Re: [PATCH 00/30] mtd: spi-nor: Clean Winbond W25QxxJV family

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Michael Walle" <mwalle@kernel.org>
Cc: "Pratyush Yadav" <pratyush@kernel.org>,
	 "Takahiro Kuwano" <takahiro.kuwano@infineon.com>,
	 "Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	 "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	 "Steam Lin" <STLin2@winbond.com>,
	<linux-mtd@lists.infradead.org>,  <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/30] mtd: spi-nor: Clean Winbond W25QxxJV family
Date: Wed, 22 Jul 2026 14:45:58 +0200	[thread overview]
Message-ID: <87ecgvjipl.fsf@bootlin.com> (raw)
In-Reply-To: <DJRK4HNYJ2LP.KDV5AMR7FCE4@kernel.org> (Michael Walle's message of "Mon, 06 Jul 2026 16:27:33 +0200")

Hello Michael,

On 06/07/2026 at 16:27:33 +02, "Michael Walle" <mwalle@kernel.org> wrote:

> On Fri May 29, 2026 at 5:22 PM CEST, Miquel Raynal wrote:
>> Thanks to Winbond collaboration, I was able to test almost the entire JV
>> SPI NOR family. A few chips could not be sourced, I decided to apply the
>> very same logic than the other chips, all of them behave identically as
>> shown in all the logs that I am sharing in each and every commit.
>>
>> This series is pretty straightforward, it is here to cleanup the JV
>> entries by:
>> - Removing the useless part names (which are going to become a problem)
>> - Aligning the comments and "fixing" the chip names in them
>> - Reordering the chips by density and family
>> - Testing and showing all the SFDP content and passing all the SPI NOR
>>   tests to ensure a good level of support.
>> - Describing only what needs to be described, parsing the SFDP tables
>>   otherwise.
>> - Adding all the locking information when it is missing.
>>
>> This work is necessary because I am about to propose the addition of the
>> W25QxxRV family, whose IDs actually collide with the JV chips. The chips
>> are similar, they have been "improved" (especially the silicon/engraving
>> smoothness) and we have a way to differentiate them based on their SFDP
>> content, but that will be for a following series.
>
> Why do you need to remove the no_sfdp_flags? I have only looked at
> some of the patches, but overall it seems we'd be dropping support
> for older chips - which we don't know if they are in use or not.
>
> So although the comment might only point to one chip, there can be
> many more with that very same id. And now.. with the RV family even
> more. Ugh.

I wanted to follow the spi-nor direction which-nor was to move away from
these, when they were relevant. But you are right, I gathered more
information, Winbond has transitioned to SFDP between 2012 and 2016, no
chip without SFDP has been manufactured for more than a decade. I guess
it is still possible to find chips with no SFDP support then.

Since removing the no_sfdp_flags field would mean dropping support for
those old chips, I guess we are stuck with this data. At this point, I
do not identify problems with keeping the no_sfdp data and adding
support for the RV chips.

However I will keep removing the names, which get wrong-er and
wrong-er...

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/