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

[John Baldwin]

On Friday, August 24, 2012 6:34:51 am Marius Strobl wrote:
> 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.

Ah, this is actually the specific use case bz@ is running into. :) That said,
I do agree it's quite rare, and it may indeed be fine to just hardcode the
name/unit in that case.

-- 
John Baldwin