> From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx] > On Thu, May 28, 2015 at 11:24:45PM +0000, Tang, Jason (ES) wrote: > > Correct, in cases where some faulty hardware requests less memory than it > > really needs. > > Hmm. This sounds potentially problematic. Does the device have a BAR that > reports a size smaller than what the device actually responds to, e.g., the > BAR says it's 1MB, but the device actually responds to 2MB of space? Yes, on a custom PCI endpoint, it had a BAR smaller than actually used. > > The two places where I see 'is_hotplug_bridge' set are in > > quirk_hotplug_bridge() and in set_pcie_hotplug_bridge(). Both of these > > check that the bridge is a particular type (a PLX 6254, or if the device > > has the PCI_>QP_SLTCAP_HPC capability). What I propose is a more > general > > purpose that works for any PCI bridge. > > Right. Do we set that bit for your bridge? Those two places certainly > don't cover all the cases: the quirk only applies to one specific device, > and the other only works for bridges with native PCIe hotplug. > > If you have a different kind of bridge, is_hotplug_bridge won't be set, but > it probably should be. What sort of bridge do you have? This bridge is a COTS bridge, with no special hotplugging capabilities. I have a need to hot-add things underneath that bridge. Yes, this will probably void various warranties, but in testing I have found it is electrically safe to do so. > This sounds like two Linux bugs: 1) we don't set is_hotplug_bridge for some > bridges that support hotplug, and 2) we don't reserve any bus numbers for > bridges that support hotplug. If we can fix those in a generic way, it > will be more useful than adding a lot of code to allow users to manually > work around the bugs. How about: 1) Let hotplugged bridges reserve bus numbers, and then 2) let users declare certain bridges as hotplugable, in addition to existing checks? -- 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
