Date: Wed, 25 Jan 2012 23:17:53 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Stefan Bethke <stb@lassitu.de> Cc: FreeBSD-arch <freebsd-arch@freebsd.org> Subject: Re: Extending sys/dev/mii Message-ID: <20120125221753.GA17821@alchemy.franken.de> In-Reply-To: <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> References: <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <F60B2B70-049F-4497-BBA8-3C421088C1EA@lassitu.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 21, 2012 at 12:08:34AM +0100, Stefan Bethke wrote: > 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. That's the idea behind auto-probing, which all FreeBSD bus drivers implement as far as the physical bus supports it. Otherwise you have to resort to using hints one way or the other, which miibus(4) also supports nowadays. The problem with miibus(4) in the embedded world probably is that as a last resort ukphy(4) grabs anything that sufficiently looks like a PHY. If there's a way to properly identify devices that actually shouldn't be handled by ukphy(4) it probably would make sense to add a pseudo-driver roughly similar to fixup_pci(4) that grabs them instead and does whatever needs to be done or maybe even just nothing instead of treating them as PHYs. The bottom line still is whether with all the quirks needed to make a framework built around IEEE 802.3-compliant stuff support also the odds of the embedded world the IMO limited code-reuse justifies doing it that way. > - 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. Yes, that's unpleasant. However, according to the man page and the newbus code a device not setting it's own instance variables is just a should, not a must. The problem with mii_data is that you can't really rely on the softc being stable until the attach method is called. This happens to work between probe and attach if the former returns 0 but given that miibus(4) manages the memory for its instance variables itself going that route is the lesser evil thing here. I'm trying to think of a way to properly newbus-ify the whole stuff that mii_attach() does but currently can't come up with a really cleaner solution ... > - 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. Yes, it assumes IEEE 802.3-compliant devices and usecases. If you throw out all the things like auto-probing via ID registers, out- detection of media via the BMSR and so and which makes miibus(4) the generic PHY handling framework that it is or work around them, I hardly can think of much that would be left that justifies using miibus(4) in the first place though. Can't we just build another framework which handles all the other stuff that also just happens to have an MDIO interface and attach it instead? > > 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. > Yes, architecture of newbus is built around the assumption that there's a single device tree and all you ever need are child- parent-relationships. AFAICT this assumption dates back to at least the device configuration in 4.4BSD and apart from the embedded world it held true just fine so far ... Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120125221753.GA17821>