>-----Original Message----- >From: [email protected] [mailto:linux- >[email protected]] On Behalf Of Mike Frysinger >Sent: Montag, 16. November 2009 07:49 >To: [email protected] >Cc: [email protected] >Subject: Re: [Linux-kernel-commits] [7683] >trunk/drivers/spi/spi_bfin5xx.c:[#5630] ethernet driver smc91x fail to >wake up by uart inbf533-stamp > >On Tue, Oct 20, 2009 at 07:29, <[email protected]> wrote: >> Revision 7683 Author hennerich Date 2009-10-20 08:29:01 -0400 (Tue, 20 >Oct >> 2009) >> >> Log Message >> >> [#5630] ethernet driver smc91x fail to wake up by uart in bf533-stamp >> On the BF533-STAMP board there is some external logic that switches >the >> Asynchronous Memory Bank 3 between Flash and SMSC91c111 Ethernet >> controller. This logic is controlled by GPIO_PF0 which is also the >same >> PIN as SPI-SPISS Slave Mode Select. The SPI driver defaults the SPI >> Control register to Slave Mode - but doesn't enable the SPI. In case >the >> SPI bus driver wasn't utilized and is then suspended and resumed >during >> the PM state transitions - the SPI resume code enables the SPI - and >> this will case the SPI-SPISS = GPIO_PF0 being driven low. In return >this >> causes the Flash being enabled and the smc91x Ethernet driver accesses >> Flash instead of the Ethernet controller. > >shouldnt we also fix the bug that the SPI driver always enables itself >when resuming ? cant we check like drv_data->workqueue to see if any >work is pending ? >-mike
Mike, I agree - It would be better if we enable SPI after resume only in case there is some pending work. Otherwise bfin_spi_restore_state() is going to do so later. -Michael >_______________________________________________ >Linux-kernel-commits mailing list >[email protected] >https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
