On Nov 19, 2004, at 16:43, Benjamin Herrenschmidt wrote:

On Fri, 2004-11-19 at 15:18 -0600, Andy Fleming wrote:

quoted

So when you say instantiated, would you consider calling an "attach"
function with the phy_id and bus_id of the desired PHY instantiation?
I'm fine with that.  The PHY would need to be able to send
notifications to the enet controller (currently done through a
callback).  I'm interested in ideas on how the notifier could be used
(I have a distaste for callbacks).

Look at the notifier lists in include/linux/notifier.h

Ok, will do.

quoted

Autopoll features sound pretty neat.  I think the system should 
support
that.

But that becomes MAC-dependant again... That means you'd need 1) a way
for the MAC driver to ask the PHY driver what register it wants
autopolled, and a function in the PHY driver for the MAC to call when 
it
detects a change. Also, autopoll is broken in some MACs...

What I'm envisioning here is that the driver would be able to tell the 
PHY infrastructure that it's going to do its own thing, and then make 
use of the reading/configuring part of the infrastructure, similar to 
how sungem and gianfar are currently set up.  But they would have the 
option of letting the infrastructure also handle the status updates.  
And, of course, the driver would not go through the effort to use 
autopoll if it were broken.

quoted

  PHY interrupts are supported (they work quite well on my 85xx
system), as is timer-based polling.  Do you really think that there 
are
special cases which can't be handled using a library similar to the
sungem_phy one?

Nope. I think timer based polling with a sungem-like fallback mecanism
to forced speeds would be nice.

Yes, I agree.  The system I currently have does fallback to forced, 
though it doesn't yet support the "magic aneg" feature you mentioned.  
But that should be easy to add, and so it shall be.


Andy Fleming