public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Michael Walle" <mwalle@kernel.org>
Cc: "Marc Olberding" <molberding@nvidia.com>,
	 "Tudor Ambarus" <tudor.ambarus@linaro.org>,
	 "Pratyush Yadav" <pratyush@kernel.org>,
	"Richard Weinberger" <richard@nod.at>,
	 "Vignesh Raghavendra" <vigneshr@ti.com>,
	 <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd: spi-nor: Fix w25q01jv flags
Date: Mon, 24 Nov 2025 09:25:28 +0100	[thread overview]
Message-ID: <87bjkrzvk7.fsf@bootlin.com> (raw)
In-Reply-To: <DEGRVEN1ZNUY.OCJLFWDG8XD4@kernel.org> (Michael Walle's message of "Mon, 24 Nov 2025 09:12:38 +0100")

Hi,

On 24/11/2025 at 09:12:38 +01, "Michael Walle" <mwalle@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, 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. 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? :)

> [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

  reply	other threads:[~2025-11-24  8:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21 22:35 [PATCH] mtd: spi-nor: Fix w25q01jv flags Marc Olberding
2025-11-24  8:00 ` Miquel Raynal
2025-11-24  8:12   ` Michael Walle
2025-11-24  8:25     ` Miquel Raynal [this message]
2025-11-24  8:50       ` Michael Walle
2025-11-24  9:15         ` Miquel Raynal
2025-11-25  0:03           ` Marc Olberding
2025-11-25  7:41             ` Michael Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bjkrzvk7.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=molberding@nvidia.com \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox