Message ID | 1427900586-5358-5-git-send-email-armbru@redhat.com |
---|---|
State | New |
Headers | show |
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 = {
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 <armbru@redhat.com> --- hw/sd/sdhci.c | 2 ++ 1 file changed, 2 insertions(+)