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