On Wed, Jan 18, 2012 at 10:27 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Wed, Jan 18, 2012 at 8:52 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> If we make a quirk for this machine, we still have the question of >> what to do with my patches. I assert that if Linux ever reconfigures >> any bus numbers or does any configuration of hot-added P2P bridges, it >> must pay attention to the host bridge bus number window. Therefore, I >> think we need something like this series even if we make a quirk. > > We may need more smart way to find unused bus range instead of just > just max+1 and ++max. > > For example: one bridge (A) have two child bridges (B and C), > A: bus range: 10-2f > B: bus range: 11-1f > C: bus range: 20-2f > > when some broken case happen, B bus BIOS assigned bus range will be > all cleared in first pass. > but C bus is ok. but in second bus, bus will be assigned to 30- . > that is totally wrong, We should still > try to use bus 11-1f at first for bus B. Yes, I agree we may need a better way to choose bus numbers in the first place. My current patch (3/4) doesn't change how we choose them; it only rejects invalid ones. > your patches should be ok, only exception should be considered: some > default link root bus could access > out of bus range state with _CRS stating. some kind of transparent > bridge concept. I'm afraid I couldn't make any sense out of the paragraph above. If we don't have any information about host bridge bus number windows (for example, for bridges not described in ACPI), I think we'll have to default to [bus 00-ff]. That's effectively what these patches already do. We only build the struct pci_host_bridge for ACPI bridges, so the check I added in pci_add_new_bus() does nothing for non-ACPI bridges. If you're suggesting that we need to add some exception (a "transparent bridge concept"?), can you clarify or suggest a patch? Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
