From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 853D136195C for ; Wed, 22 Jul 2026 15:51:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784735504; cv=none; b=E7Qk/Iy0wTCO/9dm1J74JlsE0SzTR+je1a+AFoH+n0CHqHnO92cneZ19VGJ87mj7MHi+AbvJHOja75ZU5iBLrdCUByOyogTDoWdIBrIRQMJYdCKsslANsO0n8mCgJd9YnHK/Aw1iRvVbMkpP7/s4rXr0+KN90zHC6CY86vs5k5M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784735504; c=relaxed/simple; bh=HNd93889pYseDJt9BalvcazzZRow9GWLIkcfLoh+4hc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=puYaLJgVfZrLKnR1UgwycX2IxA6IDSI/7O/yNxIrYx95oANMSLrDDdUbVhfwtqv8gzcCOWj6kaAh46xLY8XIYFO2Ad78psa0vsXJK/JSzoPABGsHI/HHjF6R/+cPFktrScvtGh3ZiwFUPj4eXbBeYlVIioySw7CFxadCuUyl1LQ= 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=yw7+O3k2; arc=none smtp.client-ip=185.246.84.56 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="yw7+O3k2" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 446251A1170; Wed, 22 Jul 2026 15:51:38 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 0C31F60388; Wed, 22 Jul 2026 15:51:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 04F3711BD2234; Wed, 22 Jul 2026 17:51:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1784735497; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=HNd93889pYseDJt9BalvcazzZRow9GWLIkcfLoh+4hc=; b=yw7+O3k2/1Pie135iKW3VzG892M/sfQ7d60pNGeGLjq80qO8Wjv965+kn+ZnYQCq7T4OeO Lx+rL5SkcFa1AmGsxw7BdTsfoi1iOuLwHSAm0nNEhk4fGmW69i+8KrxmHbcNLPxxDLHq/4 JI1/q19l47RqV6PltKBeT2C+0dzYTymz0hGbPMuXKFN0dclRPtBl1u3kLco/cssW96adZH F3HdQ/ZqRNSOl17+adY9Qv3AI71IQyLTckg4Jp6OfJNgQcEqAzkSdNCJC+jv74dRI5ry2H HJGOtAT+SnigHiF1B5dHKjFOdvshuX9b96x4VR5/VdgClNsSWzZ84IwhqdoKjA== From: Miquel Raynal To: "Michael Walle" Cc: "Pratyush Yadav" , "Takahiro Kuwano" , "Richard Weinberger" , "Vignesh Raghavendra" , "Thomas Petazzoni" , "Steam Lin" , , Subject: Re: [PATCH 03/30] mtd: spi-nor: winbond: Stop filling the .name entry In-Reply-To: (Michael Walle's message of "Wed, 22 Jul 2026 15:23:32 +0200") References: <20260529-winbond-v7-1-spi-nor-jv-cleanup-v1-0-87e5d3122244@bootlin.com> <20260529-winbond-v7-1-spi-nor-jv-cleanup-v1-3-87e5d3122244@bootlin.com> <8733xbji7s.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Wed, 22 Jul 2026 17:51:33 +0200 Message-ID: <874ihrhvju.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 X-Last-TLS-Session-Version: TLSv1.3 On 22/07/2026 at 15:23:32 +02, "Michael Walle" wrote: > On Wed Jul 22, 2026 at 2:56 PM CEST, Miquel Raynal wrote: >> On 06/07/2026 at 15:59:53 +02, "Michael Walle" wrote: >> >>> On Fri May 29, 2026 at 5:22 PM CEST, Miquel Raynal wrote: >>>> This is a legacy field, it is often incorrectly filled and will soon >>>> become very incorrect due to IDs being reused. >>> >>> And I thought winbond is doing better... So if you have a contact >>> there, please suggest they are putting a table with a unique >>> identifier per chip there. So we can use that to do fixups. >> >> Yes, this is something that has been raised, I can confirm. We found a >> way through the SFDP data to reliably identify which chip it is since >> the SFDP version has been reliably updated over time (see the RV and PW >> addition patches). > > This seem to be two different things here. What I meant is that > Winbond will put a vendor table with a unique id per flash part in > it. > > What you have now is some kind of way to differentiate between > existing flashes, that's good, but it's not a generic solution to > the problem. > > The end goal here should be to make all flash vendor put a vendor > table into SFDP to sidestep the new notorious flash id reuse. IOW. > put a new id into the SFDP and do it correctly. We should push in > that direction. Yes. >>>> Replace the names with a comment above the entry with the newly instated >>>> naming scheme to indicate what chips are covered by each entry. >>> >>> This is exported via sysfs, so this could be a regression. >>> >>> Not sure.. >> >> Yes, but the names are totally wrong. And become even wronger with the >> addition of the RV, PW, etc families. I was already asked to not put a >> name on the new additions, I believe we should drop those fields, they >> are very misleading. So what is your final position? Pratyush any >> feedback? I can keep the old names, but, well, you know my position, >> they are wrong and old. > > Well, but that's actually on Winbond for just reusing the IDs :) > Sheldon me would also be dropping the wrong names, but yeah, it > might be an ABI now. Maybe a SFDP fixup could just unset the name > for newer flashes. That could work, but would badly impact readability of the table: developers would see a name that is not matching their chip but is matching their chip ID, but since the name would not appear in sysfs, they might think the entry is not used, although it would in practice... What a (useless?) nightmare.