From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp11.infineon.com (smtp11.infineon.com [217.10.52.105]) (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 DB40737AA92 for ; Thu, 6 Aug 2026 05:41:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.10.52.105 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785994882; cv=none; b=ujgK9IhXtddgAFD473ZU1K1xgQ313Kcd653Q61dzX+UptYlVLN6WL7DKE360wdIiFOKth4yhwNJCHXzRFYstLNX7cHkMX0wkXk4allxNhDk75WncebWcxZPpRjRyVcU0vfk4zRwr4zcIGIDML/jQgw4s8L9oqi4OIrN9u4dcut0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785994882; c=relaxed/simple; bh=Y19W6dQYCEXXZL0LHrKYeszxVu2tNtDAiuHWLpyBbW0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=eHoQBAg4/ZH58eej/Rtd0ZudLCubPvGAYUlnxzeeQXR080OKWsMRHf6kRdrZlnREsPmzV6Nzp7I0ivU9BHqHsOjS1nAEWKAIFKD0xUNYse8d6qMYSdTsg0y4Jr02OOJh8Bk9gvfFgnW8Uzg0VKCtJzegLWrMXZ9XcQn7zNkOsfc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=infineon.com; spf=pass smtp.mailfrom=infineon.com; dkim=pass (1024-bit key) header.d=infineon.com header.i=@infineon.com header.b=PsB81LNN; arc=none smtp.client-ip=217.10.52.105 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=infineon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infineon.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=infineon.com header.i=@infineon.com header.b="PsB81LNN" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1785994882; x=1817530882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y19W6dQYCEXXZL0LHrKYeszxVu2tNtDAiuHWLpyBbW0=; b=PsB81LNNTY554//2j4TUTSMSj2V4H4OLJAk8mbe8ohebP4EeTnPIWZNP QnfIS44Mn1wDOKNaycA3AbZJ0gK3LaLGHlci01n6Gb8ma2Zaryr/yxuVg 1Onb8WSqdjVxcOU2THqFFr7YipykkPzADSaarW8zQtRpjHhIVWdlssJim M=; X-CSE-ConnectionGUID: J1lpMjJQRwKpcgYHidA+5Q== X-CSE-MsgGUID: uEb19Y0qS4mXF7Di/7t6lA== X-IronPort-AV: E=McAfee;i="6800,10657,11866"; a="154750381" X-IronPort-AV: E=Sophos;i="6.25,207,1779141600"; d="scan'208";a="154750381" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO MUCSE805.infineon.com) ([172.23.29.31]) by smtp11.infineon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Aug 2026 07:41:19 +0200 Received: from KLUSE816.infineon.com (172.28.156.170) by MUCSE805.infineon.com (172.23.29.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 6 Aug 2026 07:41:18 +0200 Received: from KLUSE816.infineon.com (172.28.156.170) by KLUSE816.infineon.com (172.28.156.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 6 Aug 2026 07:41:18 +0200 Received: from KLUSE816.infineon.com ([fe80::4a3d:fdb5:843:3451]) by KLUSE816.infineon.com ([fe80::4a3d:fdb5:843:3451%19]) with mapi id 15.02.2562.045; Thu, 6 Aug 2026 07:41:18 +0200 From: To: , , , , , CC: , Subject: RE: [PATCH] mtd: spi-nor: allow force unlocking via DT property Thread-Topic: [PATCH] mtd: spi-nor: allow force unlocking via DT property Thread-Index: AQHdJP2XX1L+08ylx0S4qLK3gdXlO7aQcjdQ Date: Thu, 6 Aug 2026 05:41:18 +0000 Message-ID: References: <20260805171214.2934-1-ptpt52@gmail.com> In-Reply-To: <20260805171214.2934-1-ptpt52@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi, =20 > Some SPI NOR flash chips (such as generic or unlisted chips used in vendo= r > devices like Tenda AX12L Pro) have Block Protection (BP) bits set in the > Status Register by bootloaders or factory settings, locking flash blocks. >=20 > 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. >=20 > 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_DISA= BLE_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 whe= n > "linux,force-sr-unlock" is specified, ensure locking_ops are initializ= ed, > 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. >=20 > Signed-off-by: Chen Minqiang > --- > drivers/mtd/spi-nor/core.c | 3 ++- > drivers/mtd/spi-nor/swp.c | 7 ++++++- > 2 files changed, 8 insertions(+), 2 deletions(-) >=20 > 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,for= ce-sr-unlock")) { > spi_nor_try_unlock_all(nor); > } >=20 > 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 =3D spi_nor_get_flash_node(nor); > + bool force_unlock =3D of_property_read_bool(np, "linux,force-sr-u= nlock"); > int ret; >=20 > - if (!(nor->flags & SNOR_F_HAS_LOCK)) > + if (!(nor->flags & SNOR_F_HAS_LOCK) && !force_unlock) > return; >=20 > + if (!nor->params->locking_ops) > + spi_nor_init_default_locking_ops(nor); > + > dev_dbg(nor->dev, "Unprotecting entire flash array\n"); >=20 > ret =3D spi_nor_unlock(&nor->mtd, 0, nor->params->size); > -- > 2.17.1 Thanks, Takahiro