From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 21:47:43 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 9E2531065680 for ; Fri, 6 Jan 2012 21:47:43 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC258FC0A for ; Fri, 6 Jan 2012 21:47:42 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q06Llf10015660; Fri, 6 Jan 2012 22:47:41 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q06Llf9b015659; Fri, 6 Jan 2012 22:47:41 +0100 (CET) (envelope-from marius) Date: Fri, 6 Jan 2012 22:47:41 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> User-Agent: Mutt/1.4.2.3i 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 21:47:43 -0000 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