On Jun 1, 2005, at 16:41, Stephen Hemminger wrote: > On Wed, 1 Jun 2005 15:45:26 -0500 > Andy Fleming <afleming at freescale.com> 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.
