On 7/21/20 10:36 AM, Cédric Le Goater wrote: > Hello, > > On 2/6/20 7:32 PM, Guenter Roeck wrote: >> When requesting JEDEC data using the JEDEC_READ command, the Linux kernel >> always requests 6 bytes. The current implementation only returns three >> bytes, and interprets the remaining three bytes as new commands. >> While this does not matter most of the time, it is at the very least >> confusing. To avoid the problem, always report up to 6 bytes of JEDEC >> data. Fill remaining data with 0. >> >> Signed-off-by: Guenter Roeck <li...@roeck-us.net> >> --- >> v2: Split patch into two parts; improved decription >> >> hw/block/m25p80.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c >> index 5ff8d270c4..53bf63856f 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; >> + } > > This is breaking an old firmware (Linux version 2.6.28.9) for a SuperMicro > board : > > https://www.supermicro.com/en/products/motherboard/X11SSL-F > > which expects the flash ID to repeat. Erik solved the problem with the patch > below and I think it makes sense to wrap around. Anyone knows what should be > the expected behavior ? >
No idea what the expected behavior is, but I am fine with the code below if it works. Thanks, Guenter > Thanks, > > C. > > > diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c > index 8227088441..5000930800 100644 > --- a/hw/block/m25p80.c > +++ b/hw/block/m25p80.c > @@ -1041,7 +1041,7 @@ static void decode_new_cmd(Flash *s, uint32_t value) > s->data[i] = s->pi->id[i]; > } > for (; i < SPI_NOR_MAX_ID_LEN; i++) { > - s->data[i] = 0; > + s->data[i] = s->pi->id[i % s->pi->id_len]; > } > > s->len = SPI_NOR_MAX_ID_LEN; >