On Sun, Jan 29, 2012 at 02:14:42PM +0100, Stefan Bethke wrote: > Am 29.01.2012 um 08:05 schrieb Warner Losh: > > > I think that the main issue here is that we have an assumption that we have > > a tree structure. However, it is more of a DAG across different domains. > > The hierarchy works well when each device owns all the devices below it and > > only interacted with them. Most devices are that way. However, in the > > embedded world, there's lots of reach-accrosses that are expected that > > break the model. > > What do people think would be a good approach to solve the concrete issue > without too much hackery? Aleksandr and I have presented three possible > approaches: > 1. have a PHY driver that acts as a proxy and talks to a separate MDIO master > 2. have a proxy between the ethernet driver and the miibus driver > 3. modify miibus to have a separate device for mediachg() etc. > > All three suffer from a dependency problem: miibus attachment can only > complete successfully when both the ethernet driver and the mdio driver have > been attached. In the current model, the ethernet driver provides both the > MDIO access as well as the target for the mediachg, etc. messages, so there's > no attachment ordering issue. > > In my miiproxy patch (2.), it is necessary for the ethernet driver to > cooperate in this delayed attachment, by splitting out the miibus attachment > from the device_attach method implementation. That's a fairly intrusive > change, and that would need to be made to any ethernet driver that is to > support such a split MDIO/MII setup. > > I tried delaying just the call to mii_attach(), but it seems that interacts > badly with an already attached interface. Specifically, I got a non-working > interface when I tried to call mii_attach() long after if_etherattach(). > Additionally, if_arge (and probably most other drivers) assumes that the > miibus is attached after they've successfully attached themselves, and > subsequently runs into null pointer issues when it isn't. > > Would it be possible to attach miibus without having a working PHY, and only > attach the PHYs once the MDIO device has been attached?
This would break the concept of knowing that when mii_attach() returns success you can talk to all the hardware necessary to present a working interface. So you'll just need another way instead to ensure that there's also at least a single PHY before attaching the whole thing which I don't see getting us further with the attach ordering problem of the MDIO provider. > > For the mips/atheros platforms, we could introduce ordering hints for nexus > to make sure the mdio driver gets attached before the arge's. That's a > fairly small changes (two lines), and does work, but it's more a hack than a > general solution. With my proposed change to miibus (split devices), that > would bring down the necessary changes to just a handful of lines. > How about adding the MDIO provider via multi-pass probing? That idea of that model was to attach things like drivers for interrupt controllers before any other driver that requires that resource. This seems like a perfect match here and requires neither a specific hack to the nexus (the platform generally needs to be multi-pass aware though and the thing enabled in subr_bus.c) nor a hack to miibus(4). We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place. Marius _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
