Jeff,

Where do we stand on this.  Are there changes you feel need to be made?=20=

  Some other issue?  It would like to know what we need to do to get=20
this in post 2.6.12.

thanks

- kumar

On May 10, 2005, at 12:04 PM, Fleming Andy-afleming wrote:

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

quoted

Andy Fleming wrote:

quoted

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=20
variable

quoted

that is used by a timer seems odd. Why not do all the work in the=20

work
 > queue and schedule it from the interrupt handler or timer?

Ok, I've set up a new system for handling interrupts.=A0 There are now
 two "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT.=A0
 The first one is used to indicate that the PHY layer will poll the =

PHY

for state changes, and won't enable interrupts.=A0 The second =

indicates

that the PHY layer will neither poll, nor enable interrupts, and thus
will allow the driver to handle interrupts.=A0 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).=A0 The second one is required in order to
properly take the lock.

quoted

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

For now.=A0 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.=A0 If so,
they have a fairly easy fix, and I can reinsert it (or at least
reevaluate it) in the future.

quoted

 > /james

Andy
<phy_05_09_2005.patch><ATT191442.txt>=