From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 50EE23793B6 for ; Mon, 6 Jul 2026 14:11:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783347099; cv=none; b=f3W29N9TLiLfKMRbPcIiIRTuBHqniq0pcGzDFIjwkqGNI8zdFBMmWtD1srmhtZ3+5+y2iRpf4cdGRjkk24jXCp0fxGNm0sQUSS/8U86yAnr44ngxLloyQhBQiI6mmmhOor0vzlfl6h4m+wirlcwakPMXtVOIUcILwV4vw9o7sk8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783347099; c=relaxed/simple; bh=6ujj8AadPUHGPf4g0ViGbDIodDMH86/HLsMYd1Z/r30=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:From:To: References:In-Reply-To; b=Ve7ScXSU94lfRFlKiEx2LysNzw14fgnxm65n953VhE0cGC+P8ggN6eRYeoG4etPJZaV89uv1n8DEF4Qx4HgNOqKXYHarZDRKYF5pKES6dM6rUQkWMZ2aCHpuAdXxM26NbowXhryowA5O99nto9DSZsFo7JR6ldpRH/8Vo/JHwHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lmTMELfJ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lmTMELfJ" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id 818FF1F00A3A; Mon, 6 Jul 2026 14:11:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783347096; bh=W8QV8kvJjkxCwR3MSqw3G3bV4GcXffALD1cjWerdLe8=; h=Date:Subject:Cc:From:To:References:In-Reply-To; b=lmTMELfJ5iK1xg1SfTUM8N8t83IZvU2ACy2WczPZ59hdKnCrb8MJN99RnWbmHJ+Wv QNWQM9gJS5oIcNVw5yfE/K99yHZdNCka/CqqoQak0VIpJZYarbOJjBdyQ2NamBBBf6 aZ26DqjId08FRv2/5/xAZdvI17YIid5YekwoKuqkwgj6gCh+J26A++SLHCZC4kTCRd Rr/GaZ010tQhP2Y6DCqzpuEYaIcxRBUqwT9bGKGzrWmE08Eu9YI3HBxT2a9C+Etb5V sv0RXlhItpRs/3hTJZevnr5a60iRA9YoO/hsY/e5aXFEJQyUKjjEAHPBLCnjsYYIq5 Fyy9dlMpP7i3A== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: multipart/signed; boundary=21eeddeb0a9ddf49b4373809d5661e8d3a3b1d319a61f6774eadf0e7e8fa; micalg=pgp-sha384; protocol="application/pgp-signature" Date: Mon, 06 Jul 2026 16:11:31 +0200 Message-Id: Subject: Re: [PATCH 04/30] mtd: spi-nor: winbond: Make the RDCR fixup Winbond wide Cc: "Thomas Petazzoni" , "Steam Lin" , , From: "Michael Walle" To: "Miquel Raynal" , "Pratyush Yadav" , "Takahiro Kuwano" , "Richard Weinberger" , "Vignesh Raghavendra" X-Mailer: aerc 0.20.0 References: <20260529-winbond-v7-1-spi-nor-jv-cleanup-v1-0-87e5d3122244@bootlin.com> <20260529-winbond-v7-1-spi-nor-jv-cleanup-v1-4-87e5d3122244@bootlin.com> In-Reply-To: <20260529-winbond-v7-1-spi-nor-jv-cleanup-v1-4-87e5d3122244@bootlin.com> --21eeddeb0a9ddf49b4373809d5661e8d3a3b1d319a61f6774eadf0e7e8fa Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Fri May 29, 2026 at 5:22 PM CEST, Miquel Raynal wrote: > The top level paragraph of the QER field in the JESD216B mentions: > > "In this standard, [...] Status register 2 refers to the byte read > using instruction 35h. Status register 2 is the second byte transferred > in a Write Status (01h) command. [...]" > > Value 100b, named in Linux BFPT_DWORD15_QER_SR2_BIT1_NO_RD, does not > mention anything about reads and only brings details about writes. > > This has been interpreted in the spi-nor core by the absence of read > capability, but there is no explicit reason for that, except that there > were probably some very old chips which didn't support command 35h. I agree. But making it a vendor default we always have to have an entry. So if this is really for all winbond chips, we shall do a catch all entry (like in macronix.c). > All quad capable Winbond chips carry a CMP SWP bit in SR2. SR2 is > readable with command 35h. In practice, all Winbond families but the > W25X family have support for this feature, so re-enable it Winbond-wide > in a late vendor fixup, except for the {EF, 30, xx} family. > > Signed-off-by: Miquel Raynal > --- > drivers/mtd/spi-nor/winbond.c | 37 ++++++++++++++----------------------- > 1 file changed, 14 insertions(+), 23 deletions(-) > > diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.= c > index b4088fc5fde9..4300f0419f13 100644 > --- a/drivers/mtd/spi-nor/winbond.c > +++ b/drivers/mtd/spi-nor/winbond.c > @@ -73,26 +73,6 @@ static const struct spi_nor_fixups w25q256_fixups =3D = { > .post_bfpt =3D w25q256_post_bfpt_fixups, > }; > =20 > -static int > -winbond_rdcr_post_bfpt_fixup(struct spi_nor *nor, > - const struct sfdp_parameter_header *bfpt_header, > - const struct sfdp_bfpt *bfpt) > -{ > - /* > - * W25H02NW, unlike its W25H512NW nor W25H01NW cousins, improperly sets > - * the QE BFPT configuration bits, indicating a non readable CR. This i= s > - * both incorrect and impractical, as the chip features a CMP bit for i= ts > - * locking scheme that lays in the Control Register, and needs to be re= ad. > - */ > - nor->flags &=3D ~SNOR_F_NO_READ_CR; > - > - return 0; > -} > - > -static const struct spi_nor_fixups winbond_rdcr_fixup =3D { > - .post_bfpt =3D winbond_rdcr_post_bfpt_fixup, > -}; > - > /** > * winbond_nor_select_die() - Set active die. > * @nor: pointer to 'struct spi_nor'. > @@ -305,7 +285,6 @@ static const struct flash_info winbond_nor_parts[] = =3D { > .id =3D SNOR_ID(0xef, 0x60, 0x21), > .flags =3D SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | > SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP, > - .fixups =3D &winbond_rdcr_fixup, > }, { > /* W25Q16JV-M */ > .id =3D SNOR_ID(0xef, 0x70, 0x15), > @@ -381,7 +360,6 @@ static const struct flash_info winbond_nor_parts[] = =3D { > .id =3D SNOR_ID(0xef, 0x80, 0x22), > .flags =3D SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | > SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP, > - .fixups =3D &winbond_rdcr_fixup, > }, { > /* W25H512NW-M */ > .id =3D SNOR_ID(0xef, 0xa0, 0x20), > @@ -397,7 +375,6 @@ static const struct flash_info winbond_nor_parts[] = =3D { > .id =3D SNOR_ID(0xef, 0xa0, 0x22), > .flags =3D SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | > SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP, > - .fixups =3D &winbond_rdcr_fixup, > }, > }; > =20 > @@ -490,6 +467,20 @@ static int winbond_nor_late_init(struct spi_nor *nor= ) > */ > params->set_4byte_addr_mode =3D winbond_nor_set_4byte_addr_mode; > =20 > + /* > + * All W25Q/W25H chips do set the BFPT_DWORD15_QER_SR2_BIT1_NO_RD bit i= n > + * their SFDP tables. The historical spi-nor assumption in this case ha= s > + * been to declare CR reads as unsupported, whereas the Jedec > + * specification doesn't clearly state that. In practice, all these > + * chips do support reading back the CR, which is needed for SWP suppor= t, > + * so make sure that capability remains enabled (needed for SWP). > + * In practice, only exclude the old W25X family (JEDEC ID: EF 30 xx) > + * which actually does not support this feature. > + */ > + if (nor->info->id->bytes[0] =3D=3D 0xef && > + nor->info->id->bytes[1] > 0x30) > + nor->flags &=3D ~SNOR_F_NO_READ_CR; This is somewhat hard to read and the byte[0] is redundant here. Maybe you can come up with some macro magic sugar :) -michael > + > return 0; > } > =20 --21eeddeb0a9ddf49b4373809d5661e8d3a3b1d319a61f6774eadf0e7e8fa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iKgEABMJADAWIQTIVZIcOo5wfU/AngkSJzzuPgIf+AUCaku3lBIcbXdhbGxlQGtl cm5lbC5vcmcACgkQEic87j4CH/hCXAGAoZmvhEM6qMZ5vdRHgIVkynetqQv0q6Qq 3aItZxX50e7fDCEFfzr4nbzxI3I26f69AYDW3bCClH49wrHqxF9kZ2f0F2OxH/Ez b1PnDcEE7Y7PUCjZyTBOKiZD/PQlRYLjf0I= =fZHX -----END PGP SIGNATURE----- --21eeddeb0a9ddf49b4373809d5661e8d3a3b1d319a61f6774eadf0e7e8fa--