From owner-freebsd-ppc@FreeBSD.ORG Wed Nov 10 00:08:12 2010 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26F83106566C; Wed, 10 Nov 2010 00:08:12 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id DBD4E8FC14; Wed, 10 Nov 2010 00:08:11 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 113AB582C3; Tue, 9 Nov 2010 18:08:11 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id QpRts3xcx1QI; Tue, 9 Nov 2010 18:08:10 -0600 (CST) Received: from comporellon.tachypleus.net (unknown [76.210.66.181]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 96B64582C2; Tue, 9 Nov 2010 18:08:10 -0600 (CST) Message-ID: <4CD9E269.40205@freebsd.org> Date: Tue, 09 Nov 2010 18:08:09 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101108 Thunderbird/3.0.10 MIME-Version: 1.0 To: Marius Strobl References: <4CCDD51F.2040003@freebsd.org> <20101105110728.GA65518@alchemy.franken.de> In-Reply-To: <20101105110728.GA65518@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 00:08:12 -0000 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