Date: Wed, 23 Dec 2009 09:32:34 -0500 From: John Baldwin <jhb@freebsd.org> To: Marius Strobl <marius@alchemy.franken.de> 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 Message-ID: <200912230932.34491.jhb@freebsd.org> In-Reply-To: <20091223080021.GJ74529@alchemy.franken.de> References: <200912222102.nBML2k98076576@svn.freebsd.org> <200912221720.00692.jhb@freebsd.org> <20091223080021.GJ74529@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912230932.34491.jhb>