|To:||James Chapman <jchapman@xxxxxxxxxxx>|
|Subject:||Re: RFC: PHY Abstraction Layer II|
|From:||Andy Fleming <afleming@xxxxxxxxxxxxx>|
|Date:||Tue, 10 May 2005 12:04:55 -0500|
|Cc:||netdev@xxxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>, linuxppc-embedded@xxxxxxxxxx, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>|
|References:||<firstname.lastname@example.org> <1110334456.32556.21.camel@gaston> <email@example.com> <1110340214.32524.32.camel@gaston> <firstname.lastname@example.org> <4230D1AC.email@example.com> <firstname.lastname@example.org> <423734FB.email@example.com> <firstname.lastname@example.org> <42625DDB.email@example.com>|
Andy Fleming wrote:Ok, here's the new patch with changes suggested by James Chapman:
Ok, I've set up a new system for handling interrupts. There are now two "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT. The first one is used to indicate that the PHY layer will poll the PHY for state changes, and won't enable interrupts. The second indicates that the PHY layer will neither poll, nor enable interrupts, and thus will allow the driver to handle interrupts. The PHY layer will still operate its state machine, though.
The driver must insure a couple things:
1) It must set phydev->state to PHY_CHANGELINK 2) It must do that in a work queue (or other non-interrupt time)
The first one tells the PHY layer that the link state changed (it has to grab a lock to do this). The second one is required in order to properly take the lock.
For now. It worked around a problem some people were reporting, so I'd like to see if they report it again now that the code's out. If so, they have a fairly easy fix, and I can reinsert it (or at least reevaluate it) in the future.
|<Prev in Thread]||Current Thread||[Next in Thread>|