Date: Fri, 5 Nov 2010 12:07:28 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus Message-ID: <20101105110728.GA65518@alchemy.franken.de> In-Reply-To: <4CCDD51F.2040003@freebsd.org> References: <4CCDD51F.2040003@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 31, 2010 at 03:44:15PM -0500, Nathan Whitehorn wrote: > Nexus on OF platforms doesn't behave like nexus on x86, which generates > some periodic difficulty with cryptosoft or syscons attaching to all > devices and taking over the system when someone makes a wrong > assumption. I think this is an exaggeration of the problem; the only relevant difference in this regard should be that on x86 there are no (unattached) non-pseudo-devices on the nexus, while on powerpc and sparc64 (apparently this also applies to the embedded architectures though) there are real devices where a buggy pseudo-driver like cryptosoft(4) has a chance to attach to. AFAICT cryptosoft(4) also is the only MI driver suffering from this and can be easily fixed by letting it add its pseudo-device with a specific unit number and return BUS_PROBE_NOWILDCARD. The syscons(4) front-end you are referring to is a powerpc MD part and the sparc64 counterpart never had that problem. > I have done some work to split out OF enumeration into a > new, acpi(4)-like bus called ofwbus that does all of the OF enumeration > previously done by nexus(4). The patch can be found at > http://people.freebsd.org/~nwhitehorn/ofwbus.diff. > > Doing this also provides a number of other benefits: it shares code > between PowerPC and sparc64, unifies the AIM and Book-E nexus > implementations on PPC, and makes it easier to have non-Open Firmware > platforms on PPC (the original motivation for the work). I have tested > this code with no obvious problems on a variety of Apple PPC machines > and a Sun Ultra 5. More testing and comments would be much appreciated. > If no has any objections, I will commit these changes in 2 weeks. To be honest I don't like the approach of factoring out the OF enumeration to dev/ofw the way it is done for the following reasons: o Currently we perfectly recreate the hierarchy of the OF device tree in the kernel, where the OF root device is represented by the root node, the OF nexus by nexus(4) and so forth. With ofwbus(4) in between we break this shadowing. Granted, this is somewhat a cosmetic issue, but still having the same hierarchy IMO is a nice feature as other code like for example the CPU/core enumeration code (which has to work before bus and device enumeration is done) still has to work with the OF device tree so basically one has to deal with both hierarchies in the kernel. o It shoves way too much MD-knowledge into dev/ofw, f.e. the device exclude lists (which even might be contradicting across platforms, i.e. every time one adds device for one architecture one would have to check whether there isn't a vital device of the same name or type on the others) and the interrupt bits (f.e. sun4v yet again would need something different there). o Besides adding some style bugs the patch also has several obvious functional ones, f.e. the type-based exclude list of sparc64 got lost, the former nexus(4) front-end of ebus(4) now tries to attach to ofwdump(4)[sic] and for sparc64 (as well as for sun4v) the default for the number of address-cells when no corresponding property exists would need to be 2 instead of 1 (on sparc64 these properties actually are missing occasionally). Also due to the sheer complexity I'm not sure from the patch whether ssm(4), which previously inherited from nexus(4), still works correctly. What this all boils down to is that due to the great variety of busses and devices on sparc64 and how they may hang off from each other in different ways this patch would need to be tested on all sun4u models FreeBSD supports so far in order to shake out all problems with corner cases of the patch and fof irmware versions (Solaris probably doesn't duplicated most of the equivalents for every machine model without a reason), several of which I only had temporary access to. Put differently, if you want to factor this out into dev/ofw for powerpc feel free to do so but please find a way to keep the MI part really MI so that device exclude lists, interrupt bits, cell defaults etc remain in MD locations (f.e. by supplying macros for these in MD headers or for the interrupt bits maybe and also a function in the MD code) and please don't switch sparc64 to it. IMO this just would need a lot of work to stabilize it there with no real net gain. Regarding reducing code duplication on sparc64 I'd rather prefer to put all relevant OF knowledge into nexus(4) and inherit from there like I've started to do with ssm(4) (but what probably should also work with f.e. central(4), fhc(4) and upa(4) but not so easily with sbus(4)). But unfortunately retro- fitting changes in the bus support always is a PITA on sparc64 due to the significant differences in peripherals between machine models and in firmware anomalies between different versions for the same model. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101105110728.GA65518>