Date: Fri, 6 Jan 2012 22:53:14 +0100 From: Stefan Bethke <stb@lassitu.de> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii Message-ID: <F60B2B70-049F-4497-BBA8-3C421088C1EA@lassitu.de> In-Reply-To: <20120106214741.GB88161@alchemy.franken.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>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 06.01.2012 um 22:47 schrieb Marius Strobl: > 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 = (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). >>>>>=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 modified 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 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 = 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.) >>>=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 = simply 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 = 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=3DAttachFile&do=3D= get&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 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. >>=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? 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. Atheros switches, as well as the RTL803x series, have an MDIO slave = instead of an I2C slave, but the basic layout remains the same. The = ethernet driver for arge0 cannot directly talk to PHY4 because it's = hanging off some more 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 generic way. Stefan --=20 Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F60B2B70-049F-4497-BBA8-3C421088C1EA>