On Wed, Jan 18, 2012 at 12:01 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Wed, Jan 18, 2012 at 10:30 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Wed, Jan 18, 2012 at 11:07 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >>> On Wed, Jan 18, 2012 at 9:46 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >>>>> 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? >>> >>> for example: acpi said one peer root bus should be in [0,20) : the default link. >>> other peer root bus could be [80,a0). >>> chipset will route bus other than [80,a0) all to default link. >>> >>> One transparent bridge 00:1c.0 will have 10:00.0 and 10:01.0 >>> >>> 10:01.0 is cardbus bridge, if it states with bus [1e-22). >>> >>> bus 20-22 still can be accessible. >> >> I think you're suggesting that a host bridge bus number aperture might >> be larger than ACPI reports, and that we should somehow accommodate >> that, i.e., something like this: >> >> ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-1f]) >> pci 0000:00:1c.0: PCI bridge to [bus [10-22] >> pci 0000:10:01.0: CardBus bridge to [bus 1e-22] >> pci 0000:1e:00.0: PCI bridge to [bus 20] >> pci 0000:20:00.0: >> >> With my patches, we'd refuse to scan behind the bridge at 1e:00.0, and >> I think you're suggesting that we *should* scan behind it. > > could extend pci_host_bridge to have secondary resource list to take > more than bus range. > > and later could use those range to find valid bus range for children > bridges. or even transparent bridge chain. >> >> I'm dubious. How do you propose to identify a "default" host bridge >> where we should ignore the bus range from _CRS? Is there a real >> machine like this? If so, how does Windows handle this? > > AMD HT chain have this default link setting. > > i don't know how other os is doing this. ACPI gives us an abstract model of the machine. My goal is to make Linux work as well with that abstract model as possible. There will be exceptions where the model is wrong or incomplete, and we can deal with those as exceptions, i.e., quirks, as we find them. For any abstraction, one can dream up scenarios that don't fit exactly or can't be described completely. I don't think we should worry about those scenarios until they become a real problem. I'm not interested in kludging up generic code to deal with random things that "could" happen. In the case you describe, ACPI is sufficiently expressive to correctly describe a bus number aperture. You're proposing that we add a "default bridge" concept to work around a hypothetical broken ACPI description. I'm not convinced that's necessary. If you have a real machine that would require it, let's see the specifics. 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
