From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3CB7F28C2A1 for ; Wed, 22 Jul 2026 12:46:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784724371; cv=none; b=IRIqIsMQ1O19cgndTCYzanLzPAIZ5KK7gw7pNdblRqxa6lR0gYBAugQtzrXJGyA6p94/32RPDswbfWHe4boFcj7b+BPWfOgcXTY+C5lOkz/1EF440VpA2cKh972haLqi3lXKGa6rA+T09VXCGrtc+0Cq4fv3FzfEpyXpaelZujA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784724371; c=relaxed/simple; bh=nhJE2IWXv083jcRqud6lqwQVNpQuB5v2Jng0JhdNPD0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=dbmdoTXYF1Ifr61XQC6njgr8yofa5WeLZs9Dk3E2q9On1rF1HNpkheCsIcRNY3wB3UJuoRJbgoZOICLs4LBwK/kQRWGHKMIJHphoDT5whv4Rbgn+mMXtLmx+3Gr73z84YUNwMVkspOViWxgEPGW5V4CHif0y0ouJTORzKS3GcwA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=um19THyS; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="um19THyS" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 154954E40ECD; Wed, 22 Jul 2026 12:46:02 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id CCC4B60388; Wed, 22 Jul 2026 12:46:01 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id AFE0B11BD0B36; Wed, 22 Jul 2026 14:45:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1784724361; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=FWmFCXxb0VCIramQ60LckGixY+99Du+RKyjxy2l3nWY=; b=um19THySolfKr1WxCq+CNfFUP/IQPWUv4+tws2zEVbKbm28be3BWi1O5b0j5uyGH0Orw2B YanB/FZXDjjr9+a0IGoj+/R/MPTO1ChdOj/twVSoawQ8X9gVYCf5ZvxC6csZeze8B5AK5B ob7pSyHnOCL1yyjem5Fb7G5ZdSYUDfN4BqrUOll0G2qd3P7lTHn8Xt/uqpbCm6KgRhmfZM Wzug+V9FEZbt2SyGST3Xka3UReu/51tosIx+XRQKN5RJgqACxK86U6iuzfaFF11Jdo/9T7 REopNC61vK7v1WYZDg1G0FJWLD+qKncsxZSvuGYkqvOn4h8nqWE/MT+xhbsz7w== From: Miquel Raynal To: "Michael Walle" Cc: "Pratyush Yadav" , "Takahiro Kuwano" , "Richard Weinberger" , "Vignesh Raghavendra" , "Thomas Petazzoni" , "Steam Lin" , , Subject: Re: [PATCH 00/30] mtd: spi-nor: Clean Winbond W25QxxJV family In-Reply-To: (Michael Walle's message of "Mon, 06 Jul 2026 16:27:33 +0200") References: <20260529-winbond-v7-1-spi-nor-jv-cleanup-v1-0-87e5d3122244@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Wed, 22 Jul 2026 14:45:58 +0200 Message-ID: <87ecgvjipl.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Hello Michael, On 06/07/2026 at 16:27:33 +02, "Michael Walle" 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=C3=A8l