#
8a8c9c3a |
| 05-Jan-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/pci-host: Use register definitions from PCI standard
No need to document magic values when the definition names from "standard-headers/linux/pci_regs.h" are self-explicit.
Signed-off-by: Philipp
hw/pci-host: Use register definitions from PCI standard
No need to document magic values when the definition names from "standard-headers/linux/pci_regs.h" are self-explicit.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230105173702.56610-1-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bernhard Beschow <shentey@gmail.com>
show more ...
|
#
8a8c9c3a |
| 05-Jan-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/pci-host: Use register definitions from PCI standard
No need to document magic values when the definition names from "standard-headers/linux/pci_regs.h" are self-explicit.
Signed-off-by: Philipp
hw/pci-host: Use register definitions from PCI standard
No need to document magic values when the definition names from "standard-headers/linux/pci_regs.h" are self-explicit.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230105173702.56610-1-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bernhard Beschow <shentey@gmail.com>
show more ...
|
#
edf5ca5d |
| 22-Dec-2022 |
Markus Armbruster <armbru@redhat.com> |
include/hw/pci: Split pci_device.h off pci.h
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBus
include/hw/pci: Split pci_device.h off pci.h
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBusClass and PCIBus in pci_bus.h, PCIBridge in pci_bridge.h, PCIHostBridgeClass and PCIHostState in pci_host.h, PCIExpressHost in pcie_host.h, and PCIERootPortClass, PCIEPort, and PCIESlot in pcie_port.h.
Move PCIDeviceClass and PCIDeviceClass to new pci_device.h, along with the code that needs them. Adjust include directives.
This also enables the next commit.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221222100330.380143-6-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
edf5ca5d |
| 22-Dec-2022 |
Markus Armbruster <armbru@redhat.com> |
include/hw/pci: Split pci_device.h off pci.h
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBus
include/hw/pci: Split pci_device.h off pci.h
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBusClass and PCIBus in pci_bus.h, PCIBridge in pci_bridge.h, PCIHostBridgeClass and PCIHostState in pci_host.h, PCIExpressHost in pcie_host.h, and PCIERootPortClass, PCIEPort, and PCIESlot in pcie_port.h.
Move PCIDeviceClass and PCIDeviceClass to new pci_device.h, along with the code that needs them. Adjust include directives.
This also enables the next commit.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221222100330.380143-6-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
edf5ca5d |
| 22-Dec-2022 |
Markus Armbruster <armbru@redhat.com> |
include/hw/pci: Split pci_device.h off pci.h
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBus
include/hw/pci: Split pci_device.h off pci.h
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBusClass and PCIBus in pci_bus.h, PCIBridge in pci_bridge.h, PCIHostBridgeClass and PCIHostState in pci_host.h, PCIExpressHost in pcie_host.h, and PCIERootPortClass, PCIEPort, and PCIESlot in pcie_port.h.
Move PCIDeviceClass and PCIDeviceClass to new pci_device.h, along with the code that needs them. Adjust include directives.
This also enables the next commit.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221222100330.380143-6-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3 |
|
#
b1fbf242 |
| 29-Nov-2022 |
Igor Mammedov <imammedo@redhat.com> |
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as
remove DEC 21154 PCI bridge
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user.
PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0 |
|
#
443f07b7 |
| 28-Oct-2022 |
BALATON Zoltan <balaton@eik.bme.hu> |
hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.h
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used.
Signed-off-by
hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.h
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <b82449369f718c0e207fe8c332fab550fa0230c0.1666957578.git.balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
show more ...
|
Revision tags: v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0 |
|
#
443f07b7 |
| 28-Oct-2022 |
BALATON Zoltan <balaton@eik.bme.hu> |
hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.h
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used.
Signed-off-by
hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.h
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <b82449369f718c0e207fe8c332fab550fa0230c0.1666957578.git.balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
show more ...
|
Revision tags: v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0 |
|
#
443f07b7 |
| 28-Oct-2022 |
BALATON Zoltan <balaton@eik.bme.hu> |
hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.h
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used.
Signed-off-by
hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.h
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <b82449369f718c0e207fe8c332fab550fa0230c0.1666957578.git.balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
show more ...
|
Revision tags: v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0, v7.0.0, v7.0.0-rc4, v7.0.0-rc3, v7.0.0-rc2, v7.0.0-rc1, v7.0.0-rc0, v6.1.1, v6.2.0, v6.2.0-rc4, v6.2.0-rc3, v6.2.0-rc2, v6.2.0-rc1, v6.2.0-rc0, v6.0.1, v6.1.0, v6.1.0-rc4, v6.1.0-rc3, v6.1.0-rc2, v6.1.0-rc1, v6.1.0-rc0, v6.0.0, v6.0.0-rc5, v6.0.0-rc4, v6.0.0-rc3, v6.0.0-rc2, v6.0.0-rc1, v6.0.0-rc0, v5.2.0, v5.2.0-rc4, v5.2.0-rc3, v5.2.0-rc2, v5.2.0-rc1, v5.2.0-rc0 |
|
#
4934e479 |
| 12-Oct-2020 |
Philippe Mathieu-Daudé <f4bug@amsat.org> |
hw: Use the PCI_DEVFN() macro from 'hw/pci/pci.h'
We already have a generic PCI_DEVFN() macro in "hw/pci/pci.h" to pack the PCI slot/function identifiers, use it.
Signed-off-by: Philippe Mathieu-Da
hw: Use the PCI_DEVFN() macro from 'hw/pci/pci.h'
We already have a generic PCI_DEVFN() macro in "hw/pci/pci.h" to pack the PCI slot/function identifiers, use it.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20201012124506.3406909-6-philmd@redhat.com> Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20201231224911.1467352-4-f4bug@amsat.org>
show more ...
|
#
d08b9c1b |
| 11-Oct-2020 |
Philippe Mathieu-Daudé <f4bug@amsat.org> |
hw/pci-host/uninorth: Use the PCI_FUNC() macro from 'hw/pci/pci.h'
We already have a generic PCI_FUNC() macro in "hw/pci/pci.h" to extract the PCI function identifier, use it.
Signed-off-by: Philip
hw/pci-host/uninorth: Use the PCI_FUNC() macro from 'hw/pci/pci.h'
We already have a generic PCI_FUNC() macro in "hw/pci/pci.h" to extract the PCI function identifier, use it.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20201012124506.3406909-4-philmd@redhat.com>
show more ...
|
#
40a0deb7 |
| 13-Oct-2020 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
uninorth: use qdev gpios for PCI IRQs
Currently an object link property is used to pass a reference to the OpenPIC into the PCI host bridge so that pci_unin_init_irqs() can connect the PCI IRQs to t
uninorth: use qdev gpios for PCI IRQs
Currently an object link property is used to pass a reference to the OpenPIC into the PCI host bridge so that pci_unin_init_irqs() can connect the PCI IRQs to the PIC itself.
This can be simplified by defining the PCI IRQs as qdev gpios and then wiring up the PCI IRQs to the PIC in the New World machine init function.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201013114922.2946-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
show more ...
|
Revision tags: v5.0.1, v5.1.0, v5.1.0-rc3, v5.1.0-rc2, v5.1.0-rc1, v5.1.0-rc0, v4.2.1 |
|
#
d2623129 |
| 05-May-2020 |
Markus Armbruster <armbru@redhat.com> |
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardc
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way.
When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
show more ...
|
Revision tags: v5.0.0, v5.0.0-rc4, v5.0.0-rc3, v5.0.0-rc2, v5.0.0-rc1, v5.0.0-rc0 |
|
#
4f67d30b |
| 10-Jan-2020 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
qdev: set properties with device_class_set_props()
The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter.
spatch --macr
qdev: set properties with device_class_set_props()
The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter.
spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir .
@@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v4.2.0, v4.2.0-rc5, v4.2.0-rc4, v4.2.0-rc3, v4.2.0-rc2, v4.1.1, v4.2.0-rc1, v4.2.0-rc0, v4.0.1, v3.1.1.1, v4.1.0, v4.1.0-rc5 |
|
#
a27bd6c7 |
| 12-Aug-2019 |
Markus Armbruster <armbru@redhat.com> |
Include hw/qdev-properties.h less
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend
Include hw/qdev-properties.h less
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h).
Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead.
hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h.
While there, delete a few superfluous inclusions of hw/qdev-core.h.
Touching hw/qdev-properties.h now recompiles some 1200 objects.
Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
show more ...
|
#
650d103d |
| 12-Aug-2019 |
Markus Armbruster <armbru@redhat.com> |
Include hw/hw.h exactly where needed
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/o
Include hw/hw.h exactly where needed
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h).
The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
show more ...
|
#
64552b6b |
| 12-Aug-2019 |
Markus Armbruster <armbru@redhat.com> |
Include hw/irq.h a lot less
In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h).
Include hw/irq.h a lot less
In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h).
hw/hw.h supposedly includes it for convenience. Several other headers include it just to get qemu_irq and.or qemu_irq_handler.
Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to qemu/typedefs.h, and then include hw/irq.h only where it's still needed. Touching it now recompiles only some 500 objects.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-13-armbru@redhat.com>
show more ...
|
Revision tags: v4.1.0-rc4, v3.1.1, v4.1.0-rc3, v4.1.0-rc2, v4.1.0-rc1, v4.1.0-rc0 |
|
#
0b8fa32f |
| 23-May-2019 |
Markus Armbruster <armbru@redhat.com> |
Include qemu/module.h where needed, drop it from qemu-common.h
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts res
Include qemu/module.h where needed, drop it from qemu-common.h
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
show more ...
|