MEMISLOCKED currently answers only from the flash chip's own block
protection bits. On platforms where write protection is enforced
elsewhere -- an Intel PCH SPI controller with protected range registers
being the common case -- those bits say nothing about what is actually
enforced, and are typically left clear.

The result is that MEMISLOCKED either fails with -EOPNOTSUPP, or, once
the chip gains SPI_NOR_HAS_LOCK, confidently reports a range as unlocked
while the controller is refusing writes to it. As more chips gain lock
flags over time, the second case replaces the first, so the wrong answer
spreads rather than the missing one.

Patch 1 lets a platform supply an is_locked() callback through struct
flash_platform_data, which spi-nor prefers over the chip's own bits. It
is inert on its own: nothing sets the callback, so every existing
platform keeps the behaviour it has today, and the series stays
bisectable.

Patch 2 adds the only user, spi-intel, which already computes protected
range state at probe but has had no way to expose it since the SPI MEM
conversion removed its visibility of the MTD device.

Full before/after numbers from a Coffee Lake NUC are in patch 2. Only
the Intel PCH path is functionally tested; the flash.h change is an
append-only addition and all existing users of that struct use
designated initialisers, so they are unaffected.

This came out of a discussion about fwupd reporting the BIOS region as
unlocked on Intel PCH systems:
https://bugzilla.kernel.org/show_bug.cgi?id=221927

Tooling disclosure, per Documentation/process/generated-content.rst:
this series was produced with the help of an LLM assistant in an
interactive session. All code was tested, results reviewed and can be
defended.

Question for the maintainers: this straddles MTD and SPI, so I do not
know which tree it should go through. Happy to resend in whatever shape
suits.

Signed-off-by: Tobias Jakobsen <tjakobsen84@protonmail.com>
---
Changes in v2:
- Reuse the protected range register decoding via a new helper instead
  of duplicating it (Mika Westerberg)
- Drop an unhelpful comment in intel_spi_is_locked() (Mika Westerberg)
- Add an Assisted-by tag and a tooling disclosure in the cover letter
- Link to v1: https://lore.kernel.org/r/20260829-spi-nor-platform-lock-v1-0-cd362d4914e2@protonmail.com

---
Tobias Jakobsen (2):
      mtd: spi-nor: allow the platform to supply write protection state
      spi: spi-intel: report controller enforced write protection

 drivers/mtd/spi-nor/core.c | 52 +++++++++++++++++++++++++++++++++--
 drivers/spi/spi-intel.c    | 68 ++++++++++++++++++++++++++++++++++++++++++----
 include/linux/spi/flash.h  | 12 ++++++++
 3 files changed, 124 insertions(+), 8 deletions(-)
---
base-commit: 1b78070aaef63512688aebfbc82365ef9d6660f1
change-id: 20260829-spi-nor-platform-lock-daa984da2872

Best regards,
-- 
Tobias Jakobsen <tjakobsen84@protonmail.com>

Hi,

On Mon Aug 31, 2026 at 2:05 PM CEST, Tobias Jakobsen via B4 Relay wrote:
> Patch 2 adds the only user, spi-intel, which already computes protected
> range state at probe but has had no way to expose it since the SPI MEM
> conversion removed its visibility of the MTD device.

Where was it removed, though?

-michael

Hi,

On Mon, Aug 31, 2026 at 02:37:59PM +0200, Michael Walle wrote:
> Hi,
> 
> On Mon Aug 31, 2026 at 2:05 PM CEST, Tobias Jakobsen via B4 Relay wrote:
> > Patch 2 adds the only user, spi-intel, which already computes protected
> > range state at probe but has had no way to expose it since the SPI MEM
> > conversion removed its visibility of the MTD device.
> 
> Where was it removed, though?

After the SPI MEM conversion the driver is a regular SPI driver so it can
only use spi_new_device() to add and configure the SPI-NOR chip (via
platform data, struct flash_platform_data). Prior this it was creating the
MTD device itself.

Hi,

On Mon Aug 31, 2026 at 2:55 PM CEST, Mika Westerberg wrote:
> Hi,
>
> On Mon, Aug 31, 2026 at 02:37:59PM +0200, Michael Walle wrote:
>> Hi,
>> 
>> On Mon Aug 31, 2026 at 2:05 PM CEST, Tobias Jakobsen via B4 Relay wrote:
>> > Patch 2 adds the only user, spi-intel, which already computes protected
>> > range state at probe but has had no way to expose it since the SPI MEM
>> > conversion removed its visibility of the MTD device.
>> 
>> Where was it removed, though?
>
> After the SPI MEM conversion the driver is a regular SPI driver so it can
> only use spi_new_device() to add and configure the SPI-NOR chip (via
> platform data, struct flash_platform_data). Prior this it was creating the
> MTD device itself.

Yeah, but it never exposed the _is_locked() op, right?

-michael

On Mon, Aug 31, 2026 at 03:00:36PM +0200, Michael Walle wrote:
> Hi,
> 
> On Mon Aug 31, 2026 at 2:55 PM CEST, Mika Westerberg wrote:
> > Hi,
> >
> > On Mon, Aug 31, 2026 at 02:37:59PM +0200, Michael Walle wrote:
> >> Hi,
> >> 
> >> On Mon Aug 31, 2026 at 2:05 PM CEST, Tobias Jakobsen via B4 Relay wrote:
> >> > Patch 2 adds the only user, spi-intel, which already computes protected
> >> > range state at probe but has had no way to expose it since the SPI MEM
> >> > conversion removed its visibility of the MTD device.
> >> 
> >> Where was it removed, though?
> >
> > After the SPI MEM conversion the driver is a regular SPI driver so it can
> > only use spi_new_device() to add and configure the SPI-NOR chip (via
> > platform data, struct flash_platform_data). Prior this it was creating the
> > MTD device itself.
> 
> Yeah, but it never exposed the _is_locked() op, right?

Ah, yeah that's right :)