All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Markus Armbruster <armbru@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-stable <qemu-stable@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 1/2] hw/sd: Add medium insertion status
Date: Thu, 7 Jan 2016 23:00:48 +0100	[thread overview]
Message-ID: <568EE010.1080006@redhat.com> (raw)
In-Reply-To: <CAFEAcA-i6KZa9as-B9SkCxEFcYUboe48iXgdeuEausGUDkvOtg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

On 07.01.2016 22:45, Peter Maydell wrote:
> On 7 January 2016 at 21:03, Max Reitz <mreitz@redhat.com> wrote:
>> Right now, the change_media_cb (sd_cardchange()) completely ignores its
>> @load parameter. This means that issuing a blockdev-open-tray command
>> will actually not have any effect.
>>
>> Fix this by keeping track of the medium insertion status in the SDState
>> and updating it in sd_init() and sd_cardchange().
>>
>> Cc: qemu-stable <qemu-stable@nongnu.org>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>>  hw/sd/sd.c | 16 ++++++++++------
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
>> index 1a9935c..0751ba2 100644
>> --- a/hw/sd/sd.c
>> +++ b/hw/sd/sd.c
>> @@ -114,6 +114,7 @@ struct SDState {
>>      uint8_t *buf;
>>
>>      bool enable;
>> +    bool medium_inserted;
> 
> When would this be different from blk_is_inserted(sd->blk) ?

First, whenever you use a host CD-ROM drive for an SD card. But I highly
doubt this worked before, because the device model is actually never
notified if the medium in the host drive is exchanged.

For any other medium, blk_is_inserted() should generally be always true.

Second, whenever the change_media_cb is called with @load set to false.
This means that the medium is to be unloaded, which was completely
ignored by sd.c so far (see commit message). It just interpreted a call
to sd_cardchange() as a notification that the medium might have changed,
but this is wrong.

> I don't see why we need a separate flag here rather
> than querying the block layer.

Because of the second case.

> If we do need a flag, why doesn't it need to be migrated?

Oh, yes, you're right, it probably should.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-01-07 22:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07 21:03 [Qemu-devel] [PATCH 0/2] hw/sd: Fix medium change Max Reitz
2016-01-07 21:03 ` [Qemu-devel] [PATCH 1/2] hw/sd: Add medium insertion status Max Reitz
2016-01-07 21:38   ` John Snow
2016-01-07 21:45   ` Peter Maydell
2016-01-07 22:00     ` Max Reitz [this message]
2016-01-07 21:03 ` [Qemu-devel] [PATCH 2/2] hw/sd: Implement is_tray_open() BlockDevOp Max Reitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=568EE010.1080006@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.