When probing for ROM BAR size, we should not change bits 1:10 in this BAR, because these bits are marked as "reserved for future use" in PCI spec, so changing them might have side effects. No such issue for I/O or memory, as there is an implementation note in PCI spec which explicitly allows writing 0xfffffffff there. Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> --- drivers/pci/probe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 8105e32..d65aae4 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -163,12 +163,12 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, { u32 l, sz, mask; - mask = type ? ~PCI_ROM_ADDRESS_ENABLE : ~0; + mask = type ? PCI_ROM_ADDRESS_MASK : ~0; res->name = pci_name(dev); pci_read_config_dword(dev, pos, &l); - pci_write_config_dword(dev, pos, mask); + pci_write_config_dword(dev, pos, l | mask); pci_read_config_dword(dev, pos, &sz); pci_write_config_dword(dev, pos, l); -- 1.6.5.rc2 -- 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