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
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
The main use I can see for being a driver object is to catch
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.