Review request -- splitting OF enumeration from nexus

[Marius Strobl]

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