[U-Boot,RFT,3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
diff mbox series

Message ID 20190924055617.20397-4-vigneshr@ti.com
State Changes Requested
Delegated to: Jagannadha Sutradharudu Teki
Headers show
Series
  • spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
Related show

Commit Message

Vignesh Raghavendra Sept. 24, 2019, 5:56 a.m. UTC
Newer variants of n25q256* and n25q512* flashes support 4 Byte
addressing opcodes. Add entries for the same. These flashes Bit 6 set in
5th byte of READ ID response.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
 drivers/mtd/spi/spi-nor-ids.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Simon Goldschmidt Sept. 24, 2019, 11:47 a.m. UTC | #1
On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>
> Newer variants of n25q256* and n25q512* flashes support 4 Byte
> addressing opcodes. Add entries for the same. These flashes Bit 6 set in
> 5th byte of READ ID response.
>
> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> ---
>  drivers/mtd/spi/spi-nor-ids.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 967537eafb55..0074073b123a 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
>         { INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>         { INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>         { INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
> +       { INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },

From the discussion in the other thread, this should probably be named
"mt25-something"? Seems like the 0x44 in the 5th byte wouldn't be found in the
n25q256a?

Regards,
Simon

>         { INFO("n25q256a",    0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> +       { INFO6("n25q256ax1",  0x20bb19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>         { INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
>         { INFO6("mt25qu512a (n25q512a)",  0x20bb20, 0x104400, 64 * 1024, 1024,
>                  SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>         { INFO("n25q512a",    0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> +       { INFO6("n25q512ax3",  0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>         { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
>         { INFO("n25q00",      0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>         { INFO("n25q00a",     0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> --
> 2.23.0
>
Simon Goldschmidt Sept. 24, 2019, 11:49 a.m. UTC | #2
+Tudor Ambarus (from discussion in https://patchwork.ozlabs.org/patch/1160501/)

On Tue, Sep 24, 2019 at 1:47 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
> >
> > Newer variants of n25q256* and n25q512* flashes support 4 Byte
> > addressing opcodes. Add entries for the same. These flashes Bit 6 set in
> > 5th byte of READ ID response.
> >
> > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> > ---
> >  drivers/mtd/spi/spi-nor-ids.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > index 967537eafb55..0074073b123a 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
> >         { INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
> >         { INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
> >         { INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
> > +       { INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>
> From the discussion in the other thread, this should probably be named
> "mt25-something"? Seems like the 0x44 in the 5th byte wouldn't be found in the
> n25q256a?
>
> Regards,
> Simon
>
> >         { INFO("n25q256a",    0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > +       { INFO6("n25q256ax1",  0x20bb19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> >         { INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
> >         { INFO6("mt25qu512a (n25q512a)",  0x20bb20, 0x104400, 64 * 1024, 1024,
> >                  SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> >         { INFO("n25q512a",    0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> > +       { INFO6("n25q512ax3",  0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> >         { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> >         { INFO("n25q00",      0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >         { INFO("n25q00a",     0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > --
> > 2.23.0
> >
Ambarus Tudor Sept. 24, 2019, 12:24 p.m. UTC | #3
Hi, Simon,

On 09/24/2019 02:47 PM, Simon Goldschmidt wrote:
> External E-Mail
> 
> 
> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>
>> Newer variants of n25q256* and n25q512* flashes support 4 Byte
>> addressing opcodes. Add entries for the same. These flashes Bit 6 set in
>> 5th byte of READ ID response.
>>
>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
>> ---
>>  drivers/mtd/spi/spi-nor-ids.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
>> index 967537eafb55..0074073b123a 100644
>> --- a/drivers/mtd/spi/spi-nor-ids.c
>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>> @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
>>         { INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>>         { INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>         { INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>> +       { INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> 
> From the discussion in the other thread, this should probably be named
> "mt25-something"? Seems like the 0x44 in the 5th byte wouldn't be found in the
> n25q256a?
> 

Probably yes, but the ultimate test would be to dump all the JEDEC ID bytes from
the n25q256a flash, with code similar to that from below. It's not the first
time that we see manufacturers messing with the JEDEC IDs or with the SFDP
tables. It would be really helpful if you can dump the JEDEC ID bytes on a n25q256a.

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 1acff745d1a2..0be3496c5367 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -885,13 +885,16 @@ static const struct flash_info *spi_nor_read_id(struct
spi_nor *nor)
        info = spi_nor_ids;
        for (; info->name; info++) {
                if (info->id_len) {
-                       if (!memcmp(info->id, id, info->id_len))
+                       if (!memcmp(info->id, id, info->id_len)) {
+                               dev_err(nor->dev, "JEDEC id bytes: %*ph\n",
+                                       SPI_NOR_MAX_ID_LEN, id);
                                return info;
+                       }
                }
        }

-       dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
-               id[0], id[1], id[2]);
+        dev_err(nor->dev, "unrecognized JEDEC id bytes: %*ph\n",
+                SPI_NOR_MAX_ID_LEN, id);
        return ERR_PTR(-ENODEV);
 }
Vignesh Raghavendra Sept. 25, 2019, 8:21 a.m. UTC | #4
Simon,

On 24/09/19 5:54 PM, Tudor.Ambarus@microchip.com wrote:
> Hi, Simon,
> 
> On 09/24/2019 02:47 PM, Simon Goldschmidt wrote:
>> External E-Mail
>>
>>
>> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>>
>>> Newer variants of n25q256* and n25q512* flashes support 4 Byte
>>> addressing opcodes. Add entries for the same. These flashes Bit 6 set in
>>> 5th byte of READ ID response.
>>>
>>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
>>> ---
>>>  drivers/mtd/spi/spi-nor-ids.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
>>> index 967537eafb55..0074073b123a 100644
>>> --- a/drivers/mtd/spi/spi-nor-ids.c
>>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>>> @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
>>>         { INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>>>         { INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>>         { INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>> +       { INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>>
>> From the discussion in the other thread, this should probably be named
>> "mt25-something"? Seems like the 0x44 in the 5th byte wouldn't be found in the
>> n25q256a?
>>

Sorry, I thought mt25 parts are also marked as n25q based on your
replies.. For now, I believe we can assume all devices with 0x44 in the
5th byte are mt25 parts and support 4 byte opcodes. Will next v2 with
this assumptions.

Regards
Vignesh

> 
> Probably yes, but the ultimate test would be to dump all the JEDEC ID bytes from
> the n25q256a flash, with code similar to that from below. It's not the first
> time that we see manufacturers messing with the JEDEC IDs or with the SFDP
> tables. It would be really helpful if you can dump the JEDEC ID bytes on a n25q256a.
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 1acff745d1a2..0be3496c5367 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -885,13 +885,16 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor)
>         info = spi_nor_ids;
>         for (; info->name; info++) {
>                 if (info->id_len) {
> -                       if (!memcmp(info->id, id, info->id_len))
> +                       if (!memcmp(info->id, id, info->id_len)) {
> +                               dev_err(nor->dev, "JEDEC id bytes: %*ph\n",
> +                                       SPI_NOR_MAX_ID_LEN, id);
>                                 return info;
> +                       }
>                 }
>         }
> 
> -       dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
> -               id[0], id[1], id[2]);
> +        dev_err(nor->dev, "unrecognized JEDEC id bytes: %*ph\n",
> +                SPI_NOR_MAX_ID_LEN, id);
>         return ERR_PTR(-ENODEV);
>  }
>
Simon Goldschmidt Sept. 25, 2019, 8:27 a.m. UTC | #5
Hi Vignesh,

On Wed, Sep 25, 2019 at 10:20 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>
> Simon,
>
> On 24/09/19 5:54 PM, Tudor.Ambarus@microchip.com wrote:
> > Hi, Simon,
> >
> > On 09/24/2019 02:47 PM, Simon Goldschmidt wrote:
> >> External E-Mail
> >>
> >>
> >> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
> >>>
> >>> Newer variants of n25q256* and n25q512* flashes support 4 Byte
> >>> addressing opcodes. Add entries for the same. These flashes Bit 6 set in
> >>> 5th byte of READ ID response.
> >>>
> >>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> >>> ---
> >>>  drivers/mtd/spi/spi-nor-ids.c | 3 +++
> >>>  1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> >>> index 967537eafb55..0074073b123a 100644
> >>> --- a/drivers/mtd/spi/spi-nor-ids.c
> >>> +++ b/drivers/mtd/spi/spi-nor-ids.c
> >>> @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
> >>>         { INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
> >>>         { INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
> >>>         { INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
> >>> +       { INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> >>
> >> From the discussion in the other thread, this should probably be named
> >> "mt25-something"? Seems like the 0x44 in the 5th byte wouldn't be found in the
> >> n25q256a?
> >>
>
> Sorry, I thought mt25 parts are also marked as n25q based on your
> replies.. For now, I believe we can assume all devices with 0x44 in the
> 5th byte are mt25 parts and support 4 byte opcodes. Will next v2 with
> this assumptions.

Well, that's my fault. Seems I mixed up the parts here. Our switch to mt25 was
earlier than I had thought and I was using boards with mt25 where I thought I
had n25q before me... Sorry for the confusion!

I can however not tell you if all mt25 chips support 4 byte opcodes. The ones
I have do though.

Oh, and there are also Altera/Intel EPCQ devices (e.g. on the socfpga_socrates)
that are reported as n25q256a. I'd have to look at them as well to see if 4
byte opcodes are supported and what the full ID is.

Regards,
Simon

>
> Regards
> Vignesh
>
> >
> > Probably yes, but the ultimate test would be to dump all the JEDEC ID bytes from
> > the n25q256a flash, with code similar to that from below. It's not the first
> > time that we see manufacturers messing with the JEDEC IDs or with the SFDP
> > tables. It would be really helpful if you can dump the JEDEC ID bytes on a n25q256a.
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index 1acff745d1a2..0be3496c5367 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -885,13 +885,16 @@ static const struct flash_info *spi_nor_read_id(struct
> > spi_nor *nor)
> >         info = spi_nor_ids;
> >         for (; info->name; info++) {
> >                 if (info->id_len) {
> > -                       if (!memcmp(info->id, id, info->id_len))
> > +                       if (!memcmp(info->id, id, info->id_len)) {
> > +                               dev_err(nor->dev, "JEDEC id bytes: %*ph\n",
> > +                                       SPI_NOR_MAX_ID_LEN, id);
> >                                 return info;
> > +                       }
> >                 }
> >         }
> >
> > -       dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
> > -               id[0], id[1], id[2]);
> > +        dev_err(nor->dev, "unrecognized JEDEC id bytes: %*ph\n",
> > +                SPI_NOR_MAX_ID_LEN, id);
> >         return ERR_PTR(-ENODEV);
> >  }
> >
>
> --
> Regards
> Vignesh
Vignesh Raghavendra Sept. 25, 2019, 9:09 a.m. UTC | #6
On 25/09/19 1:57 PM, Simon Goldschmidt wrote:
> Hi Vignesh,
> 
> On Wed, Sep 25, 2019 at 10:20 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>
>> Simon,
>>
>> On 24/09/19 5:54 PM, Tudor.Ambarus@microchip.com wrote:
>>> Hi, Simon,
>>>
>>> On 09/24/2019 02:47 PM, Simon Goldschmidt wrote:
>>>> External E-Mail
>>>>
>>>>
>>>> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>>>>
>>>>> Newer variants of n25q256* and n25q512* flashes support 4 Byte
>>>>> addressing opcodes. Add entries for the same. These flashes Bit 6 set in
>>>>> 5th byte of READ ID response.
>>>>>
>>>>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
>>>>> ---
>>>>>  drivers/mtd/spi/spi-nor-ids.c | 3 +++
>>>>>  1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
>>>>> index 967537eafb55..0074073b123a 100644
>>>>> --- a/drivers/mtd/spi/spi-nor-ids.c
>>>>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>>>>> @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
>>>>>         { INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>>         { INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>>         { INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>> +       { INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>>>>
>>>> From the discussion in the other thread, this should probably be named
>>>> "mt25-something"? Seems like the 0x44 in the 5th byte wouldn't be found in the
>>>> n25q256a?
>>>>
>>
>> Sorry, I thought mt25 parts are also marked as n25q based on your
>> replies.. For now, I believe we can assume all devices with 0x44 in the
>> 5th byte are mt25 parts and support 4 byte opcodes. Will next v2 with
>> this assumptions.
> 
> Well, that's my fault. Seems I mixed up the parts here. Our switch to mt25 was
> earlier than I had thought and I was using boards with mt25 where I thought I
> had n25q before me... Sorry for the confusion!
> 
> I can however not tell you if all mt25 chips support 4 byte opcodes. The ones
> I have do though.
> 
> Oh, and there are also Altera/Intel EPCQ devices (e.g. on the socfpga_socrates)
> that are reported as n25q256a. I'd have to look at them as well to see if 4
> byte opcodes are supported and what the full ID is.
> 

I will go ahead and post patches with mt25* in the name. If we find
parts with same ID code but sold as n25q* we can rename the entries or
add new ones if ID codes are different.

Regards
Vignesh

> Regards,
> Simon
> 
>>
>> Regards
>> Vignesh
>>
>>>
>>> Probably yes, but the ultimate test would be to dump all the JEDEC ID bytes from
>>> the n25q256a flash, with code similar to that from below. It's not the first
>>> time that we see manufacturers messing with the JEDEC IDs or with the SFDP
>>> tables. It would be really helpful if you can dump the JEDEC ID bytes on a n25q256a.
>>>
>>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>>> index 1acff745d1a2..0be3496c5367 100644
>>> --- a/drivers/mtd/spi/spi-nor-core.c
>>> +++ b/drivers/mtd/spi/spi-nor-core.c
>>> @@ -885,13 +885,16 @@ static const struct flash_info *spi_nor_read_id(struct
>>> spi_nor *nor)
>>>         info = spi_nor_ids;
>>>         for (; info->name; info++) {
>>>                 if (info->id_len) {
>>> -                       if (!memcmp(info->id, id, info->id_len))
>>> +                       if (!memcmp(info->id, id, info->id_len)) {
>>> +                               dev_err(nor->dev, "JEDEC id bytes: %*ph\n",
>>> +                                       SPI_NOR_MAX_ID_LEN, id);
>>>                                 return info;
>>> +                       }
>>>                 }
>>>         }
>>>
>>> -       dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
>>> -               id[0], id[1], id[2]);
>>> +        dev_err(nor->dev, "unrecognized JEDEC id bytes: %*ph\n",
>>> +                SPI_NOR_MAX_ID_LEN, id);
>>>         return ERR_PTR(-ENODEV);
>>>  }
>>>
>>
>> --
>> Regards
>> Vignesh

Patch
diff mbox series

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 967537eafb55..0074073b123a 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -161,11 +161,14 @@  const struct flash_info spi_nor_ids[] = {
 	{ INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
 	{ INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
 	{ INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
+	{ INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
 	{ INFO("n25q256a",    0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ INFO6("n25q256ax1",  0x20bb19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
 	{ INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
 	{ INFO6("mt25qu512a (n25q512a)",  0x20bb20, 0x104400, 64 * 1024, 1024,
 		 SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
 	{ INFO("n25q512a",    0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
+	{ INFO6("n25q512ax3",  0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
 	{ INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
 	{ INFO("n25q00",      0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
 	{ INFO("n25q00a",     0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },