From nobody Tue Feb 10 22:56:36 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 646CD347BA3 for ; Fri, 14 Nov 2025 17:53:33 +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=1763142816; cv=none; b=HjhlouUGPhLLwwyZSiRd0UqE53UemuADIxkFHvFZI7kYst6aYk7gaJab5TH5G8nllHqquIpAXHMZLuGENdepWELEFAhzi+C0H9YDw+wDTqejtjssnYXZnaxhXg67oP+UvuerQmrKs6tS/wcVEZw9FEIUOZvNp3kF1OuNYB0gbGI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763142816; c=relaxed/simple; bh=rITH1oTXB9QbeqFibxYG19sQVo6xRjVQSg/WRgrNYjs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=b1TMh4rnsN5g9c4ZzHerEXbsueBy4/TJ63nMpOZHtwuFeRLOS8ZCqmvmj0rq4GreSAzFQpOr1p/6d5n+eMsG28lEPH9pXKCDSOLIBwCoSiy9Xhdv7I7FdQUlEpe2zBaGSlnvVH+wDniC3xpxj4hRb86cpj73Q0TsEu4keJLRR1Q= 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=QGKdlJrh; 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="QGKdlJrh" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id C49D84E416B7; Fri, 14 Nov 2025 17:53:31 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 998406060E; Fri, 14 Nov 2025 17:53:31 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 2E4AF10371997; Fri, 14 Nov 2025 18:53:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1763142810; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=98ui2AWqfgCc/02PfNjFtZFpjS6UsC5GFegQdo9CPOY=; b=QGKdlJrhYSNoY+0jlViAn3WjyJdZ3PfqQSnn+NZ/qfc55SgI3IRtcNVbM8oLhcxv/OvSSy s+s/G/wvO1VB9etfebFDagPSc3QW+H9rNbdAQ2zG1AUeYO7JK7rXKHfjuUXpFqV6eAX/bY 57mJTXQS+h+oifWldr6VPLyWLD/gGAeiNkskJ4f2t6k8EpmgGRQf1IWSBPVoJDl0JJO3dX FqDIFDf4/1dOcoqv4Xz9grfkxhoJLFxDaJcqaZnJWHHoYEbshTDsa6ghvGxe0oBS78BeKr 0Rt0DvAsDQFefM/3d5QEinn7yHr/wq5TBwTgy0J9VDvOaBrx09hbWybmq3aLwg== From: Miquel Raynal Date: Fri, 14 Nov 2025 18:53:07 +0100 Subject: [PATCH 06/19] 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: <20251114-winbond-v6-18-rc1-spi-nor-swp-v1-6-487bc7129931@bootlin.com> References: <20251114-winbond-v6-18-rc1-spi-nor-swp-v1-0-487bc7129931@bootlin.com> In-Reply-To: <20251114-winbond-v6-18-rc1-spi-nor-swp-v1-0-487bc7129931@bootlin.com> To: Tudor Ambarus , Pratyush Yadav , Michael Walle , Richard Weinberger , Vignesh Raghavendra , Jonathan Corbet Cc: 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.2 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. Signed-off-by: Miquel Raynal Reviewed-by: Michael Walle --- 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 9bc5a356444665ad8824e9e12d679fd551b3e67d..ede03f26de3c65ff53c1cb888c2= c43aea268b85a 100644 --- a/drivers/mtd/spi-nor/swp.c +++ b/drivers/mtd/spi-nor/swp.c @@ -341,6 +341,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.0