On 03/12/2025 17:14, Philippe Mathieu-Daudé wrote:
On 3/12/25 16:51, Zhao Liu wrote:
Hi Philippe,
diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index 82c3e7c855b..6dc9f64b74d 100644
--- a/hw/sparc64/sun4u.c
+++ b/hw/sparc64/sun4u.c
@@ -683,14 +683,7 @@ static void sun4uv_init(MemoryRegion *address_space_mem,
graphic_width, graphic_height, graphic_depth,
(uint8_t *)&macaddr);
- dev = qdev_new(TYPE_FW_CFG_IO);
- qdev_prop_set_bit(dev, "dma_enabled", false);
- object_property_add_child(OBJECT(ebus), TYPE_FW_CFG, OBJECT(dev));
There's another difference: fw_cfg_init_io_nodma() uses `machine` as the
parent and here sun4uv uses `ebus`.
Ah yeah I wanted to comment it but forgot :facepalm:
I think maybe one reason to use `ebus` is because...
- sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
- memory_region_add_subregion(pci_address_space_io(ebus), BIOS_CFG_IOPORT,
^^^^^^^^^^^^^^^^^^^^^^^^^^
... because the parent region is managed by ebus.
Perhaps we should add another argument: Object *parent?
I thought about it but don't think so, all instances but this one use
the machine container.
I'll improve the description.
The reason that the fw_cfg device lives under ebus on sun4u is because the ebus
device is effectively a PCI-ISA bridge, and the fw_cfg port is mapped into I/O
address space along with other ISA devices. I'm not sure that setting the parent to
the machine is the right thing to do here.
ATB,
Mark.
