From nobody Sat Sep 26 18:55:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D91623EF0DC; Mon, 31 Aug 2026 12:05:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788177955; cv=none; b=jwI9oh+KTdvi57GbBIjD9ZzRqaoCbhp87rRjDTxYaOxUvczBErn6+EVS1p0wyz1dbvl8dbTnn1A4BO9czznxtszYv1EbODVlkVJlGKrccI7DCc9F3XlL26hKzTF0x4HGkt2Lg6XJSTvk6S064CZMOyM+Dx2r6REgphFlwowAN0E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788177955; c=relaxed/simple; bh=kHQGesbCcImkblBLI4Q2Mc47miAuY3bdoqDw2nlRzP0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=dJCYkG5TNJybKvDghgK5DUANfCkBOmwMPmEERIr63fg8VzDS+4hEge4s/6/4W1v+1f1KEzh/4ZVgO/jXymsN7dXslX22yn4akBNSPJ7rk8XbmtBbO1btXfhOfiQa5o2oYZ7LSaUSQmZDGnfzhylPEtgYS8gQQjPkr/+GAxQDCco= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Jc8TuW6H; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Jc8TuW6H" Received: by smtp.kernel.org (Postfix) with ESMTPS id 87E97C2BCB8; Mon, 31 Aug 2026 12:05:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1788177955; bh=kHQGesbCcImkblBLI4Q2Mc47miAuY3bdoqDw2nlRzP0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=Jc8TuW6Hok33Secphh/iSb3+ubNglM9b0omzZnZiCJPiruB+w7xGmDDrrIClF22yF Dk0s//yza/XTAiVMw7Jq2RbpEA6ACgeBKLtxiCJp3eEGfGwyVnS7xDofKYSRAnvPr6 ZeSkef5o8l/t6QsuHhe1IFLa/iBfqS+vpfTimoozCCQYnpHD2JzjeHZEJtpJ+zTFFC n4F1aZBalrcZ3xyCS0YUPAlDtIoeK1jAR2tjTC8JwB1NpW2Scn580oDsx8uaHzWxI0 fLMdZAsEcXYaE1hkWEsQHUpdED0Ar2tdzlqp81fjB5eu46S+XF0FN6rINZnOluiRkZ PFX90WRRSV3YA== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69927C61DE2; Mon, 31 Aug 2026 12:05:55 +0000 (UTC) From: Tobias Jakobsen via B4 Relay Date: Mon, 31 Aug 2026 14:05:51 +0200 Subject: [PATCH v2 1/2] mtd: spi-nor: allow the platform to supply write protection state 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 Message-Id: <20260831-spi-nor-platform-lock-v2-1-6cc75b909241@protonmail.com> References: <20260831-spi-nor-platform-lock-v2-0-6cc75b909241@protonmail.com> In-Reply-To: <20260831-spi-nor-platform-lock-v2-0-6cc75b909241@protonmail.com> To: Pratyush Yadav , Michael Walle , Takahiro Kuwano , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mark Brown Cc: Mika Westerberg , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, Tobias Jakobsen X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788177954; l=5359; i=tjakobsen84@protonmail.com; s=20260829; h=from:subject:message-id; bh=MSys8cnXbQBoWVAcIhue35cuWVEU+RVJ5eSR/jS9c98=; b=ajtrL7jE2GkvUCH6m2KQ0jishkNtM0TF0PpJb/axYVNuluOZtf1Qa9FzPiA4zAu5tUgw9Gp6c /lHveFpouueDqLb4AAyQZYtx4URG+RMherINPr34hszuGz3ETL+COZH X-Developer-Key: i=tjakobsen84@protonmail.com; a=ed25519; pk=UREd6cisfwsFIDP455nUH6Ysx+ZDGnAVE9nGmKzm1Ks= X-Endpoint-Received: by B4 Relay for tjakobsen84@protonmail.com/20260829 with auth_id=986 X-Original-From: Tobias Jakobsen Reply-To: tjakobsen84@protonmail.com From: Tobias Jakobsen Some flashes are write protected by the platform they are attached to rather than by their own block protection bits. An Intel PCH SPI controller programmed with protected range registers is one example: it refuses writes to a range regardless of what the chip's status register says, while the chip's block protection bits are typically left clear. MEMISLOCKED therefore either fails with -EOPNOTSUPP, or, once the chip gains SPI_NOR_HAS_LOCK, reports a range as unlocked while writes to it are in fact being refused. Let the platform supply an optional is_locked() callback in struct flash_platform_data, alongside the partitions it can already supply, and prefer it over the chip's own block protection bits. This is independent of SPI_NOR_HAS_LOCK, so an answer is also given for chips that have no block protection support of their own. lock() and unlock() return -EOPNOTSUPP, as platform enforced protection is not expected to be changed at runtime. Platforms that do not supply the callback are unaffected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D221927 Assisted-by: LLM Signed-off-by: Tobias Jakobsen --- drivers/mtd/spi-nor/core.c | 52 ++++++++++++++++++++++++++++++++++++++++++= ++-- include/linux/spi/flash.h | 12 +++++++++++ 2 files changed, 62 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index ccf4396cd..a5c37eea4 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -3001,6 +3001,50 @@ static void spi_nor_init_fixup_flags(struct spi_nor = *nor) nor->flags |=3D SNOR_F_IO_MODE_EN_VOLATILE; } =20 +static int spi_nor_platform_lock(struct spi_nor *nor, loff_t ofs, u64 len) +{ + return -EOPNOTSUPP; +} + +static int spi_nor_platform_unlock(struct spi_nor *nor, loff_t ofs, u64 le= n) +{ + return -EOPNOTSUPP; +} + +static int spi_nor_platform_is_locked(struct spi_nor *nor, loff_t ofs, u64= len) +{ + struct flash_platform_data *data =3D dev_get_platdata(nor->dev); + + return data->is_locked(nor->spimem->spi, ofs, len); +} + +static const struct spi_nor_locking_ops spi_nor_platform_locking_ops =3D { + .lock =3D spi_nor_platform_lock, + .unlock =3D spi_nor_platform_unlock, + .is_locked =3D spi_nor_platform_is_locked, +}; + +/** + * spi_nor_init_platform_locking_ops() - Use the platform supplied write + * protection query, if there is one. + * @nor: pointer to a 'struct spi_nor' + * + * Some flashes are write protected by the platform they are attached to r= ather + * than by their own block protection bits, for example by an Intel PCH SPI + * controller programmed with protected range registers. In that case the = chip's + * block protection bits are typically left clear and say nothing about wh= at is + * actually enforced, so prefer the platform supplied query when available. + */ +static void spi_nor_init_platform_locking_ops(struct spi_nor *nor) +{ + struct flash_platform_data *data =3D dev_get_platdata(nor->dev); + + if (!data || !data->is_locked || !nor->spimem) + return; + + nor->params->locking_ops =3D &spi_nor_platform_locking_ops; +} + /** * spi_nor_late_init_params() - Late initialization of default flash param= eters. * @nor: pointer to a 'struct spi_nor' @@ -3040,9 +3084,13 @@ static int spi_nor_late_init_params(struct spi_nor *= nor) spi_nor_init_fixup_flags(nor); =20 /* - * NOR protection support. When locking_ops are not provided, we pick - * the default ones. + * NOR protection support. Platform enforced protection is preferred + * over the chip's own, as the chip is not necessarily aware of it. + * When locking_ops are not provided, we pick the default ones. */ + if (!nor->params->locking_ops) + spi_nor_init_platform_locking_ops(nor); + if (nor->flags & SNOR_F_HAS_LOCK && !nor->params->locking_ops) spi_nor_init_default_locking_ops(nor); =20 diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h index 2401a0887..f415e2c0b 100644 --- a/include/linux/spi/flash.h +++ b/include/linux/spi/flash.h @@ -2,7 +2,10 @@ #ifndef LINUX_SPI_FLASH_H #define LINUX_SPI_FLASH_H =20 +#include + struct mtd_partition; +struct spi_device; =20 /** * struct flash_platform_data: board-specific flash data @@ -11,6 +14,13 @@ struct mtd_partition; * @nr_parts: number of mtd_partitions for static partitioning * @type: optional flash device type (e.g. m25p80 vs m25p64), for use * with chips that can't be queried for JEDEC or other IDs + * @is_locked: optional callback to query write protection enforced by the + * platform rather than by the flash chip itself, for example a SPI + * controller that gates writes to a range of the flash. Returns 1 if + * the whole range is protected, 0 if it is not, or a negative errno. + * When supplied it takes precedence over the chip's own block + * protection bits, which do not necessarily reflect what is actually + * being enforced. * * Board init code (in arch/.../mach-xxx/board-yyy.c files) can * provide information about SPI flash parts (such as DataFlash) to @@ -26,6 +36,8 @@ struct flash_platform_data { =20 char *type; =20 + int (*is_locked)(struct spi_device *spi, loff_t ofs, u64 len); + /* we'll likely add more ... use JEDEC IDs, etc */ }; =20 --=20 2.53.0 From nobody Sat Sep 26 18:55:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D8FEE3EAC75; Mon, 31 Aug 2026 12:05:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788177955; cv=none; b=RGDjT9MaagO/MhXxjVf/o9uYgROR3VMwFT7xBk9chngiX+qgv/b4cFQE9Zmg0Y9+gdadu2AnkHYApTD6UdhBVWqkyKEXI0a7C0ZqgIC4SDlgxyoSR7G8Dn49b+tC+t35K/Ny48zLQgjMDeqQ04qnwYkgRRvw25Wn7OyphSgTt74= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788177955; c=relaxed/simple; bh=F1+FfGZtXVn4f1NtX43blQ71NZ9In0wKXvLvW0MwbMA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=rgxkSq1HM61AJT5P7tt71HH9zRu+47dHW8/0zbhWqhPRbI9D4ngAbpGZBB4XQKH42FJAgttD51AnDvIH2GCJGrKOwB6HJw37tV27A8ByAdrofhoUNYCDJ+FXVnJswp8j98viJykeWCx5C8qoj0V5kXEAmEyNEe1FSr1nC6W1MBc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eEP7hGCf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eEP7hGCf" Received: by smtp.kernel.org (Postfix) with ESMTPS id 9AC5CC2BCFC; Mon, 31 Aug 2026 12:05:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1788177955; bh=F1+FfGZtXVn4f1NtX43blQ71NZ9In0wKXvLvW0MwbMA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=eEP7hGCf2RnkcowUWTG9HlNAT8XX1/7GSwl7E9hFgEy1eTv2c8ovHcKHxsUbpFrEe Rpx1AQrVXJsI6LFFhEgqcPW//MQxGr+qGv5u0Edw9V/v64GvkriRPI+0j4Fn5bSk1r ghV4U8Ooc5Y/nP0y5TE4mxZQpQekCe0E3Zv/1i5Pl+8i8d6rSiBDg9ScPgZKCjgTlx MqaDeQDm52wzw4AzqKDycYBqO7/3KtThxWUZBbSP2gFtUOgfF0TJYJMV6RU/d5kEEH 1yGlgzbDxRgvX0JgueClN9ahx9bngPPqIQEgmv4VP9ZeWANoQyHgj6vO+Luru3P/ed PBO0Ct9pHmCDA== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CA32C61DD3; Mon, 31 Aug 2026 12:05:55 +0000 (UTC) From: Tobias Jakobsen via B4 Relay Date: Mon, 31 Aug 2026 14:05:52 +0200 Subject: [PATCH v2 2/2] spi: spi-intel: report controller enforced write protection 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 Message-Id: <20260831-spi-nor-platform-lock-v2-2-6cc75b909241@protonmail.com> References: <20260831-spi-nor-platform-lock-v2-0-6cc75b909241@protonmail.com> In-Reply-To: <20260831-spi-nor-platform-lock-v2-0-6cc75b909241@protonmail.com> To: Pratyush Yadav , Michael Walle , Takahiro Kuwano , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mark Brown Cc: Mika Westerberg , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, Tobias Jakobsen X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788177954; l=4515; i=tjakobsen84@protonmail.com; s=20260829; h=from:subject:message-id; bh=hnJ5ZrAUjiYnonyAjO1RxiM6tEYPy3JJWHB4oxKDt+M=; b=aHxQRdIuNRun/v9aWrq5iqZrpjZYWvw0mh/38zfg43Dy5itL94mf6v9Qy7SNUU5E4REshttif mO+Xbpon6q3AqtO4/rjM9wyeGg+gsIChC02ii7a8+kBgmdnItgHaa8M X-Developer-Key: i=tjakobsen84@protonmail.com; a=ed25519; pk=UREd6cisfwsFIDP455nUH6Ysx+ZDGnAVE9nGmKzm1Ks= X-Endpoint-Received: by B4 Relay for tjakobsen84@protonmail.com/20260829 with auth_id=986 X-Original-From: Tobias Jakobsen Reply-To: tjakobsen84@protonmail.com From: Tobias Jakobsen On Intel PCH platforms write protection is enforced by the controller's protected range registers, not by the flash chip's block protection bits, which are typically left clear. The SPI MEM conversion left spi-intel without visibility of the MTD device, so it cannot supply MTD locking operations directly. Pass a write protection query through struct flash_platform_data, which spi-intel already uses to hand the partition layout to spi-nor. Note this asks the opposite question to intel_spi_is_protected(): rather than whether a flash region contains a protected range, it asks whether the queried range is itself entirely covered by one, which is what the MTD layer means by locked. Tested on a Coffee Lake i5 with PR0 covering 0x860000-0xffffff and FLOCKDN set, querying MEMISLOCKED over four ranges: PR0 range whole chip in PR0 below PR0 unpatched -95 -95 -95 -95 chip lock flags only 0 0 0 0 patched, no chip lock flags 1 0 1 0 patched + chip lock flags 1 0 1 0 The whole chip and below-PR0 columns stay unlocked because only 0x860000-0xffffff is covered by a protected range. Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D221927 Assisted-by: LLM Signed-off-by: Tobias Jakobsen --- drivers/spi/spi-intel.c | 68 ++++++++++++++++++++++++++++++++++++++++++++-= ---- 1 file changed, 62 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c index 7494b921a..63639f742 100644 --- a/drivers/spi/spi-intel.c +++ b/drivers/spi/spi-intel.c @@ -1201,21 +1201,36 @@ static int intel_spi_init(struct intel_spi *ispi) return 0; } =20 +/* + * Read protected range register @idx and decode it, provided any of the + * protection bits in @mask are set. + */ +static bool intel_spi_pr_range(const struct intel_spi *ispi, int idx, u32 = mask, + unsigned int *base, unsigned int *limit) +{ + u32 pr_value =3D readl(ispi->pregs + PR(idx)); + + if (!(pr_value & mask)) + return false; + + *limit =3D (pr_value & PR_LIMIT_MASK) >> PR_LIMIT_SHIFT; + *base =3D pr_value & PR_BASE_MASK; + + return true; +} + static bool intel_spi_is_protected(const struct intel_spi *ispi, unsigned int base, unsigned int limit) { int i; =20 for (i =3D 0; i < ispi->pr_num; i++) { - u32 pr_base, pr_limit, pr_value; + unsigned int pr_base, pr_limit; =20 - pr_value =3D readl(ispi->pregs + PR(i)); - if (!(pr_value & (PR_WPE | PR_RPE))) + if (!intel_spi_pr_range(ispi, i, PR_WPE | PR_RPE, &pr_base, + &pr_limit)) continue; =20 - pr_limit =3D (pr_value & PR_LIMIT_MASK) >> PR_LIMIT_SHIFT; - pr_base =3D pr_value & PR_BASE_MASK; - if (pr_base >=3D base && pr_limit <=3D limit) return true; } @@ -1223,6 +1238,41 @@ static bool intel_spi_is_protected(const struct inte= l_spi *ispi, return false; } =20 +/* + * Unlike intel_spi_is_protected(), which asks whether a flash region cont= ains + * any protected range, this asks the opposite: whether the given range is + * itself entirely covered by a write protected range. That is what the MTD + * layer means by "locked". + */ +static bool intel_spi_is_range_protected(const struct intel_spi *ispi, + unsigned int base, unsigned int limit) +{ + int i; + + for (i =3D 0; i < ispi->pr_num; i++) { + unsigned int pr_base, pr_limit; + + if (!intel_spi_pr_range(ispi, i, PR_WPE, &pr_base, &pr_limit)) + continue; + + if (base >=3D pr_base && limit <=3D pr_limit) + return true; + } + + return false; +} + +static int intel_spi_is_locked(struct spi_device *spi, loff_t ofs, u64 len) +{ + struct intel_spi *ispi =3D spi_controller_get_devdata(spi->controller); + + if (!len) + return 0; + + return intel_spi_is_range_protected(ispi, ofs >> 12, + (ofs + len - 1) >> 12); +} + /* * There will be a single partition holding all enabled flash regions. We * call this "BIOS". @@ -1395,6 +1445,12 @@ static int intel_spi_populate_chip(struct intel_spi = *ispi) =20 intel_spi_fill_partition(ispi, pdata->parts); =20 + /* + * The protected range registers address the first chip, so only it can + * be queried this way. + */ + pdata->is_locked =3D intel_spi_is_locked; + memset(&chip, 0, sizeof(chip)); snprintf(chip.modalias, 8, "spi-nor"); chip.platform_data =3D pdata; --=20 2.53.0