Device models aren't supposed to go on fishing expeditions for
backends. They should expose suitable properties for the user to set.
For onboard devices, board code sets them.
"sdhci-pci" picks up its block backend in its realize() method with
drive_get_next() instead. Already marked FIXME. See the commit that
added the FIXME for a more detailed explanation of what's wrong.
We can't fix this in time for the release, but since the device is new
in 2.3, we can set cannot_instantiate_with_device_add_yet to disable
it before this mistake becomes ABI, and we have to support command
lines like
$ qemu -drive if=sd -drive if=sd,file=sd.img -device sdhci-pci -device
sdhci-pci
forever.
Signed-off-by: Markus Armbruster <arm...@redhat.com>
---
hw/sd/sdhci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index f056c52..ab13505 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1254,6 +1254,8 @@ static void sdhci_pci_class_init(ObjectClass *klass, void
*data)
set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
dc->vmsd = &sdhci_vmstate;
dc->props = sdhci_properties;
+ /* Reason: realize() method uses drive_get_next() */
+ dc->cannot_instantiate_with_device_add_yet = true;
}
static const TypeInfo sdhci_pci_info = {
--
1.9.3
