Date: Fri, 6 Jan 2012 21:35:40 +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: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> In-Reply-To: <20120106182756.GA88161@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=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. 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 >=20 [ 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=3DAttachFile&do=3D= get&target=3Dembedded-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. I would like to find a solution that allows us to plug together an = ethernet driver, a driver that makes that MDIO bus available, and the = miibus/phy combo with minimal effort. Writing a driver framework that = can be interposed between arbitrary drivers in the system to pass one = message from the PHY to the ethernet driver seems rather convoluted to = me. (Yes, for the concrete case we can always hack something up, but = I'm trying to find something better than that.) 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?95372FB3-406F-46C2-8684-4FDB672D9FCF>