From: Bin Meng <bmeng.cn@gmail.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Bin Meng <bin.meng@windriver.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: [PATCH] hw/sd: sd: Bypass the RCA check for CMD13 in SPI mode
Date: Mon, 8 Feb 2021 22:00:44 +0800 [thread overview]
Message-ID: <CAEUhbmWr4o0AgmKiknkd9W9SEjfNVCcF8g_pw3G2=u6WDqgDuw@mail.gmail.com> (raw)
In-Reply-To: <CAEUhbmWP50LZZaoE8a3mEbYH5XUgqLSNrcAy5oCmH9NMzuTXZg@mail.gmail.com>
On Mon, Feb 8, 2021 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Philippe,
>
> On Mon, Feb 8, 2021 at 9:08 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >
> > On 1/30/21 11:20 AM, Bin Meng wrote:
> > > Hi Philippe,
> > >
> > > On Fri, Jan 29, 2021 at 10:11 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > >>
> > >> Hi Bin,
> > >>
> > >> On 1/29/21 9:51 AM, Bin Meng wrote:
> > >>> From: Bin Meng <bin.meng@windriver.com>
> > >>>
> > >>> Unlike SD mode, when SD card is working in SPI mode, the argument
> > >>> of CMD13 is stuff bits. Hence we should bypass the RCA check.
> > >>
> > >> Is this for detecting events by polling? From spec v8:
> > >>
> > >> 5.7.5 Event Indication Method
> > >> 5.7.5.1 FX_EVENT (Bit06 of Card Status)
> > >>
> > >> An event indication method is introduced from Version 4.20.
> > >> Card may use Bit06 of R1 (R1b) response of any SD command
> > >> to indicate event generation.
> > >>
> > >> F.2 Concept of Event Detection Method
> > >> F.2.2 Host Implementation to use Event Detection Method
> > >>
> > >
> > > I think you looked at the wrong place. See spec v8
> > >
> > > chapter 7.3.1.3 Detailed Command Description
> > >
> > > "The card shall ignore stuff bits and reserved bits in an argument"
> > >
> > > and Table 7-3 Commands and Arguments
> > >
> > > CMD13 Argument [31:0] stuff bits
> >
> > Indeed. Adding this information in the commit description makes
> > things obvious ;)
>
> I thought that's already obvious. If you search for "stuff bits" or
> "CMD13" in the spec, you will get the information.
>
> >
> > The SPI responses are not well implemented, in this case (CMD13)
> > it is incorrect, we should return a 2-byte R2. Your patch
> > correctly skip the RCA check, but we still invalid data.
>
> This is already handled in ssi-sd.c in SPI mode. As for the SD mode,
> that should be a separate patch instead of mixing two fixes into one.
Sigh, I should have checked the spec before I replied.
The CMD13 response for SD card is R1. Only SPI mode is R2. As I
mentioned SPI mode R2 is already handled in ssi-sd.c, so there is
nothing wrong here.
Regards,
Bin
prev parent reply other threads:[~2021-02-08 20:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 8:51 [PATCH] hw/sd: sd: Bypass the RCA check for CMD13 in SPI mode Bin Meng
2021-01-29 14:11 ` Philippe Mathieu-Daudé
2021-01-30 10:20 ` Bin Meng
2021-02-08 13:08 ` Philippe Mathieu-Daudé
2021-02-08 13:55 ` Bin Meng
2021-02-08 14:00 ` Bin Meng [this message]
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='CAEUhbmWr4o0AgmKiknkd9W9SEjfNVCcF8g_pw3G2=u6WDqgDuw@mail.gmail.com' \
--to=bmeng.cn@gmail.com \
--cc=bin.meng@windriver.com \
--cc=f4bug@amsat.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).