All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Takahiro.Kuwano@infineon.com>
To: <ptpt52@gmail.com>, <pratyush@kernel.org>, <mwalle@kernel.org>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>
Cc: <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] mtd: spi-nor: allow force unlocking via DT property
Date: Thu, 6 Aug 2026 05:41:18 +0000	[thread overview]
Message-ID: <c0205980208a489598f4cdbdb5c8d271@infineon.com> (raw)
In-Reply-To: <20260805171214.2934-1-ptpt52@gmail.com>

Hi,
 
> Some SPI NOR flash chips (such as generic or unlisted chips used in vendor
> devices like Tenda AX12L Pro) have Block Protection (BP) bits set in the
> Status Register by bootloaders or factory settings, locking flash blocks.
> 
> Because vendors frequently switch between various generic SPI NOR flash
> chips ("Flash Lottery"), it is impractical to upstream explicit chip ID
> flags (SNOR_F_HAS_LOCK) for every possible generic chip variant.
> 
> This patch introduces support for the "linux,force-sr-unlock" Device Tree
> property:
> 1. In spi_nor_init(), trigger spi_nor_try_unlock_all() if "linux,force-sr-unlock"
>    is present in the flash DT node, even when CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE
>    is active and the chip is non-volatile.
> 2. In spi_nor_try_unlock_all(), bypass the SNOR_F_HAS_LOCK flag check when
>    "linux,force-sr-unlock" is specified, ensure locking_ops are initialized,
>    and invoke Linux kernel's native spi_nor_unlock() mechanism.

Does this work for generic(unlisted) SPI NOR flash chips with 4-bit BP
and/or CMP bit? I think we need to rely on ID database to know what block
protection bits are available in the chip.

> 
> Signed-off-by: Chen Minqiang <ptpt52@gmail.com>
> ---
>  drivers/mtd/spi-nor/core.c | 3 ++-
>  drivers/mtd/spi-nor/swp.c  | 7 ++++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index ccf4396cdcd0..ef0bdc1254bb 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3332,7 +3332,8 @@ static int spi_nor_init(struct spi_nor *nor)
>         spi_nor_cache_sr_lock_bits(nor, NULL);
>         if (IS_ENABLED(CONFIG_MTD_SPI_NOR_SWP_DISABLE) ||
>             (IS_ENABLED(CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE) &&
> -            nor->flags & SNOR_F_SWP_IS_VOLATILE)) {
> +            nor->flags & SNOR_F_SWP_IS_VOLATILE) ||
> +           of_property_read_bool(spi_nor_get_flash_node(nor), "linux,force-sr-unlock")) {
>                 spi_nor_try_unlock_all(nor);
>         }
> 
> diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
> index 235070b215d1..a190d10c1630 100644
> --- a/drivers/mtd/spi-nor/swp.c
> +++ b/drivers/mtd/spi-nor/swp.c
> @@ -628,11 +628,16 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, u64 len)
>   */
>  void spi_nor_try_unlock_all(struct spi_nor *nor)
>  {
> +       struct device_node *np = spi_nor_get_flash_node(nor);
> +       bool force_unlock = of_property_read_bool(np, "linux,force-sr-unlock");
>         int ret;
> 
> -       if (!(nor->flags & SNOR_F_HAS_LOCK))
> +       if (!(nor->flags & SNOR_F_HAS_LOCK) && !force_unlock)
>                 return;
> 
> +       if (!nor->params->locking_ops)
> +               spi_nor_init_default_locking_ops(nor);
> +
>         dev_dbg(nor->dev, "Unprotecting entire flash array\n");
> 
>         ret = spi_nor_unlock(&nor->mtd, 0, nor->params->size);
> --
> 2.17.1

Thanks,
Takahiro


WARNING: multiple messages have this Message-ID (diff)
From: <Takahiro.Kuwano@infineon.com>
To: <ptpt52@gmail.com>, <pratyush@kernel.org>, <mwalle@kernel.org>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>
Cc: <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] mtd: spi-nor: allow force unlocking via DT property
Date: Thu, 6 Aug 2026 05:41:18 +0000	[thread overview]
Message-ID: <c0205980208a489598f4cdbdb5c8d271@infineon.com> (raw)
In-Reply-To: <20260805171214.2934-1-ptpt52@gmail.com>

