On 20 December 2015 at 20:51, Peter Crosthwaite
<crosthwaitepe...@gmail.com> wrote:
> On Sun, Dec 20, 2015 at 9:10 AM, Peter Maydell <peter.mayd...@linaro.org>
> wrote:
>> On 19 December 2015 at 21:38, Peter Crosthwaite
>> <crosthwaitepe...@gmail.com> 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 :-)
thanks
-- PMM
