Extending sys/dev/mii

[Stefan Bethke]

Am 11.01.2012 um 20:37 schrieb Marius Strobl:

> Okay, I suggest to postpone this discussion until then. For the
> scenario when mdiobus is the parent of miibus I see no technical
> need to change miibus to support what you want to do, just implement
> the miibus_if in mdiobus and redirect it to the device_t of the
> MAC there. Moreover, that way the hack to sidestep newbus is contained
> in the layer that actually needs it and not scattered over multiple
> frameworks.

I've posted to -net a patch that implements a workaround along those lines.  It solves two issues: talking to two upstream devices, and providing a proper attachment for miibus.

There's a number of things that made this harder than I would have liked:
- miibus has a funny way of attaching to it's parent.  Making the parent a bus that automatically attaches matching children does not lead to good results.
- miibus uses it's parents ivars.  To clarify: device_get_ivars get's a devices ivars, but those are owned by the parent; the bus uses device_[gs]et_ivars(9) to manipulate it's own private per-child data storage.  The device must not manipulate them.  I believe those variables can be moved to mii_data.
- miibus makes assumptions about it's children, namely that they have specific softc's and that they provide callbacks outside of the newbus method mechanism
- miibus assumes that all devices attached to that mdio have certain registers that have certain bits set or cleared
- miibus calls it's parent methods and two explicit callbacks, plus various calls into the interface management code.

The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship.   I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature.  Has it really never before come up?

Leaving aside the miibus issue, the newbus problem is that the ethernet driver (which is attached to some bus) needs to associate with some other driver that might not be in it's vincinity, in particular neither it's parent nor one of it's children.  Compounding the problem is that there is no way to express an attachment ordering constraint so that the ethernet driver is only attached once the required mdio driver has attached.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811


-------------- next part --------------
A non-text attachment was scrubbed...
Name: miiproxy.patch
Type: application/octet-stream
Size: 34705 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120120/b9f1387f/miiproxy.obj