On Thu, 18 Sep 1997 16:01:24 +0200 
 Manuel BOUYER <bouyer@antioche.lip6.fr> wrote:

 > These 3 elements have a standart interface, so they may be present in other
 > board as well. The DP83840A is present in some (all ?) dec tulip based
 > ethernet board. So I think it is worth definning an software interface
 > for the MII and I2C busses, and writing "controller independant" drivers
 > for the DP83840A and 24c01A.

[ snip ]

 > de* at pci? dev? function ?
 > miibus* at de?
 > tl* at pci? dev? function ?
 > miibus* at tl?
 > DP83840A* at miibus?

What you're suggesting has been done in BSD/OS (starting at 3.0, I think).
I think it's a marvelous idea - I'd certainly like for that code to be
shared.

The MII bus has one locator - "device number" - an integer address.  I would
suggest a config syntax like:

de*	at pci? dev ? function ?
mii*	at de?
fxp*	at pci? dev ? function ?
mii*	at fxp?
tl*	at pci? dev ? function ?
mii*	at fxp?
ep*	at pci? dev ? function ?
mii*	at ep?

nsphy*	at mii? dev ?

...and whatever other PHYs are out there.  This would make adding new PHY
support to other network drivers _trivial_ (indeed, as new boards come out
with new PHYs, they'll probably Just Work if we have support for that
PHY already because of another board).

 > [ possibly others MII drivers ]
 > This would finer grain tuning when we'll have several mii drivers.
 > The problem here is that we can't easily say that a MII driver can attach to a
 > controller but not to another (the internal MII device of the thunderland will
 > never attach to a de). So I'd prefer:
 > de* at pci? dev? function ?
 > DP83840A* at de?
 > [ possibly others MII drivers ]
 > tl* at pci? dev? function ?
 > miitl* at tl?
 > DP83840A* at tl?
 > 
 > Any ideas about all this ?

I don't like this so much.  The way BSD/OS did this was to define an
"mii common" data structure, that contains pointers to all of the configured
children of that interface.  I don't see how this could possibly be a problem,
since the autoconfiguration framework has the goo for all of the bookeeping
you need to do, here.  Since the user will never be dealing with the
mii or nsphy instances directly, I'm not sure I see the issue you're trying
to convey :-)

Oh, wait, yes I do... I think the "internal controller for MII" thing is
really a non-issue... the fack that it's attaching to a "de" or "tl"
instance is enough - they just provide the right function pointers in
miibus_attach_args.

If you do this, then the ifmedia hooks for interfaces with MII are simply
calls into the MII bus layer.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-6                                       Work: +1 415 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939