svn commit: r227687 - head/sys/dev/mii

[Marius Strobl]

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