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.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
v2:
* Rebase to master
* Improve commit message

 hw/sd/ssi-sd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/sd/ssi-sd.c b/hw/sd/ssi-sd.c
index 95a143bfba..623d0333e8 100644
--- a/hw/sd/ssi-sd.c
+++ b/hw/sd/ssi-sd.c
@@ -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.17.1

On 2018-10-09 08:08, Markus Armbruster wrote:
> 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.
> 
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> v2:
> * Rebase to master
> * Improve commit message
> 
>  hw/sd/ssi-sd.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/sd/ssi-sd.c b/hw/sd/ssi-sd.c
> index 95a143bfba..623d0333e8 100644
> --- a/hw/sd/ssi-sd.c
> +++ b/hw/sd/ssi-sd.c
> @@ -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 = {
> 

Acked-by: Thomas Huth <thuth@redhat.com>

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

Markus Armbruster <armbru@redhat.com> writes:

> 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.
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> v2:
> * Rebase to master
> * Improve commit message
>
>  hw/sd/ssi-sd.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/hw/sd/ssi-sd.c b/hw/sd/ssi-sd.c
> index 95a143bfba..623d0333e8 100644
> --- a/hw/sd/ssi-sd.c
> +++ b/hw/sd/ssi-sd.c
> @@ -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 = {

On 18 October 2018 at 08:50, Markus Armbruster <armbru@redhat.com> wrote:
> Peter, would you be willing to take this through your ARM tree?

Sure; applied to target-arm.next.

thanks
-- PMM