From: Guenter Roeck <linux@roeck-us.net>
To: "Cédric Le Goater" <clg@kaod.org>,
"Alistair Francis" <alistair@alistair23.me>
Cc: Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
qemu-block@nongnu.org, Andrew Jeffery <andrew@aj.id.au>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
qemu-arm@nongnu.org, Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH 2/3] m25p80: Improve command handling for Jedec and unsupported commands
Date: Tue, 4 Feb 2020 06:28:37 -0800 [thread overview]
Message-ID: <7fe70871-c0e3-4ff6-bfda-17b45aa50c5e@roeck-us.net> (raw)
In-Reply-To: <accf297f-0c54-7475-8817-c1014999a57d@kaod.org>
On 2/4/20 12:53 AM, Cédric Le Goater wrote:
> On 2/3/20 7:09 PM, Guenter Roeck wrote:
>> Always report 6 bytes of JEDEC data. Fill remaining data with 0.
>>
>> For unsupported commands, keep sending a value of 0 until the chip
>> is deselected.
>>
>> Both changes avoid attempts to decode random commands. Up to now this
>> happened if the reported Jedec data was shorter than 6 bytes but the
>> host read 6 bytes, and with all unsupported commands.
>
> Do you have a concrete example for that ? machine and flash model.
>
I noticed it while tracking down the bug fixed in patch 3 of the series,
ie with AST2500 evb using w25q256 flash, but it happens with all machines
using SPI NOR flash (ie all aspeed bmc machines) when running the Linux
kernel. Most of the time it doesn't cause harm, unless the host sends
an "address" as part of an unsupported command which happens to include
a valid command code.
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> ---
>> hw/block/m25p80.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
>> index 63e050d7d3..aca75edcc1 100644
>> --- a/hw/block/m25p80.c
>> +++ b/hw/block/m25p80.c
>> @@ -1040,8 +1040,11 @@ static void decode_new_cmd(Flash *s, uint32_t value)
>> for (i = 0; i < s->pi->id_len; i++) {
>> s->data[i] = s->pi->id[i];
>> }
>> + for (; i < SPI_NOR_MAX_ID_LEN; i++) {
>> + s->data[i] = 0;
>> + }
>
> It seems that data should be reseted in m25p80_cs() also.
>
Are you sure ?
The current implementation sets s->data[] as needed when command decode
is complete. That seems less costly to me.
Thanks,
Guenter
>>
>> - s->len = s->pi->id_len;
>> + s->len = SPI_NOR_MAX_ID_LEN;
>> s->pos = 0;
>> s->state = STATE_READING_DATA;
>> break;
>> @@ -1158,6 +1161,11 @@ static void decode_new_cmd(Flash *s, uint32_t value)
>> s->quad_enable = false;
>> break;
>> default:
>> + s->pos = 0;
>> + s->len = 1;
>> + s->state = STATE_READING_DATA;
>> + s->data_read_loop = true;
>> + s->data[0] = 0;
>> qemu_log_mask(LOG_GUEST_ERROR, "M25P80: Unknown cmd %x\n", value);
>> break;
>> }
>>
>
next prev parent reply other threads:[~2020-02-04 14:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-03 18:09 [PATCH 1/3] m25p80: Convert to support tracing Guenter Roeck
2020-02-03 18:09 ` [PATCH 2/3] m25p80: Improve command handling for Jedec and unsupported commands Guenter Roeck
2020-02-04 8:53 ` Cédric Le Goater
2020-02-04 12:27 ` Philippe Mathieu-Daudé
2020-02-04 14:28 ` Guenter Roeck [this message]
2020-02-05 10:08 ` Cédric Le Goater
2020-02-05 17:43 ` Guenter Roeck
2020-02-06 7:04 ` Joel Stanley
2020-02-06 14:26 ` Guenter Roeck
2020-02-04 12:13 ` Philippe Mathieu-Daudé
2020-02-03 18:09 ` [PATCH 3/3] aspeed/smc: Fix number of dummy cycles for FAST_READ_4 command Guenter Roeck
2020-02-04 7:45 ` Cédric Le Goater
2020-02-04 14:19 ` Guenter Roeck
2020-02-18 11:38 ` Francisco Iglesias
2020-02-03 18:44 ` [PATCH 1/3] m25p80: Convert to support tracing Alistair Francis
2020-02-04 7:16 ` Cédric Le Goater
2020-02-04 14:18 ` Guenter Roeck
2020-02-04 12:08 ` Philippe Mathieu-Daudé
2020-02-05 10:05 ` Cédric Le Goater
2020-02-05 16:35 ` Guenter Roeck
2020-02-05 17:10 ` Cédric Le Goater
2020-02-05 18:34 ` Guenter Roeck
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=7fe70871-c0e3-4ff6-bfda-17b45aa50c5e@roeck-us.net \
--to=linux@roeck-us.net \
--cc=alistair@alistair23.me \
--cc=andrew@aj.id.au \
--cc=clg@kaod.org \
--cc=joel@jms.id.au \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.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).