linux-kernel - Re: [PATCH] mtd: spi-nor: Fix w25q01jv flags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87wm3fyeof.fsf@bootlin.com>
Date: Mon, 24 Nov 2025 10:15:28 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Michael Walle" <mwalle@...nel.org>
Cc: "Marc Olberding" <molberding@...dia.com>,  "Tudor Ambarus"
 <tudor.ambarus@...aro.org>,  "Pratyush Yadav" <pratyush@...nel.org>,
  "Richard Weinberger" <richard@....at>,  "Vignesh Raghavendra"
 <vigneshr@...com>,  <linux-mtd@...ts.infradead.org>,
  <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mtd: spi-nor: Fix w25q01jv flags

On 24/11/2025 at 09:50:27 +01, "Michael Walle" <mwalle@...nel.org> wrote:

> 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@...nel.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.

Well I expect CONFIG_MTD_SPI_NOR_USE_4K_SECTORS to have no effect
if the SECT_4K flag is unset. I believe Marc is using the same chip as I
am, but enabled this option for compatibility reasons?

But as you say, this 4K capability is advertised by "my" chip, so if
Marc faces an issue with it, it may indicate that we are having an ID
collision?

Thanks,
Miquèl