From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (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 6BB4920CCCA for ; Mon, 24 Nov 2025 08:00:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763971238; cv=none; b=dAdieBS40Grv1Oc0yMj0KWAN6CFLTTBOap4YUKBp9Bp2/21NgHGJLdPrYo70SLOvb7AdD34mACVz5Eoo7nG3qmybZrGBrk8/Qi46wDYQ0Ez5NcE1m/5CxY3KUCGyzDC/IxionSZZWcjWsEH0eiPPba/xutU3XT7vB0oM9jG3kJ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763971238; c=relaxed/simple; bh=dGKPpm7k8tuka8ZhEfMm6JqB+0CUpCKmZWKS0+hgD70=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=RdgyxeAn4pzvggTqbRSYkj0IL0EZJjbmGCmYQfre0NsDAPac//JEKhSE+ou4o6rV2m1DIraSzhv1Mb3ZacjTLppLgr9AdRTrrgN9P/rAqpKQ/rSI7SJ9nx60NjtWTHA/fvvvQHpV3JjXCzyw2H9qnx6qkGNHbNVrMB7bRVT9TRY= 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=dflCg6JW; arc=none smtp.client-ip=185.171.202.116 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="dflCg6JW" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id E4411C139A5; Mon, 24 Nov 2025 08:00:09 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 7D8F3606FC; Mon, 24 Nov 2025 08:00:32 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 166A010370004; Mon, 24 Nov 2025 09:00:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1763971231; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=nAYucZ//0PJKUxBFzIXxcaSNRPWJLukjBLAGomp2KiY=; b=dflCg6JWqiq6r+0sn/UcxrmbmlFXNuSqzjz6AS8+1tY+na6I7Z+8fJdbjMl4o9Jy9lpBiS cMJ6CAZmtgrDh4wh119IxyoZeGY8en+eO9OUmk78Bs++K4O34qb3jEvWVi0MaZnq1iT625 4AGoXLR7hpb8OUtkbxnXzJiLu1nwvBNIcZyXXjWY4pAViRxCGvasoxFS4dPumUXIAi8jYQ l0Em+g2xipKEG+sP55MasTq8Zhj2jvnaYG0j2z/g8qA0A3t9g97wvywRDB7aMVHwG9yFlc ZLOxaOj0IpCElf4NWg5z5XdqJOJNnTJF5dhyzW8bBYuimDoM3f0Q51jh1imlqQ== From: Miquel Raynal To: Marc Olberding Cc: Tudor Ambarus , Pratyush Yadav , Michael Walle , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: spi-nor: Fix w25q01jv flags In-Reply-To: <20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com> (Marc Olberding's message of "Fri, 21 Nov 2025 14:35:34 -0800") References: <20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Mon, 24 Nov 2025 09:00:27 +0100 Message-ID: <87jyzfzwpw.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 Hi Marc, On 21/11/2025 at 14:35:34 -08, Marc Olberding wrote: > The previous support for w25q01jv was causing read/write > miscompares on flashing with the aspeed ast2600. Add in > extra flags to allow the chip to identify as having 4K > sectors if the sfdp tables aren't present, as well Are we sure about the reason? Normally this is a non-sfdp flag, which means even if you have sfdp tables, you must mark this flag manually. These chips should always have the sfdp tables. Did you face cases where they are not populated? > as reporting the name and adding the LOCK and TB flag. > > After this change, no miscompares were seen. > > Fixes: 9b4db032fb2b ("mtd: spi-nor: winbond: Add support for w25q01jv") > Signed-off-by: Marc Olberding > --- > The initial commit[1] that came in for w25q01jv [2] support > lacks the 4K sector flags in the case that the sfdp flags don't > exist on the chip. This caused filesystem corruption upon writes. > Add in the flags as well as the chips size and name. > > Testing: > After this patch, BMC's backed by the w25q01jv succeed on boot > as well as self-flash > > [1] https://lore.kernel.org/all/20251014050108.665338-1-chou.cosmo@gmail.= com/ > [2] https://www.winbond.com/resource-files/W25Q01JV%20SPI%20RevE%20030420= 24%20Plus.pdf > --- > drivers/mtd/spi-nor/winbond.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c > index 63a93c9eb9174b073e19c41eeada33b23a99b184..7d4119afc8c6b4135b5a055b5= 2b1ade7e3ef926c 100644 > --- a/drivers/mtd/spi-nor/winbond.c > +++ b/drivers/mtd/spi-nor/winbond.c > @@ -227,8 +227,11 @@ static const struct flash_info winbond_nor_parts[] = =3D { > .size =3D SZ_64M, > .no_sfdp_flags =3D SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ, > }, { > - /* W25Q01JV */ > .id =3D SNOR_ID(0xef, 0x40, 0x21), > + .name =3D "w25q01jv", Changing the comment into a name is not relevant here for two reasons: - this is deprecated - this patch is a fix, any further additions should be in a dedicated patch. > + .size =3D SZ_128M, Do you really need this field? How did the flash even worked before if you need this? > + .flags =3D SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB, I have not used nor tested block protection on that chip. If it's an addition you must put that in a separated patch. Fixes will be queued faster than feature additions, you cannot mix both. > + .no_sfdp_flags =3D 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). > .fixups =3D &winbond_nor_multi_die_fixups, > }, { > .id =3D SNOR_ID(0xef, 0x50, 0x12), Thanks, Miqu=C3=A8l