Extending sys/dev/mii

[Marius Strobl]

On Fri, Jan 06, 2012 at 09:35:40PM +0100, Stefan Bethke wrote:
> 
> Am 06.01.2012 um 19:27 schrieb Marius Strobl:
> 
> > On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote:
> >> Am 05.01.2012 um 21:52 schrieb Stefan Bethke:
> >> 
> >>> The problem with this is that the miibus instance might not be a (transitive) child of the ethernet driver that has the MII that needs to be adjusted to the new PHY settings.  And since the method does not provide any parameters about which phy or miibus did issue the method, or which ifp it applies to, bubbling it up won't work (that the scenario where the PHY for arge0 is connected to the switch's MDIO, which is attached to arge1's MDIO).
> >>> 
> >>>>> Since the parent will now be the mdiobus, miibus needs effectively two attachments, one to the provider of the MDIO access, the other for the ethernet interface.  I propose to associate the ethernet interface by a modified mii_attach() function that takes a device_t (of the ethernet driver) instead of the two callback function pointers.
> >>>> 
> >>>> Please elaborate on why these changes are technically necessary
> >>>> to implement what you are trying do. Otherwise I prefer to avoid
> >>>> them given the rototilling they'd cause.
> >>> 
> >>> Necessary is a strong word.  Right now, I'm trying to understand how a sensible change would even look like, and which combination of glue code and miibus changes make the most sense.
> >>> 
> >>> Let me see if I can come up with a prototype patch the next couple of days, so we don't have to theorize about the changes that might or might not be necessary.
> >> 
> >> Here's a patch that causes zero rototilling, if I'm not mistaken.
> >> 
> >> The patch implements the split between the MDIO access and notifications posted to the ethernet interface device that has the MII that needs to be adjusted in accordance with the PHY autonegotiation results.  I've added a field to the ivars struct and not the softc, because the softc is included by many network drivers, while the ivars are private to mii.c  For this reason, I believe this change is API and ABI compatible, and likely can be MFCed.  (I believe MFCing is not high on the priority list because many other parts in sys/mips would need to be MFCed first for all the Atheros platforms to become fully usable, but Adrian can correct me.)
> > 
> > By calling an newbus method on a device that is not the parent this
> > patch hacks around how newbus is intended to work.
> 
> Admittedly, it adds a reference across the tree.
> 
> > I also still don't see why for the scenarios you describe you can't simply use miibus(4) as-is in a clean way.
> 
> [ Scenarios for which the existing model works ]
> 
> > That's why I proposed the model that puc(4), scc(4) etc are
> > following to solve this in a clean way, which for arge(4)
> > would look like:
> >       nexus0
> >         |
> >      miimux0
> >       /   \
> >  arge0    arge1
> >   |        |
> > ethswitch0  |
> >   |        |
> > miibus0   miibus1
> >   |        |
> > foophy0   foophy1
> > 
> [ Explanation on how things work with above setup ]
> 
> Except that your diagram does not correlate with the scenario I've outlined.  I'll try to explain again: the MDIO master access for the PHY which MII lines are connected to arge1 are hosted on a separate device.  Please refer to this diagram: http://wiki.freebsd.org/StefanBethke/EtherSwitch?action=AttachFile&do=get&target=embedded-switch.png (arge0 and phy4)
> 
> To make things as clear as possible, consider an RTL836x controller which is attached to the system through an I2C bus.  (Never mind that it has a switch, that's not relevant to the discussion here.)  It has one MII bus connection connecting one ethernet interface MAC to one PHY; the MDIO master that can talk to that PHY is in the RTL836x.  The common ancestor for the ethernet driver and the MDIO driver then are likely to be very near the top, meaning that the interposed driver would need support not only for the ethernet driver in question, but the I2C bus as well.  An interposed driver at nexus level that gets the phy linkchg message bubbled up to it does need to send it back down to the ethernet driver.  The message sent by miibus does contains neither source nor destination information, so that miibus needs to be attached to a unique driver instances that adds that information to the message before bubbling it up.  Of course, it also needs to get this information from somewhere, so a reference to the ethernet driver needs to be injected somehow.
> 

Okay, now I'm confused; I don't know the RTL836x but you seem to say
that essentially for this discussion this is a I2C to MDIO bridge,
with iicbus(4) being involved to access the MDIO of PHYs being new
information. Is this scenario supposed to be also covered by
embedded-switch.png? If it is, what purpose does the MDIO connection
between arge1 and the switch in there serve for?

Marius