Date: Tue, 09 Nov 2010 18:08:09 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus Message-ID: <4CD9E269.40205@freebsd.org> In-Reply-To: <20101105110728.GA65518@alchemy.franken.de> References: <4CCDD51F.2040003@freebsd.org> <20101105110728.GA65518@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CD9E269.40205>