From owner-svn-src-all@FreeBSD.ORG Wed Dec 23 14:38:37 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B68FF1065672; Wed, 23 Dec 2009 14:38:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 857FB8FC0A; Wed, 23 Dec 2009 14:38:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 307F546B17; Wed, 23 Dec 2009 09:38:37 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 737B48A01D; Wed, 23 Dec 2009 09:38:35 -0500 (EST) From: John Baldwin To: Marius Strobl Date: Wed, 23 Dec 2009 09:32:34 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200912222102.nBML2k98076576@svn.freebsd.org> <200912221720.00692.jhb@freebsd.org> <20091223080021.GJ74529@alchemy.franken.de> In-Reply-To: <20091223080021.GJ74529@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912230932.34491.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 23 Dec 2009 09:38:35 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r200874 - in head/sys: dev/auxio sparc64/central sparc64/ebus sparc64/fhc sparc64/pci sparc64/sbus sparc64/sparc64 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:38:37 -0000 On Wednesday 23 December 2009 3:00:21 am Marius Strobl wrote: > On Tue, Dec 22, 2009 at 05:20:00PM -0500, John Baldwin wrote: > > On Tuesday 22 December 2009 4:02:46 pm Marius Strobl wrote: > > > Author: marius > > > Date: Tue Dec 22 21:02:46 2009 > > > New Revision: 200874 > > > URL: http://svn.freebsd.org/changeset/base/200874 > > > > > > Log: > > > Enroll these drivers in multipass probing. The motivation behind this > > > is that the JBus to EBus bridges share the interrupt controller of a > > > sibling JBus to PCIe bridge (at least as far as the OFW device tree > > > is concerned, in reality they are part of the same chip) so we have to > > > probe and attach the latter first. That happens to be also the case > > > due to the fact that the JBus to PCIe bridges appear first in the OFW > > > device tree but it doesn't hurt to ensure the right order. > > > > Hmm, I'm curious why you used BUS_PASS_DEFAULT with EARLY_DRIVER_MODULE()? > > The intent was that EARLY_DRIVER_MODULE() only really be used for drivers that > > used a pass other than BUS_PASS_DEFAULT. > > Just in order to document as good as possible that the use of > another pass level has been considered but was decided to not > be the right thing to do (although dma_sbus(4) can act like a > bus BUS_PASS_BUS isn't appropriate for example) as my impression > was that at some point in time we'll want to got through the > tree and change for example all bus drivers to use BUS_PASS_BUS > etc similarly to how BUS_PROBE_* at least partially was introduced > in a sweeping fashion (causing the expected breakage). Ok. I am slowly working on allow for multiple passes but am working on resource management stuff currently (the resource_list_reserve() commit). Hopefully in the not too distant future I can teach the PCI bus driver to handle multiple passes correctly along with ACPI and many other x86 bus drivers. I'm not able to test non-x86 at this point, but I believe that the PCI bus changes I make will be suitable for other platforms. -- John Baldwin