Re: [Qemu-devel] [RFC PATCH] ssi-sd: Make devices picking up backends unavailable with -device

[Peter Maydell]

On 26 September 2018 at 12:40, Markus Armbruster <address@hidden> wrote:
> Thomas Huth <address@hidden> writes:
>
>> On 2018-09-26 11:00, 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 provide an SSI bus.
>>>
>>> Signed-off-by: Markus Armbruster <address@hidden>
>>> ---
>>> Are there valid uses of -device ssi-sd?  If no, this patch is fine.
>>> If yes, this patch breaks them.  But fixing the FIXME will also break
>>> them.  What should we do?
>>>
>>>  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..ec7c7e6dbf 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->cannot_instantiate_with_device_add_yet = true;
>>
>> s/cannot_instantiate_with_device_add_yet = true/user_creatable = false/
>
> Whoops, sent the pre-rebase patch instead of the post-rebase patch.
>
>> Sounds like a good idea to me, if somebody then still needs this for
>> "-device", they should fix the FIXME first.
>
> Peter, what do you think?

Seems fine to me.

thanks
-- PMM