On Mar 10, 2005, at 17:01, James Chapman wrote: > Hi Andy, > > Can you elaborate on why this phy abstraction is needed? > > In your original post, you mentioned that you were going to post a > patch to show how your code would be hooked up in an existing net > driver. Did I miss it? It would help in understanding the pros and cons > of using genphy over using plain old mii.c.
Hi James, I haven't posted it yet, since it's a large patch (it deletes a lot of code from my driver), but I can give a basic overview of how my driver hooks into this code: 1) The driver connects to the PHY when opened, calling phy_connect, and then clears some bits to declare functionality it doesn't support (my driver, for instance, does not support gigabit in half-duplex mode). 2) The driver implements a function which reads the speed/duplex settings, and modifies the controller registers as appropriate (also bringing the carrier up and down depending on link state). My driver needs to note whether it's gigabit or not (for GMII vs MII mode), and the duplex (to set the MAC full or half). Both of those steps are very straightforward. The PHY layer will invoke the callback whenever the link state changes, so the controller will always be up-to-date. 3) The third step is the part that can make things a little messier. My driver implements a second driver for the MDIO bus, which is connected through its registers. This bus needs to be registered, and the driver also needs to register. Then some code needs to be written to deal with initialization, and takedown. I can send out that patch anytime, if there's demand. > > btw, I recently posted a patch to add GigE support to mii.c which is > in Jeff's netdev-2.6 queue. Some register definitions were added in > mii.h that will collide with yours. Yeah, I ran in to some of those. I can't remember whether they're in the patch or not, I suspect not. I will have to submit a new patch to cover those (I just changed my code to use your definitions). Andy
