Hi,
On Thu, Sep 13, 2012 at 11:00:12PM +0200, Mark Kettenis wrote:
> > However, there might be a different solution:
> > We could track attached busses (not just host bridge busses but all busses)
> > in the pci code (or via MD code and hooks but I think that would be a
> > generic thing) and do nothing in pciattach if a bus is discovered for
> > the second time.
> >
> > With this MD code could use whatever methods it wants to detect otherwise
> > undiscovered host bridges. Possible methods might be magic numbers, hints
> > from ACPI or even a linear scan of all possible bus numbers.
> >
> > Does this sound like a possible solution?
>
> It actually got me thinking about proper bus number resource
> accounting again. Something that's needed for properly hot-plugging
> pci busses. Below is a diff that does this.
>
> With that code, your acpi code can just try to grab the bus number
> using extent_alloc_region() and only attach a bus if that succeeds.
Nice idea!
However, I have some doubts about the implementation. In particular
you don't pass sc_busex down through bridge devices. This is ok as long
as all busses that we _discover_ downstream of that bridge are in fact
_physically_ dowstream of that bridge, too. In this case the bus range
of the bridge (PPB_BUSINFO_SECONDARY..PPB_BUSINFO_SUBORDINATE) covers
all busses.
However, host bridges that are handled e.g. in arch/i386/pci/pchb.c
can appear downstream of another bridge but use bus numbers that are
outside of the upstream bridge's bus number range.
The easiest solution would probably be, to make the pcibus_ex an MI
thing, i.e. define and allocate it globally in dev/pci/pci.c.
regards Christian
