From nobody Tue Apr 7 01:06:53 2026 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (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 26EEF3A3E97 for ; Tue, 17 Mar 2026 10:24:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773743061; cv=none; b=Y0rh8Acz+K3k4ir5SNvIl9g+FW5TVejAoep6j+d/i3mJmcskIYFmkSja0vrdSAuZEbtpJEd39M12OCymcO3qgI2LiLiPjxz3wEePOqg7dFdVR4Yl/RhW4MTtdaok/KGoVZ7QAJxuejOKGEb/kcuMeydnTdaTauYOb0V6EHB76NA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773743061; c=relaxed/simple; bh=PGW28jxV6NLfJchRFgJZv966a2uFw+0TVJ+29FoFq50=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=YVjA5F3ZkjIdNRbUneDx9ZxuSsOKLdeAEhGnJb0Mqr9mgITTca7FJAyaJ4afcz4fmtmvqXvpbRrRrNao7uqHoa45KFqfsdgruP1WPRPB2TYlv9Ln5A075FetoQKOUZEXxfI56itm6Y4mNO9utACc51bauPgOHJfHSs1rraydTWU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=S1perSMX; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="S1perSMX" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id DB10F4E42629; Tue, 17 Mar 2026 10:24:18 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id B1EAB5FC9A; Tue, 17 Mar 2026 10:24:18 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 9038C104503A6; Tue, 17 Mar 2026 11:24:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1773743057; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=oH2f1X8ubdaJfjO8jMVN/SnoqiCo9otBh9JA0zOAQYE=; b=S1perSMXvgTj9BcAX/5aMWvU0brGtGre/OKB/h3uYO1cwci2caT1nEPs2uu6P1FTRDE9jN FTVz6ARqrxbDFf+MJbnLC+h6HBKaJddf7n5wFtF+JFsTo+JYuykClwrpEBH47LkDXrtqJc F3FwaDmveGaR2lOS0VsdgSxhkU3K2yxdyEjAAA69SuNRlNrYv7BscK76KsRoTYv38Lda5f lPS0P0n8pGCIIvL9bywv0WVzzVfyRl0R7ob3lOanM7dA1V3pG75LXkhdXENgMX3P2zCg0Z DdpcnaEYZQgwkYtvYssogg9uwyNPOiD8rn9BNCMepT1rYOmGnG5ElAW50v9YXw== From: Miquel Raynal Date: Tue, 17 Mar 2026 11:24:06 +0100 Subject: [PATCH v3 03/27] mtd: spi-nor: swp: Improve locking user experience 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: <20260317-winbond-v6-18-rc1-spi-nor-swp-v3-3-2ca9ea4e7b9b@bootlin.com> References: <20260317-winbond-v6-18-rc1-spi-nor-swp-v3-0-2ca9ea4e7b9b@bootlin.com> In-Reply-To: <20260317-winbond-v6-18-rc1-spi-nor-swp-v3-0-2ca9ea4e7b9b@bootlin.com> To: Pratyush Yadav , Michael Walle , Takahiro Kuwano , Richard Weinberger , Vignesh Raghavendra , Jonathan Corbet Cc: Tudor Ambarus , Sean Anderson , Thomas Petazzoni , Steam Lin , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Miquel Raynal , stable@kernel.org X-Mailer: b4 0.14.3 X-Last-TLS-Session-Version: TLSv1.3 In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails. It fails because the conditions "can_be_top" and "can_be_bottom" are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite option) and lock_len, which in practice should be reduced down to 0, is set to "nor->params->size - (ofs + len)" which is a positive number. This is wrong. An easy way is to simply add an extra condition. In the unlock() path, if we can achieve the same result from both sides, it means we unlock everything and lock_len must simply be 0. A comment is added to clarify that logic. Fixes: 3dd8012a8eeb ("mtd: spi-nor: add TB (Top/Bottom) protect support") Cc: stable@kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Michael Walle --- drivers/mtd/spi-nor/swp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c index 9b07f83aeac7..1d50db1ef1a0 100644 --- a/drivers/mtd/spi-nor/swp.c +++ b/drivers/mtd/spi-nor/swp.c @@ -280,8 +280,15 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff= _t ofs, u64 len) /* Prefer top, if both are valid */ use_top =3D can_be_top; =20 - /* lock_len: length of region that should remain locked */ - if (use_top) + /* + * lock_len: length of region that should remain locked. + * + * When can_be_top and can_be_bottom booleans are true, both adjacent + * regions are unlocked, thus the entire flash can be unlocked. + */ + if (can_be_top && can_be_bottom) + lock_len =3D 0; + else if (use_top) lock_len =3D nor->params->size - (ofs + len); else lock_len =3D ofs; --=20 2.51.1