Re: RFC: PHY Abstraction Layer II

[Andy Fleming <afleming@xxxxxxxxxxxxx>]

On Jun 1, 2005, at 16:41, Stephen Hemminger wrote:

> On Wed, 1 Jun 2005 15:45:26 -0500
> Andy Fleming <afleming@xxxxxxxxxxxxx> wrote:
> > >     * get rid of bus read may sleep implication in comment.
> > >       since you are holding phy spin lock it better not!!
>
> On a different note, I am not sure that using sysfs/kobject bus object
> is the right thing for this object.  Isn't the phy instance really  
> just
> an kobject whose parent is the network device?  I can't see a 1 to N
> relationship between phy bus and phy objects existing.

Well, the MII Management bus is, in fact, a bus.  When a network  
driver wants to modify a PHY, it must access that bus.  Many ethernet  
controllers have a 1 to 1 relationship, since a typical NIC is a PCI  
card with 1 ethernet port (meaning one controller, and one PHY).   
However, many systems have multiple ethernet controllers attached to  
one bus, which configures multiple PHYs.  Currently, these systems  
have been relying on luck to prevent multiple accesses to the same bus.

This tends to work because all of the PHY support is contained within  
the ethernet driver, so it is easy for such drivers to ensure that  
only one PHY transaction is done at a time.  This system begins to  
fall apart, though, when the PHY drivers start operating more  
independently to react to changing PHY state.  It really begins to  
fall apart if you have multiple drivers trying to access a shared  
bus.  For instance, the 8560 ADS board has 2 gigabit ethernet ports  
controlled by the gianfar driver, and 2 10/100 ports in the CPM  
subsystem, controlled by the fcc_enet driver.

These two drivers each have an access point for the bus, which use  
different mechanisms (one is a bit bang interface, and one is  
register based).  Using the new abstraction, it is possible for the  
FCC driver to use the gianfar driver's bus, thus saving code, and  
reducing complexity.

> The main use I can see for being a driver object is to catch  
> suspend/resume,
> and wouldn't you want that to be tied to the network device.

It would be quite easy for the network driver to suspend or resume  
the PHY and bus objects under the new abstraction.  However, if eth0  
is suspended, should it suspend the whole bus, and all the PHYs on  
it?  By making the MII bus an independent entity, eth0 can be  
suspended, and it can choose to suspend its PHY, but eth1 can  
continue to access its PHY over the bus, since those aren't suspended.