Change the mt25ql02g/mt25qu02g entries to include SPI_NOR_4B_OPCODES. In
addition, the SPI_NOR_DUAL_READ flag is added to mt25ql02g; this seems
to have been an accidental omission, as mt25ql02g and mt25qu02g should
support the same features.
In addition, the entries are made more specific by matching on the mt25q
extended ID, like it is already done for the smaller n25q derivatives.
It is unclear whether n25q derivatives with 2Gbit exist that do not
support 4B opcodes (like it is the case for sizes up to 512MBit), so we
do not have a match for such variants anymore (as we wouldn't even know
how to name such hypothetical models).
The changes were tested with a mt25qu01g, which should support the same
features as the mt25ql02g/mt25qu02g.
Signed-off-by: Matthias Schiffer <[email protected]>
---
v2:
- add extended ID match
- add back NO_CHIP_ERASE
drivers/mtd/spi-nor/micron-st.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index c224e59820a1..a000a0790ecd 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -180,12 +180,14 @@ static const struct flash_info st_parts[] = {
{ "n25q00a", INFO(0x20bb21, 0, 64 * 1024, 2048,
SECT_4K | USE_FSR | SPI_NOR_QUAD_READ |
NO_CHIP_ERASE) },
- { "mt25ql02g", INFO(0x20ba22, 0, 64 * 1024, 4096,
- SECT_4K | USE_FSR | SPI_NOR_QUAD_READ |
- NO_CHIP_ERASE) },
- { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096,
- SECT_4K | USE_FSR | SPI_NOR_DUAL_READ |
- SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+ { "mt25ql02g", INFO6(0x20ba22, 0x104400, 64 * 1024, 4096,
+ SECT_4K | USE_FSR | SPI_NOR_DUAL_READ |
+ SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
+ NO_CHIP_ERASE) },
+ { "mt25qu02g", INFO6(0x20bb22, 0x104400, 64 * 1024, 4096,
+ SECT_4K | USE_FSR | SPI_NOR_DUAL_READ |
+ SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
+ NO_CHIP_ERASE) },
{ "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
{ "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 0) },
--
2.17.1
On Thu, 2021-10-07 at 14:08 +0200, Matthias Schiffer wrote:
> Change the mt25ql02g/mt25qu02g entries to include SPI_NOR_4B_OPCODES.
> In
> addition, the SPI_NOR_DUAL_READ flag is added to mt25ql02g; this
> seems
> to have been an accidental omission, as mt25ql02g and mt25qu02g
> should
> support the same features.
>
> In addition, the entries are made more specific by matching on the
> mt25q
> extended ID, like it is already done for the smaller n25q
> derivatives.
> It is unclear whether n25q derivatives with 2Gbit exist that do not
> support 4B opcodes (like it is the case for sizes up to 512MBit), so
> we
> do not have a match for such variants anymore (as we wouldn't even
> know
> how to name such hypothetical models).
>
> The changes were tested with a mt25qu01g, which should support the
> same
> features as the mt25ql02g/mt25qu02g.
>
> Signed-off-by: Matthias Schiffer <[email protected]>
> ---
ping
>
> v2:
> - add extended ID match
> - add back NO_CHIP_ERASE
>
> drivers/mtd/spi-nor/micron-st.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-
> nor/micron-st.c
> index c224e59820a1..a000a0790ecd 100644
> --- a/drivers/mtd/spi-nor/micron-st.c
> +++ b/drivers/mtd/spi-nor/micron-st.c
> @@ -180,12 +180,14 @@ static const struct flash_info st_parts[] = {
> { "n25q00a", INFO(0x20bb21, 0, 64 * 1024, 2048,
> SECT_4K | USE_FSR | SPI_NOR_QUAD_READ |
> NO_CHIP_ERASE) },
> - { "mt25ql02g", INFO(0x20ba22, 0, 64 * 1024, 4096,
> - SECT_4K | USE_FSR | SPI_NOR_QUAD_READ |
> - NO_CHIP_ERASE) },
> - { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096,
> - SECT_4K | USE_FSR | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> + { "mt25ql02g", INFO6(0x20ba22, 0x104400, 64 * 1024, 4096,
> + SECT_4K | USE_FSR | SPI_NOR_DUAL_READ |
> + SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
> + NO_CHIP_ERASE) },
> + { "mt25qu02g", INFO6(0x20bb22, 0x104400, 64 * 1024, 4096,
> + SECT_4K | USE_FSR | SPI_NOR_DUAL_READ |
> + SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
> + NO_CHIP_ERASE) },
>
> { "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
> { "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 0) },
Hi Matthias,
On 07/10/21 02:08PM, Matthias Schiffer wrote:
> Change the mt25ql02g/mt25qu02g entries to include SPI_NOR_4B_OPCODES. In
> addition, the SPI_NOR_DUAL_READ flag is added to mt25ql02g; this seems
> to have been an accidental omission, as mt25ql02g and mt25qu02g should
> support the same features.
The way flags are specified are changed a bit. See [0]. Please re-roll
your patch to use the new flag types. If this flash supports SFDP you
should ideally just need to set the sfdp flag to true and the core
should take care of the rest. Test reports with the new changes would be
much appreciated :-)
>
> In addition, the entries are made more specific by matching on the mt25q
> extended ID, like it is already done for the smaller n25q derivatives.
> It is unclear whether n25q derivatives with 2Gbit exist that do not
> support 4B opcodes (like it is the case for sizes up to 512MBit), so we
> do not have a match for such variants anymore (as we wouldn't even know
> how to name such hypothetical models).
Sounds good to me.
>
> The changes were tested with a mt25qu01g, which should support the same
> features as the mt25ql02g/mt25qu02g.
>
> Signed-off-by: Matthias Schiffer <[email protected]>
> ---
>
[0] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=275622&state=%2A&archive=both
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
On Fri, 2021-12-17 at 00:22 +0530, Pratyush Yadav wrote:
> Hi Matthias,
>
> On 07/10/21 02:08PM, Matthias Schiffer wrote:
> > Change the mt25ql02g/mt25qu02g entries to include
> > SPI_NOR_4B_OPCODES. In
> > addition, the SPI_NOR_DUAL_READ flag is added to mt25ql02g; this
> > seems
> > to have been an accidental omission, as mt25ql02g and mt25qu02g
> > should
> > support the same features.
>
> The way flags are specified are changed a bit. See [0]. Please re-
> roll
> your patch to use the new flag types. If this flash supports SFDP
> you
> should ideally just need to set the sfdp flag to true and the core
> should take care of the rest. Test reports with the new changes would
> be
> much appreciated :-)
Will do. Is there an easy way to check which features the kernel
detected from the SFDP with the new code?
>
> > In addition, the entries are made more specific by matching on the
> > mt25q
> > extended ID, like it is already done for the smaller n25q
> > derivatives.
> > It is unclear whether n25q derivatives with 2Gbit exist that do not
> > support 4B opcodes (like it is the case for sizes up to 512MBit),
> > so we
> > do not have a match for such variants anymore (as we wouldn't even
> > know
> > how to name such hypothetical models).
>
> Sounds good to me.
>
> > The changes were tested with a mt25qu01g, which should support the
> > same
> > features as the mt25ql02g/mt25qu02g.
> >
> > Signed-off-by: Matthias Schiffer <[email protected]
> > >
> > ---
> >
>
> [0]
> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=275622&state=%2A&archive=both
>
On 17/12/21 11:07AM, Matthias Schiffer wrote:
> On Fri, 2021-12-17 at 00:22 +0530, Pratyush Yadav wrote:
> > Hi Matthias,
> >
> > On 07/10/21 02:08PM, Matthias Schiffer wrote:
> > > Change the mt25ql02g/mt25qu02g entries to include
> > > SPI_NOR_4B_OPCODES. In
> > > addition, the SPI_NOR_DUAL_READ flag is added to mt25ql02g; this
> > > seems
> > > to have been an accidental omission, as mt25ql02g and mt25qu02g
> > > should
> > > support the same features.
> >
> > The way flags are specified are changed a bit. See [0]. Please re-
> > roll
> > your patch to use the new flag types. If this flash supports SFDP
> > you
> > should ideally just need to set the sfdp flag to true and the core
> > should take care of the rest. Test reports with the new changes would
> > be
> > much appreciated :-)
>
> Will do. Is there an easy way to check which features the kernel
> detected from the SFDP with the new code?
Hm, I don't think so. I think you would have to add debug prints in the
driver to know which flags were discovered by SFDP.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.