[PATCH] mtd: spi-nor: Fix w25q01jv flags

[Michael Walle]

On Mon Nov 24, 2025 at 9:25 AM CET, Miquel Raynal wrote:
> Hi,
>
> On 24/11/2025 at 09:12:38 +01, "Michael Walle" <mwalle at kernel.org> wrote:
>
>> Hi,
>>
>>>> +		.no_sfdp_flags = SECT_4K,
>>>
>>> This one is the right fix and should stand alone in its own patch (first
>>> in the series if you add support for the block protection).
>>
>> Only if that flash really doesn't have SFDP. But since the entry
>> didn't have a size property the flash *must* have SFDP in the first
>> place.  Otherwise it won't even be probed. Please provide a dump of
>> the SFDP tables, see [1].
>
> SFDP data is in lore

At least yours :) And if I decode that correctly by hand, it has the
4k erase size bit set as well as the correct opcode 20h or 21h for
4byte addressing.

> , but not the params which are missing (?) Marc, can
> you compare with your data?
> https://lore.kernel.org/all/20250110-winbond-6-12-rc1-nor-volatile-bit-v3-1-735363f8cc7d@bootlin.com/
>
>> Also please provide the contents of
>> /sys/kernel/debug/spi-nor/spiN.N/params.
>>
>> -michael
>
> My understanding (which may clearly be erroneous) is that most of these
> flashes support 4K blocks but somehow don't advertise it in their SFDP
> data, so every time we describe a chip we must remember to tick that
> flag.

Which flag? SECT_4K? I don't think that will be used at all, does
it? It's only used in spi_nor_no_sfdp_init_params() which in turn is
only called in spi_nor_init_params_deprecated() (or if SKIP_SFDP is
set). 

> I guess all^Wmost chips have 4k blocks compatibility support, but in
> general we prefer to use bigger blocks (the ones advertised in the SFDP
> data). Michael, am I being mislead by the decades of history that went
> through the spi-nor core? :)

You mean CONFIG_MTD_SPI_NOR_USE_4K_SECTORS? But that has nothing to
to with the flashdb/sfdp parsing.

-michael

>
>> [1] https://docs.kernel.org/driver-api/mtd/spi-nor.html#minimum-testing-requirements
>>
>>>
>>>>  		.fixups = &winbond_nor_multi_die_fixups,
>>>>  	}, {
>>>>  		.id = SNOR_ID(0xef, 0x50, 0x12),
>>>
>>> Thanks,
>>> Miquèl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 297 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20251124/9cadcc76/attachment.sig>