On Fri, Aug 26, 2011 at 8:51 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi, > > Bjorn Helgaas wrote: > >> [Subject: [PATCH] PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs] > > To users, the more noticeable impact will be that this doesn't claim > all pci-pci bridges with AMD vendor ID any more either, right? The driver normally claims PCI bridges with the SHPC (Standard Hot-plug Controller) capability. That works for all bridges that conform to the SHPC spec. In addition, we have this special case for AMD bridges. Previously, we used the special case for all bridges with device ID 0x7450 and all AMD bridges. The special case ignores the SHPC capability. I suspect the intent of this "quirk" was to deal with an early AMD bridge that didn't conform to the SHPC spec. With my patch, the special case will apply only to the AMD 0x7450 bridge. So we won't treat non-AMD 0x7450 bridges (if any) specially any more. And, as you say, we won't treat AMD non-0x7450 bridges specially either. It's possible that will break SHPC on some AMD bridges, but it's also possible that it will *fix* newer AMD bridges that conform to the spec and supply the SHPC capability. We used to ignore that SHPC capability, and now we'll pay attention to it. So SHPC users with AMD bridges *will* likely notice a difference. Hopefully it's usually that an error message goes away. This seems to be quite common: googling for "shpchp 0000:00:01.0: Cannot reserve MMIO region" found many reports. It could also be that SHPC breaks on AMD non-0x7450 bridges that don't conform to the spec. Or, if we're lucky, SHPC could start working on AMD bridges that *do* conform to the spec. 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