Hi,
 
> Some SPI NOR flash chips (such as generic or unlisted chips used in vendor
> devices like Tenda AX12L Pro) have Block Protection (BP) bits set in the
> Status Register by bootloaders or factory settings, locking flash blocks.
> 
> Because vendors frequently switch between various generic SPI NOR flash
> chips ("Flash Lottery"), it is impractical to upstream explicit chip ID
> flags (SNOR_F_HAS_LOCK) for every possible generic chip variant.
> 
> This patch introduces support for the "linux,force-sr-unlock" Device Tree
> property:
> 1. In spi_nor_init(), trigger spi_nor_try_unlock_all() if "linux,force-sr-unlock"
>    is present in the flash DT node, even when CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE
>    is active and the chip is non-volatile.
> 2. In spi_nor_try_unlock_all(), bypass the SNOR_F_HAS_LOCK flag check when
>    "linux,force-sr-unlock" is specified, ensure locking_ops are initialized,
>    and invoke Linux kernel's native spi_nor_unlock() mechanism.

Does this work for generic(unlisted) SPI NOR flash chips with 4-bit BP
and/or CMP bit? I think we need to rely on ID database to know what block
protection bits are available in the chip.

> 
> Signed-off-by: Chen Minqiang <ptpt52@gmail.com>
> ---
>  drivers/mtd/spi-nor/core.c | 3 ++-
>  drivers/mtd/spi-nor/swp.c  | 7 ++++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index ccf4396cdcd0..ef0bdc1254bb 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3332,7 +3332,8 @@ static int spi_nor_init(struct spi_nor *nor)
>         spi_nor_cache_sr_lock_bits(nor, NULL);
>         if (IS_ENABLED(CONFIG_MTD_SPI_NOR_SWP_DISABLE) ||
>             (IS_ENABLED(CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE) &&
> -            nor->flags & SNOR_F_SWP_IS_VOLATILE)) {
> +            nor->flags & SNOR_F_SWP_IS_VOLATILE) ||
> +           of_property_read_bool(spi_nor_get_flash_node(nor), "linux,force-sr-unlock")) {
>                 spi_nor_try_unlock_all(nor);
>         }
> 
> diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
> index 235070b215d1..a190d10c1630 100644
> --- a/drivers/mtd/spi-nor/swp.c
> +++ b/drivers/mtd/spi-nor/swp.c
> @@ -628,11 +628,16 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, u64 len)
>   */
>  void spi_nor_try_unlock_all(struct spi_nor *nor)
>  {
> +       struct device_node *np = spi_nor_get_flash_node(nor);
> +       bool force_unlock = of_property_read_bool(np, "linux,force-sr-unlock");
>         int ret;
> 
> -       if (!(nor->flags & SNOR_F_HAS_LOCK))
> +       if (!(nor->flags & SNOR_F_HAS_LOCK) && !force_unlock)
>                 return;
> 
> +       if (!nor->params->locking_ops)
> +               spi_nor_init_default_locking_ops(nor);
> +
>         dev_dbg(nor->dev, "Unprotecting entire flash array\n");
> 
>         ret = spi_nor_unlock(&nor->mtd, 0, nor->params->size);
> --
> 2.17.1

Thanks,
Takahiro


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2026-08-06  5:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05 17:12 [PATCH] mtd: spi-nor: allow force unlocking via DT property Chen Minqiang
2026-08-05 17:12 ` Chen Minqiang
2026-08-06  5:41 ` Takahiro.Kuwano [this message]
2026-08-06  5:41   ` Takahiro.Kuwano
     [not found] <2026-08-05171214.2934-1-ptpt52@gmail.com>
2026-08-06 11:24 ` Chen Minqiang
2026-08-06 11:24   ` Chen Minqiang
2026-08-10  6:30   ` Michael Walle
2026-08-10  6:30     ` Michael Walle

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=c0205980208a489598f4cdbdb5c8d271@infineon.com \
    --to=takahiro.kuwano@infineon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=ptpt52@gmail.com \
    --cc=richard@nod.at \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.