| 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* | expand |
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 >
+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 > >
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); }
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); > } >
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
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
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) },
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(+)