On 10/06/2010 04:44 PM, Bjorn Helgaas wrote: > On Wed, Oct 06, 2010 at 04:26:59PM -0700, H. Peter Anvin wrote: >> On 10/06/2010 04:20 PM, Yinghai Lu wrote: >>> On 10/06/2010 04:17 PM, Bjorn Helgaas wrote: >>>> The AMD doc mentions an enable bit (HIDE_MMCFG_BAR), and I suppose we could >>>> set that and make the whole thing go away. But I sort of hate to add >>>> chipset-specific information unless we have to. >>> >>> that step should be done by BIOS before OS take over. so quirk for specific chipset should be ok. >>> >>> later with system with new chipset, they have chance to fix that in BIOS. >> >> By the way, there is absolutely nothing illogical about using a BAR for >> this configuration; in fact, it is actually documented in the spec that >> this is a possible configuration, since the BARs are accessible via >> CF8-CFC. They are real BARs just as much as any BAR attached to a host >> bridge -- those addresses of course never appear on the bus since they >> are consumed by the host bridge itself, but that is true for other types >> of BARs as well. > > Did you notice that the BAR end is 0xffffffff, not 0xefffffff? > > The range reported by the BAR is 0xe0000000-0xffffffff. Part of that > (0xe0000000-0xefffffff) is consumed by the host bridge. But the rest > (0xf0000000-0xffffffff) is not. > > If you did catch that, I must be missing something. that chip has extra bug to report wrong range. so just use quirk adjust that resource size. Yinghai -- 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
