> For the DP83840A, the functionalities provided by the controller chip driver
> need to be the same (this is also a serial line). A generic MII interface
> would allow reading/writing registers, using the controller's driver functions.
> Then a MII chip specific driver would provide common services, mostly about
> medias: available_medias, select_media, autoselect_media, ...
> These drivers would be in sys/dev/mii.
> MII could be handled as other bus are, by creating an miibus in autoconfig,
> and then having something like:
> de* at pci? dev? function ?
> miibus* at de?
> tl* at pci? dev? function ?
> miibus* at tl?
> DP83840A* at miibus?
> [ 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 ?

It doesn't really seem that these things should be first-class devices
at all.

Why would you want to name MIIs seperately from the NICs?  What
operations would you want to do on MIIs?

Given that there's pretty much no functionality of the MII device
which is directly usable, why make it a first-class device?  Seems
wasteful, both in user-visible complexity and internal complexity.


Just because you have a standard interface doesn't mean you have to
put it in the device hierarchy.


cgd