RFC: PHY Abstraction Layer II

Andy Fleming afleming at freescale.com
Thu Jun 2 08:42:56 EST 2005


On Jun 1, 2005, at 16:19, Stephen Hemminger wrote:

> Andy Fleming wrote:
>>
>> But not this one.  The phy_read and phy_write functions are  
>> reading  from and writing to a bus.  It is a reasonable  
>> implementation to have  the operation block in the bus driver, and  
>> be awoken when an  interrupt signals the operation is done.  All  
>> of the phydev spinlocks  have been arranged so as to prevent the  
>> lock being taken during  interrupt time.
>>
>> Unless I've misunderstood spinlocks (it wouldn't be the first  
>> time),  as long as the lock is never taken in interrupt time, it  
>> should be ok  to hold the lock, and wait for an interrupt before  
>> clearing the lock.
>>
>
>
> The problem is that sleeping is defined in the linux kernel as  
> meaning waiting on a mutual exclusion
> primitive (like semaphore) that puts the current thread to sleep.  
> It is not legal to sleep with a spinlock held.
> In the phy_read code you do:
>     spin_lock_bh(&bus->mdio_lock);
>    retval = bus->read(bus, phydev->addr, regnum);
>    spin_unlock_bh(&bus->mdio_lock);
>
> If the bus->read function were to do something like start a request  
> and wait on a semaphore, then
> you would be sleeping with a spin lock held.  So bus->read can not  
> sleep! (as sleep is defined in the
> linux kernel).

Hmm...  I understand this reasoning, but I still need a way for a bus  
read to wait for an interrupt before returning.  I suppose I can just  
have the code spin while it waits, but that seems wrong, somehow.   
I'm open to any suggestions.



More information about the Linuxppc-embedded mailing list