Re: [Qemu-devel] [PATCH 04/10] hw/sd: Add QOM bus which SD cards plug in to

[Peter Crosthwaite]

On Sun, Dec 20, 2015 at 3:18 PM, Peter Maydell <address@hidden> wrote:
> On 20 December 2015 at 20:51, Peter Crosthwaite
> <address@hidden> wrote:
>> On Sun, Dec 20, 2015 at 9:10 AM, Peter Maydell <address@hidden> wrote:
>>> On 19 December 2015 at 21:38, Peter Crosthwaite
>>> <address@hidden> wrote:
>>>> On Fri, Dec 11, 2015 at 04:37:05PM +0000, Peter Maydell wrote:
>>>>> +bool sdbus_get_inserted(SDBus *sdbus)
>>>>> +{
>>>>> +    SDState *card = get_card(sdbus);
>>>>> +
>>>>> +    if (card) {
>>>>> +        SDClass *sc = SD_GET_CLASS(card);
>>>>> +
>>>>> +        return sc->get_inserted(card);
>>>>> +    }
>>>>> +
>>>>> +    return false;
>>>>> +}
>>>>
>>>> This I am not sure about. Realistically, the card has no self
>>>> awareness of its ejection state so it can't be polled for "are
>>>> you there". The card insertion switch is implemented as a
>>>> physical switch on the slot itself and a property of the bus.
>>>>
>>>> The absence on presence of a device should determine this, making me
>>>> think this should return !!card.
>>>>
>>>> Unfortunately, we have the case of the block UI being able to trigger a
>>>> card ejection from underneath the bus level. But since the SD card is 
>>>> already
>>>> using qdev_get_parent_bus() the removal from the bus can be managed at the
>>>> card level.
>>>
>>> For user-level back compat I think we need to retain "might have
>>> an sdcard object with no block backend, and that means
>>> 'no-card-present'". This is both for the user facing
>>> monitor commands to manipulate the sd card, and also
>>
>> What are the user-facing monitor commands? I tried using "change" and
>> "eject", but they don't seem to work for SD, due to the tray being
>> closed. Has this ever worked in a way that is user manipulatable for
>> SD or is it just to handle the case of unconditional SD card creation
>> (with the card never hotplugging over the system lifetime)?
>
> I admit to just assuming that this stuff worked rather than
> testing it :-)
>

Can we capitilise on the opportunity here to break the backwards
compat for the non-functional feature and defeature eject and change
for SD? File substitution for SD cards doesn't match the real world
nicely, as we use the file size to modify the SD card implementation
(SDSC vs SDHC as well as the # of blocks). It really should be a
destroy+recreate rather than a substitution.We can then deal with SD
card ejection and insertion as proper hotplug.

Regards,
Peter

> thanks
> -- PMM