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

[Tudor Ambarus]

On 24.10.2023 19:43, Fabio Estevam wrote:
> On Tue, Oct 24, 2023 at 1:36 PM Michael Walle <michael at walle.cc> wrote:
> 
>> Mhh, that's a pity. It seems that your SFDP in the flash doesn't
>> contain that table. I haven't confirmed it by looking at your dump
>> as I'm about to go on vacation tomorrow and packing right now.
> 
> Just did a hack to force calling  spi_nor_parse_sccr_mc():
> 
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index b3b11dfed789..dc61bb5c4f7f 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -1320,7 +1320,8 @@ static int spi_nor_parse_sccr_mc(struct spi_nor *nor,
>                 params->vreg_offset[i] = dwords[SFDP_DWORD(i) * 2];
> 
>         params->n_dice = n_dice;
> -
> +
> +       pr_err("***** params->n_dice is %d\n", params->n_dice);
>  out:
>         kfree(dwords);
>         return ret;
> @@ -1532,6 +1533,7 @@ int spi_nor_parse_sfdp(struct spi_nor *nor)
> 
>                 case SFDP_4BAIT_ID:
>                          err = spi_nor_parse_4bait(nor, param_header);
> +                       err = spi_nor_parse_sccr_mc(nor, param_header);
>                         break;
> 
>                 case SFDP_PROFILE1_ID:
> 
> When booting with this change I get:
> 
> [    1.855903] ***** params->n_dice is 2
> [    1.859626] spi-nor spi0.0: mt25qu01g (131072 Kbytes)
> 
> So spi_nor_parse_sccr_mc() was able to read the number of dies correctly.

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

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.

> 
>> What do we do in that case, Tudor? I presume a fixup which sets n_dice
>> (any maybe others) to the correct value?
> 
> 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().

cheers,
ta