From owner-svn-src-all@FreeBSD.ORG Fri Aug 24 10:34:52 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2F6E106564A; Fri, 24 Aug 2012 10:34:52 +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 772948FC08; Fri, 24 Aug 2012 10:34:52 +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 q7OAYphM036756; Fri, 24 Aug 2012 12:34:51 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q7OAYpE0036755; Fri, 24 Aug 2012 12:34:51 +0200 (CEST) (envelope-from marius) Date: Fri, 24 Aug 2012 12:34:51 +0200 From: Marius Strobl To: John Baldwin Message-ID: <20120824103451.GM28757@alchemy.franken.de> References: <201111182239.pAIMdkCr003347@svn.freebsd.org> <201208231012.52720.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208231012.52720.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, Marius Strobl , Bjoern Zeeb , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r227687 - head/sys/dev/mii X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 10:34:53 -0000 On Thu, Aug 23, 2012 at 10:12:52AM -0400, John Baldwin wrote: > On Friday, November 18, 2011 5:39:46 pm Marius Strobl wrote: > > Author: marius > > Date: Fri Nov 18 22:39:46 2011 > > New Revision: 227687 > > URL: http://svn.freebsd.org/changeset/base/227687 > > > > Log: > > - Add a hint.miibus.X.phymask hint, allowing do individually exclude PHY > > addresses from being probed and attaching something including ukphy(4) > > to it. This is mainly necessarily for PHY switches that create duplicate > > or fake PHYs on the bus that can corrupt the PHY state when accessed or > > simply cause problems when ukphy(4) isolates the additional instances. > > - Change miibus(4) to be a hinted bus, allowing to add child devices via > > hints and to set their attach arguments (including for automatically > > probed PHYs). This is mainly needed for PHY switches that violate IEEE > > 802.3 and don't even implement the basic register set so we can't probe > > them automatically. However, the ability to alter the attach arguments > > for automatically probed PHYs is also useful as for example it allows > > to test (or tell a user to test) new variant of a PHY with a specific > > driver by letting an existing driver attach to it via manipulating the > > IDs without the need to touch the source code or to limit a Gigabit > > Ethernet PHY to only announce up to Fast Ethernet in order to save > > energy by limiting the capability mask. Generally, a driver has to > > be hinted via hint.phydrv.X.at="miibusY" and hint.phydrv.X.phyno="Z" > > (which already is sufficient to add phydrvX at miibusY at PHY address > > Z). Then optionally the following attach arguments additionally can > > be configured: > > hint.phydrv.X.id1 > > hint.phydrv.X.id2 > > hint.phydrv.X.capmask > > - Some minor cleanup. > > I was looking at this today with bz to try to figure out how to use this. > It strikes me that in a case of a bus with devices that have IDs it can > be useful to not hardcode the driver name and unit number, but to be able > to create a device and let the normal driver probe mechanics work. The > existing miibus_hinted_child() routine already largely enforces that by > ensuring that any new child has a unique phyno address. Two approaches I > can think of are: > > 1) Never hardcode the name and unit number. > > 2) Don't hardcode the name and unit number if the name is "phy". > > This would let you do something like: > > hint.phy.0.at="miibus0" > hint.phy.0.phyno="1" > hint.phy.0.id1="xxx" > hint.phy.0.id2="yyy" > > And then 'e1000phy' or 'brphy' or whoever could manage the phy. Though > perhaps in the case of hinted children you want to always force the phy > driver? > I think to understand what you mean but fail to see an actual use case for it. If there's a real PHY on a MII bus a specialized driver like e1000phy(4) already knows about, there's no reason to use a hint to force it to probe and attach as that will be done automatically. If on the other hand, you'd want to say e1000phy(4) probe and attach a PHY it doesn't know about, you'd need to also alter its probe table but your approach doesn't provide any means to link a PHY hint with a certain driver. In general, the use for the latter is also very limited in reality as drivers have to not only take IDs into account but also things like chip revisions etc. (that's also why I think that attempts to make PCI drivers use a unified probing approach/tables in order to provide means to patch ID lists is rather pointless). The main purpose of the above commit is to force wildcard/hoover drivers like ukphy(4) to attach to non-IEEE 802.3 compliant "PHYs" without proper ID registers like so: hint.ukphy.0.at="miibus0" hint.ukphy.0.phyno="2" The use of the name of the driver to probe and attach in these hints mainly was done for consistency with the ISA etc. hints we have. However, as noted in the commit message, you can actually (ab)use these hints to also make a specialized driver probe and attach an unknown PHY (real or not) by faking the ID registers of a PHY it knows of. Note that for this to work, you actually need to put the appropriate contents of real ID registers into these hints and not just OUI and model as found in the driver. As noted above, the use for this method might be very limited in reality. Marius