Re: RFC: PHY Abstraction Layer II

[Andy Fleming <afleming@xxxxxxxxxxxxx>]

On Apr 17, 2005, at 08:00, James Chapman wrote:

> Andy Fleming wrote:
> > Ok, here's the new patch with changes suggested by James Chapman:
>
> I guess I still have questions about the way interrupts are used.
>
> Using an interrupt to schedule a work queue which then sets a variable
> that is used by a timer seems odd. Why not do all the work in the work
> queue and schedule it from the interrupt handler or timer?

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.

> Also, did you mean to leave the #if 0 code in davicom.c?

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.

> /james

Andy

phy_05_09_2005.patch
Description: Binary data