[PATCH] mtd: spi-nor: micron-st: Add support for mt25qu01g

[Fabio Estevam]

Hi Tudor,

On Wed, Oct 25, 2023 at 12:34 AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:

> you probably just got lucky, the SFDP tables are just 32bit data. You
> actually have to have that table defined in the SFDP space.

Oh, I see.

It's unfortunate that SFDP_SCCR_MAP_MC_ID is not defined in this SPI NOR flash.

> Check the jesd216 sfdp standard and look into the SFDP Parameter Header
> (section 6.3). Each table has a ID LSB & MSB and a parameter table
> pointer. If the SCCR ID is not there then the table is not defined, thus
> not supported. Let me know what you find. I'll take a look too if you
> have troubles decoding the sfdp dump data. We'd like to add a sfdp
> decoder in the future to ease the process, but it's not something that I
> can allocate time for now.

Thanks for your explanation.

I have downloaded the  jesd216 spec and will take a close look at it.

> > Maybe I can add a fixup that calls spi_nor_parse_sccr_mc()?
>
> I doubt it. You probably need something like s25fs256t_post_sfdp_fixup().

I need to become familiar with the sfdp internals to be able to come
up with a post_sfdp_fixup()
implementation.

In the meantime, could you please consider the v2 proposal?
https://lore.kernel.org/linux-mtd/20231024135826.2729088-1-festevam@gmail.com/T/#u

mt25qu01g is very similar to the already supported mt25qu02g.

In v2, the .size and .no_sfdp_flag fields were removed, which is an
improvement over mt25qu02g.

Only NO_CHIP_ERASE still needs to be passed, but that can be removed
later when the
mt25qu01g_post_sfdp_fixup() is implemented.

Does this sound reasonable?

Thanks