Skip to contentSkip to conversation

ssi-sd: Make devices picking up backends unavailable with -device

PATCH In review Markus Armbruster 3 participants 4 messages Oct 9, 2018 – Oct 18, 2018

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 ssi-sd: Make devices picking up backends unavailable with -device

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.

Device ssi-sd picks up its block backend in its init() method with drive_get_next() instead. This mistake is already marked FIXME since commit af9e40a.

Unset user_creatable to remove the mistake from our external interface. Since the SSI bus doesn't support hotplug, only -device can be affected. Only certain ARM machines have ssi-sd and provide an SSI bus for it; this patch breaks -device ssi-sd for these machines. No actual use of -device ssi-sd is known.

---
v2:
* Rebase to master
* Improve commit message

 hw/sd/ssi-sd.c | 2 ++
 1 file changed, 2 insertions(+)
hw/sd/ssi-sd.c +2 -0
index 95a143bfba..623d0333e8 100644
@@ -284,6 +284,8 @@ static void ssi_sd_class_init(ObjectClass *klass, void *data)
     k->cs_polarity = SSI_CS_LOW;
     dc->vmsd = &vmstate_ssi_sd;
     dc->reset = ssi_sd_reset;
+    /* Reason: init() method uses drive_get_next() */
+    dc->user_creatable = false;
 }
 
 static const TypeInfo ssi_sd_info = {
Signature · 1 line
2.17.1
Acked-by on v2 1/1
#1 lore raw
Quoted 30 lines · Markus Armbruster

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.

Device ssi-sd picks up its block backend in its init() method with drive_get_next() instead. This mistake is already marked FIXME since commit af9e40a.

Unset user_creatable to remove the mistake from our external interface. Since the SSI bus doesn't support hotplug, only -device can be affected. Only certain ARM machines have ssi-sd and provide an SSI bus for it; this patch breaks -device ssi-sd for these machines. No actual use of -device ssi-sd is known.

---
v2:
* Rebase to master
* Improve commit message

 hw/sd/ssi-sd.c | 2 ++
 1 file changed, 2 insertions(+)
hw/sd/ssi-sd.c +0 -0
index 95a143bfba..623d0333e8 100644

hw/sd/ssi-sd.c static void ssi_sd_class_init(ObjectClass *klass, void *data) · line 291

Quoted 8 lines
hw/sd/ssi-sd.c +2 -0
@@ -284,6 +284,8 @@ static void ssi_sd_class_init(ObjectClass *klass, void *data)
     k->cs_polarity = SSI_CS_LOW;
     dc->vmsd = &vmstate_ssi_sd;
     dc->reset = ssi_sd_reset;
+    /* Reason: init() method uses drive_get_next() */
+    dc->user_creatable = false;
 }
 
 static const TypeInfo ssi_sd_info = {
#2 lore raw
In reply to Markus Armbruster

Peter, would you be willing to take this through your ARM tree?

Quoted 37 lines · Markus Armbruster

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.

Device ssi-sd picks up its block backend in its init() method with drive_get_next() instead. This mistake is already marked FIXME since commit af9e40a.

Unset user_creatable to remove the mistake from our external interface. Since the SSI bus doesn't support hotplug, only -device can be affected. Only certain ARM machines have ssi-sd and provide an SSI bus for it; this patch breaks -device ssi-sd for these machines. No actual use of -device ssi-sd is known.

---
v2:
* Rebase to master
* Improve commit message

 hw/sd/ssi-sd.c | 2 ++
 1 file changed, 2 insertions(+)
hw/sd/ssi-sd.c +2 -0
index 95a143bfba..623d0333e8 100644
@@ -284,6 +284,8 @@ static void ssi_sd_class_init(ObjectClass *klass, void *data)
     k->cs_polarity = SSI_CS_LOW;
     dc->vmsd = &vmstate_ssi_sd;
     dc->reset = ssi_sd_reset;
+    /* Reason: init() method uses drive_get_next() */
+    dc->user_creatable = false;
 }
 
 static const TypeInfo ssi_sd_info = {
#3 lore raw
Quoted 1 line · Markus Armbruster

Peter, would you be willing to take this through your ARM tree?

Sure; applied to target-arm.next.

thanks
-- PMM