From nobody Tue Apr 7 01:06:54 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 0F0AE3A7585 for ; Tue, 17 Mar 2026 10:24:27 +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=1773743068; cv=none; b=nbXZbIXbCb2ej7Urce1BonUEEmECK0oW5gYdPIBIRd0OrO+CiWc5DRahhad27+vpb7c7v7r4fxUifrsEwqG8Da+Sba/cOO90tUjxo8ISi6lCVJ1Dj3wKu8ODcfSFgou1DXS4pFp/zJee3gDzvU2in1jSItBge4KDHLb9IKJr7B4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773743068; c=relaxed/simple; bh=m8EezPdj5/zLpTZs6LAb34kiI2GknFW1YMmMypIYx5U=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DivnCs41cswigrQ0VUutrwufRTRCeVfUMYCxcuZ7gqoBFUqqIUwa5uyEKXkEOJVIupQYHyxipAQ2BeObA+gaB19xNjKSaXwTxCz+fe1wD1hrdVIJVPLatH2JvLgUU/izHKA1GhaeITPUdCxxo3tM8N9L3thiPLnGMipUFI2jJew= 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=oOGaC2i9; 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="oOGaC2i9" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id DE8BB4E4263E; Tue, 17 Mar 2026 10:24:25 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id AF1145FC9A; Tue, 17 Mar 2026 10:24:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 95C80104503A6; Tue, 17 Mar 2026 11:24:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1773743064; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=uBSfAslupKiDUjYa9VdOz+tUE+1u7aYrr2OFADafudU=; b=oOGaC2i9lLEU64q+oZ0r2QGoz4idF7IPxDdsm3W4fLhv+7mnI+EUblWRysxMQg/Aqdryyv MlkyUFxKs+avwRfmAaHynkoVoqQxzC9/g3zWQtBP0D9jvYL0rTnWu0K79vhVckeMbRIo2X x/xcd57dsca5KaQirVOm/bv7flu3vbomsgBkWt5r9+Lhkxn9m1Qy8Vpx4gI3f06Uibv5Xn VPIXWqQoAyROOv05XR7Eup+PD5AOdWV9c7R5K5NoRfQLkTPLyNJBzQkjGN5GVj4aVrGHF1 sQJgfU4A++wePdwIQKHBu+/aYaelsdg7Fr5/JL3C6HWxmUiOKQ8TSwQicz2V7g== From: Miquel Raynal Date: Tue, 17 Mar 2026 11:24:10 +0100 Subject: [PATCH v3 07/27] mtd: spi-nor: swp: Explain the MEMLOCK ioctl implementation behaviour 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-7-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 X-Mailer: b4 0.14.3 X-Last-TLS-Session-Version: TLSv1.3 Add comments about how these requests are actually handled in the SPI NOR core. Their behaviour was not entirely clear to me at first, and explaining them in plain English sounds the way to go. Reviewed-by: Michael Walle Signed-off-by: Miquel Raynal --- drivers/mtd/spi-nor/swp.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c index 1d50db1ef1a0..64a917543928 100644 --- a/drivers/mtd/spi-nor/swp.c +++ b/drivers/mtd/spi-nor/swp.c @@ -346,6 +346,14 @@ static int spi_nor_sr_is_locked(struct spi_nor *nor, l= off_t ofs, u64 len) return spi_nor_is_locked_sr(nor, ofs, len, nor->bouncebuf[0]); } =20 +/* + * These ioctls behave according to the following rules: + * ->lock(): Never locks more than what is requested, ie. may lock less + * ->unlock(): Never unlocks more than what is requested, ie. may unlock l= ess + * -is_locked(): Checks if the region is *fully* locked, returns false oth= erwise. + * This feeback may be misleading because users may get an "= unlocked" + * status even though a subpart of the region is effectively= locked. + */ static const struct spi_nor_locking_ops spi_nor_sr_locking_ops =3D { .lock =3D spi_nor_sr_lock, .unlock =3D spi_nor_sr_unlock, --=20 2.51.1