v1: === During my PIIX consolidation work [1] I've noticed that both PIIX models have quite different pci_slot_get_pirq() implementations. These functions seem to map PCI INTx pins to input pins of a programmable interrupt router which is AFAIU board-specific. IOW, board-specific assumptions are baked into the device models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC machine.
This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which then allowes for moving the two board-specific PIIX pci_slot_get_pirq() funtions into their respective boards. With these changes, the PIIX4 south bridge could eventually become an alternative to the PIIX3-Frankenstein solution in the PC machine. v2: === * Remove RFC tag from whole series * New patch to split pci_bus_irqs() * Remove VT82xx patch which was just a demonstration Testing done: * `make check` * `make check-avocado` * `qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-5kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=ttyS0"` * `qemu-system-x86_64 -M pc -m 2G -cdrom manjaro-kde-21.3.2-220704-linux515.iso` Thanks, Bernhard [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg03941.html Bernhard Beschow (3): hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs() hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific hw/i386/pc_piix.c | 16 ++++++++++++++++ hw/i386/pc_q35.c | 4 ++-- hw/isa/piix3.c | 17 ++--------------- hw/isa/piix4.c | 27 +-------------------------- hw/mips/malta.c | 28 ++++++++++++++++++++++++++++ hw/pci-host/raven.c | 3 ++- hw/pci-host/versatile.c | 3 ++- hw/pci/pci.c | 12 +++++++++--- hw/remote/machine.c | 3 ++- include/hw/pci/pci.h | 3 ++- 10 files changed, 66 insertions(+), 50 deletions(-) -- 2.38.1
