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>,
"Nicolas Ferre" <nicolas.ferre@microchip.com>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
"Steam Lin" <STLin2@winbond.com>,
"Hsin-Yi Wang" <hsinyi@chromium.org>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
<linux-mtd@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] mtd: spi-nor: Refactor Read Status/Write Status support
Date: Thu, 06 Aug 2026 09:38:50 +0200 [thread overview]
Message-ID: <87se4rem0l.fsf@bootlin.com> (raw)
In-Reply-To: <87mrv2exwp.fsf@bootlin.com> (Miquel Raynal's message of "Tue, 04 Aug 2026 16:57:26 +0200")
Hello Michael,
>> One thing that comes to mind is hardware write protection. If
>> there's nothing before that code which checks it, the verify might
>> fail if the hardware write protection is enabled. So we should
>> somehow check for that and drop the verify here.
>
> But how do you think we should handle it? Will the QE bit writing
> verification fail if HW WP is enabled?
Looking into this further: we shall return an error if the QE bit is not
set. It just tells the caller that quad mode cannot be used. Then up to
the caller to either hard fail or just degrade into single mode (maybe
because of a strapped WP). What we should do is to propose a DT property
to flag when WP is strapped in hardware, this would make the content of
the status registers immutable and we would just skip the entire write
operation in the first place, instead of deliberately trying and get a
100% failure rate. Nevertheless, the changes introduced here are kind of
orthogonal and do not alter the current behaviour; we shall however
listen if people start complaining about this and perhaps implement the
solution proposed above.
Thanks!
Miquèl
next prev parent reply other threads:[~2026-08-06 7:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 16:05 [PATCH 0/5] mtd: spi-nor: Massive QE handling cleanup and Winbond RV chips addition Miquel Raynal
2026-05-29 16:05 ` [PATCH 1/5] mtd: spi-nor: Refactor Read Status/Write Status support Miquel Raynal
2026-07-07 9:43 ` Michael Walle
2026-08-04 14:57 ` Miquel Raynal
2026-08-05 14:04 ` Miquel Raynal
2026-08-06 7:38 ` Miquel Raynal [this message]
2026-05-29 16:05 ` [PATCH 2/5] mtd: spi-nor: Add support for the new JESD216 rev F QER field Miquel Raynal
2026-05-29 16:05 ` [PATCH 3/5] mtd: spi-nor: Move the SFDP header structure to a C header Miquel Raynal
2026-05-29 16:05 ` [PATCH 4/5] mtd: spi-nor: winbond: Add support for W25Q02RV-M Miquel Raynal
2026-05-29 16:05 ` [PATCH 5/5] mtd: spi-nor: winbond: Add support for W25Q51RV-M Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87se4rem0l.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=STLin2@winbond.com \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=hsinyi@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mwalle@kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=takahiro.kuwano@infineon.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox