svn commit: r200874 - in head/sys: dev/auxio sparc64/central sparc64/ebus sparc64/fhc sparc64/pci sparc64/sbus sparc64/sparc64

[John Baldwin]

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