| Message ID | 1368545616-22344-2-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | Accepted |
| Commit | 33201b51cbce9f18d6702a56429a4dbbe18a9961 |
| Headers | show |
diff --git a/hw/pci-host/versatile.c b/hw/pci-host/versatile.c index 540daf7..2bb09fa 100644 --- a/hw/pci-host/versatile.c +++ b/hw/pci-host/versatile.c @@ -331,8 +331,6 @@ static void pci_vpb_init(Object *obj) object_initialize(&s->pci_dev, TYPE_VERSATILE_PCI_HOST); qdev_set_parent_bus(DEVICE(&s->pci_dev), BUS(&s->pci_bus)); - object_property_set_int(OBJECT(&s->pci_dev), PCI_DEVFN(29, 0), "addr", - NULL); /* Window sizes for VersatilePB; realview_pci's init will override */ s->mem_win_size[0] = 0x0c000000;
This reverts commit 5f37ef92b7690423ac6311d3c597e182fc5f8fe6. It turns out that some kernels incorrectly depend on the old QEMU behaviour of not putting the host PCI bridge device where the hardware puts it, because they use a swizzling IRQ mapping which is incorrect but happens to match up with old broken QEMU when the slot number mod 4 is zero. Since we start PCI devices at 11, if we put the host bridge at 29 then the first real PCI device goes at 11 and doesn't work. Not putting the host bridge at 29 means it defaults to 11, so the first real PCI device is at 12 and works. Since continuing with the old behaviour doesn't cause problems for kernels which do work with hardware, the simplest fix for this is to revert the change. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- hw/pci-host/versatile.c | 2 -- 1 file changed, 2 deletions(-)