Date: Sun, 8 Jan 2012 14:00:39 +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: <20120108130039.GG88161@alchemy.franken.de> In-Reply-To: <F60B2B70-049F-4497-BBA8-3C421088C1EA@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> <20120106214741.GB88161@alchemy.franken.de> <F60B2B70-049F-4497-BBA8-3C421088C1EA@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 06, 2012 at 10:53:14PM +0100, Stefan Bethke wrote: >=20 > Am 06.01.2012 um 22:47 schrieb Marius Strobl: >=20 > > 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 (t= ransitive) child of the ethernet driver that has the MII that needs to be a= djusted 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= ). > >>>>>=20 > >>>>>>> Since the parent will now be the mdiobus, miibus needs effectivel= y two attachments, one to the provider of the MDIO access, the other for th= e ethernet interface. I propose to associate the ethernet interface by a m= odified 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 ho= w a sensible change would even look like, and which combination of glue cod= e 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= not 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 notificat= ions posted to the ethernet interface device that has the MII that needs to= be adjusted in accordance with the PHY autonegotiation results. I've adde= d a field to the ivars struct and not the softc, because the softc is inclu= ded 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 ot= her parts in sys/mips would need to be MFCed first for all the Atheros plat= forms 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 s= imply 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 out= lined. 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?act= ion=3DAttachFile&do=3Dget&target=3Dembedded-switch.png (arge0 and phy4) > >>=20 > >> To make things as clear as possible, consider an RTL836x controller wh= ich 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 maste= r 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 to= p, meaning that the interposed driver would need support not only for the e= thernet 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 d= oes contains neither source nor destination information, so that miibus nee= ds to be attached to a unique driver instances that adds that information t= o 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. > >>=20 > >=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? >=20 > Yes, for the purpose of this discussion, the RTL836x series is an I2C to = MDIO bridge; the diagram for the Atheros chip is an MDIO to MDIO bridge in = that sense. >=20 > Atheros switches, as well as the RTL803x series, have an MDIO slave inste= ad of an I2C slave, but the basic layout remains the same. The ethernet dr= iver for arge0 cannot directly talk to PHY4 because it's hanging off some m= ore or less remote part of the device tree. That's what I'm trying to get = across, and that's the problem I'm trying to solve in a more or less generi= c way. >=20 Okay, this is the kind of information I was looking for as coupling devices with newbus that have no close relation in the hierarchy is tedious. However, when not using newbus the question arises how do you intend to associate the device_t of say arge0 with the mdiobus0 hanging off somewhere beneath iicbus0? Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120108130039.GG88161>