From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 20:35:42 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC6521065672 for ; Fri, 6 Jan 2012 20:35:42 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7B48FC12 for ; Fri, 6 Jan 2012 20:35:42 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id CBF5711986A; Fri, 6 Jan 2012 20:35:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120106182756.GA88161@alchemy.franken.de> Date: Fri, 6 Jan 2012 21:35:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Marius Strobl X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:35:42 -0000 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 Fon +49 151 14070811