On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote:

By calling an newbus method on a device that is not the parent this patch hacks around how newbus is intended to work. I also still don't see why for the scenarios you describe you can't simply use miibus(4) as-is in a clean way. For the following scenario: fooeth0 | mdiobus0 | \ miibus0 (ethswitch0 or whatever) | foophy0

In mdiobus(4) you'd simply do: DEVMETHOD(miibus_statchg, mdiobus_statchg), <...> static void mdiobus_statchg(device_t dev) {

parent = device_get_parent(dev); MIIBUS_STATCHG(device_get_parent(dev)); }

in order to bubble up the miibus_statchg-method call from miibus0 to fooeth0. Likewise for the miibus_{linkchg,mediainit,readreg,writereg}. This isn't a work-around but how newbus works, just see the various bus drivers in the tree. I agree that if you'd want to do something like the following in order to "solve" the problem with arge(4): nexus0 / \ arge0 arge1 | mdiobus0 / \ miibus0 miibus1 | | foophy0 foophy1

or even: nexus0 / | \ arge0 arge1 mdio0 / \ miibus0 miibus1 | | foophy0 foophy1

then newbus is inconvenient here as it's just not how newbus is designed. But then calling the miibus_statchg-method etc on the Ethernet driver device also isn't your only problem as there's no newbus way to connect miibus0 with arge0 in the upper or arge0/arge1 with mdio0 in the lower diagram. Such architectures are just one big hack in the newbus point of view as you'd need to sidestep newbus with something like your patch. That's why I proposed the model that puc(4), scc(4) etc are following to solve this in a clean way, which for arge(4) would look like: nexus0 | miimux0 / \ arge0 arge1 | | ethswitch0 | | | miibus0 miibus1 | | foophy0 foophy1

Then you once again can bubble up things just fine. Basically look at scc(4) how to implement this, i.e. miimux(4) (or whatever you'd like to call it) would have a core, various bus-frontends (for nexus(4), pci(4) etc) and MAC-specific device parts for AR71xx etc. Then the probe routine of the nexus-frontend of miimux(4) would need claim the devices for arge0/1 in this setup (you'd probably need to provide a way to easily hard-code or specify this via hints as I can't imagine a way to auto-detect that) by returning a higheR probe value than arge(4) does. Apart from that it just needs to pass-through the bus resources to arge(4) and implement miibus_{readreg,writereg}-methods for the shared AR71xx MDIO master. In turn arge(4) would have two bus-frontends, one for nexus(4) (for the "normal" case) and one for miimux(4). In case it attaches to miimux(4) it then would just bubble up miibus_{readreg,writereg}- calls but terminate miibus_{linkchg,mediainit,statchg)- calls locally. Besides doing whatever it needs to do to configure the switch, ethswitch(4) would also just always bubble up the miibus_if.m methods. Besides being the clean way to do this from the newbus point of view this architecture also needs zero changes to miibus(4).

Marius