On Wed, 2010-04-07 at 21:42 -0700, H. Peter Anvin wrote: > On 04/07/2010 08:24 PM, Bjorn Helgaas wrote: > > > > I actually did propose doing something in pci_setup_device(), similar to > > what we already do for legacy IDE resources, but HPA thought it should > > be done in the arch code instead, again for reasons I don't completely > > understand. > "Non-PCI devices" is hard to understand? I understand that part, and the patch I posted is for the arch code, as you suggested. I just thought you were suggesting an x86 change *instead* of something in PCI, even though it seems like the PCI spec does mention that devices with VGA class code respond at 0xa0000. Or maybe you were just suggesting that we should do something in *both* PCI and in the arch code? Of course, the PCI part might be complicated by the VGA arbiter, although I would think that if the system contains at least one VGA device, reserving the 0xa0000 region once would solve 99% of the problem. If the arbiter changes the actual device that responds there, the reservation will be for the wrong device, but we still want to avoid putting anything else there. Honestly, I don't know enough about x86_32 vs x86_64 to understand Yinghai's objection. Is there some platform architecture difference that means x86_64 can reliably determine whether a non-PCI VGA device is present, when x86_32 can't? Unless there's a real difference, we ought to handle them both the same, as my patch does. Yinghai mentioned a box with no VGA and another device using 0xa0000. Unless there's some x86_64-specific spec or convention that addresses this, maybe we could handle that by (1) doing the legacy reservation as in this patch, and (2) special-casing the PCI device setup so that if we find a BAR set to that area, we undo the legacy reservation. Or maybe we just leave the legacy reservation unused and relocate the device that BIOS left there. 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
