Date: Fri, 6 Jan 2012 22:47:41 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Stefan Bethke <stb@lassitu.de> Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii Message-ID: <20120106214741.GB88161@alchemy.franken.de> In-Reply-To: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 06, 2012 at 09:35:40PM +0100, Stefan Bethke wrote: >=20 > Am 06.01.2012 um 19:27 schrieb Marius Strobl: >=20 > > On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote: > >> Am 05.01.2012 um 21:52 schrieb Stefan Bethke: > >>=20 > >>> The problem with this is that the miibus instance might not be a (tra= nsitive) child of the ethernet driver that has the MII that needs to be adj= usted to the new PHY settings. And since the method does not provide any p= arameters about which phy or miibus did issue the method, or which ifp it a= pplies to, bubbling it up won't work (that the scenario where the PHY for a= rge0 is connected to the switch's MDIO, which is attached to arge1's MDIO). > >>>=20 > >>>>> 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 mod= ified mii_attach() function that takes a device_t (of the ethernet driver) = instead of the two callback function pointers. > >>>>=20 > >>>> 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. > >>>=20 > >>> 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. > >>>=20 > >>> 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 n= ot be necessary. > >>=20 > >> Here's a patch that causes zero rototilling, if I'm not mistaken. > >>=20 > >> The patch implements the split between the MDIO access and notificatio= ns posted to the ethernet interface device that has the MII that needs to b= e 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 include= d by many network drivers, while the ivars are private to mii.c For this r= eason, I believe this change is API and ABI compatible, and likely can be M= FCed. (I believe MFCing is not high on the priority list because many othe= r parts in sys/mips would need to be MFCed first for all the Atheros platfo= rms to become fully usable, but Adrian can correct me.) > >=20 > > By calling an newbus method on a device that is not the parent this > > patch hacks around how newbus is intended to work. >=20 > Admittedly, it adds a reference across the tree. >=20 > > I also still don't see why for the scenarios you describe you can't sim= ply use miibus(4) as-is in a clean way. >=20 > [ Scenarios for which the existing model works ] >=20 > > 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 > >=20 > [ Explanation on how things work with above setup ] >=20 > Except that your diagram does not correlate with the scenario I've outlin= ed. I'll try to explain again: the MDIO master access for the PHY which MI= I lines are connected to arge1 are hosted on a separate device. Please ref= er to this diagram: http://wiki.freebsd.org/StefanBethke/EtherSwitch?action= =3DAttachFile&do=3Dget&target=3Dembedded-switch.png (arge0 and phy4) >=20 > 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 s= witch, that's not relevant to the discussion here.) It has one MII bus con= nection connecting one ethernet interface MAC to one PHY; the MDIO master t= hat can talk to that PHY is in the RTL836x. The common ancestor for the et= hernet 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 ethe= rnet 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 t= he message before bubbling it up. Of course, it also needs to get this inf= ormation from somewhere, so a reference to the ethernet driver needs to be = injected somehow. >=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120106214741.GB88161>