Review request -- splitting OF enumeration from nexus

[Nathan Whitehorn]

On 11/05/10 06:07, Marius Strobl wrote:
>
> 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.
>    

Without sparc64, there isn't a lot of point to this reorganization and 
we should probably stick with the status quo instead. The last thing in 
the world I want is to create yet more duplication of OF-related 
infrastructure -- we already have enough of that with FDT.
-Nathan