On Thu, Mar 12, 2015 at 09:03:12PM +0800, Yijing Wang wrote:

On 2015/3/12 10:55, Bjorn Helgaas wrote:

quoted

On Mon, Mar 09, 2015 at 10:34:07AM +0800, Yijing Wang wrote:

quoted

Introduce pci_host_bridge_list to manage pci host
bridges in system, so we could detect whether
the host in domain:bus is alreay registered.
Then we could remove bus alreay exist test in
__pci_create_root_bus().

It's a nice idea to move this test into the core.  While you're at it, why
don't you check for any overlap with the bus ranges of existing host
bridges?  For example, if we're trying to create a new host bridge to
[bus 40-7f], it should conflict with existing bridges to [bus 00-7f]
as well as to [bus 40-ff].  I think your current patch will detect the
latter conflict but not the former.

Now pci host bridge may only know its start bus number, like acpi _BBN provided,
but does not limit the end bus number, Eg. two pci roots report _BBN 0x0 and 0x80,
so we have two bus number resource (0, 0xff) and (0x80, 0xff), if we check it strictly,
some pci scan would fail which currently scan success.

_BBN is not the correct source for the bridge's bus number range.  There's
a comment in acpi_pci_root_add() that explains why:

  * We need both the start and end of the downstream bus range
  * to interpret _CBA (MMCONFIG base address), so it really is
  * supposed to be in _CRS.  If we don't find it there, all we
  * can do is assume [_BBN-0xFF] or [0-0xFF].

A platform SHOULD know the start and and end bus number.  If it doesn't I
think it's the platform's responsibility to carve up the bus number range.
Maybe this can be done by trimming the range of the [bus 00-ff] bridge when
we discover another bridge that leads to bus 80.