From: srini@kernel.org
To: gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, Marek Vasut <marex@nabladev.com>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Srinivas Kandagatla <srini@kernel.org>
Subject: [PATCH 03/14] nvmem: core: Default to read-only if wp-gpios present
Date: Sat, 30 May 2026 21:53:22 +0100 [thread overview]
Message-ID: <20260530205333.117458-4-srini@kernel.org> (raw)
In-Reply-To: <20260530205333.117458-1-srini@kernel.org>
From: Marek Vasut <marex@nabladev.com>
In case the nvmem DT node contains "wp-gpios" DT property, the device
currently defaults to read-write and the force_ro sysfs attribute reads
0. Switch to the default read-only, which is both safer, and aligned
with eMMC HW BOOT partition force_ro sysfs attribute behavior, which
also defaults to read-only.
The adjustment of nvmem->read_only value to read-only in case wp-gpios
DT property is present must be done only after the device_add() got
called because device_add() does internally call nvmem_bin_attr_get_umode(),
which configures the permissions of 'nvmem' bin attr based on the value
of nvmem->read_only that is only parsed from DT property 'read-only',
without any adjustment. This way, if DT property 'read-only' is present,
the 'nvmem' attribute is always read-only. Otherwise, if the device is
writeable, then 'nvmem' attribute is writeable, and nvmem->read_only
defaults to read-only, but can be switched to read-write at runtime via
the 'force_ro' attribute.
The updated behavior can be tested as follows:
Current content:
"
$ cat /sys/bus/nvmem/devices/logging7/force_ro
1
$ hexdump -C /sys/bus/nvmem/devices/logging7/nvmem
00000000 66 6f 6f 0a ff ff ff ff
"
Write into default-read-only device:
"
$ echo bar > /sys/bus/nvmem/devices/logging7/nvmem
bash: echo: write error: Operation not permitted
$ cat /sys/bus/nvmem/devices/logging7/force_ro
1
"
Unlock and write into device:
"
$ echo 0 > /sys/bus/nvmem/devices/logging7/force_ro
$ cat /sys/bus/nvmem/devices/logging7/force_ro
0
$ echo bar > /sys/bus/nvmem/devices/logging7/nvmem
$ hexdump -C /sys/bus/nvmem/devices/logging7/nvmem
00000000 62 61 72 0a ff ff ff ff
"
Relock and write into device, fails because device is read-only again:
"
$ echo 1 > /sys/bus/nvmem/devices/logging7/force_ro
$ echo baz > /sys/bus/nvmem/devices/logging7/nvmem
bash: echo: write error: Operation not permitted
$ hexdump -C /sys/bus/nvmem/devices/logging7/nvmem
00000000 62 61 72 0a ff ff ff ff
"
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
---
drivers/nvmem/core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 311cb2e5a5c0..be28a366f603 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1019,6 +1019,10 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
if (rval)
goto err_remove_dev;
+ /* If the device has WP GPIO, default to read-only */
+ if (nvmem->wp_gpio)
+ nvmem->read_only = true;
+
#ifdef CONFIG_NVMEM_SYSFS
rval = nvmem_populate_sysfs_cells(nvmem);
if (rval)
--
2.53.0
next prev parent reply other threads:[~2026-05-30 20:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-30 20:53 [PATCH 00/14] nvmem: patches for 7.2 srini
2026-05-30 20:53 ` [PATCH 01/14] dt-bindings: nvmem: qfprom: Add glymur compatible srini
2026-05-30 20:53 ` [PATCH 02/14] nvmem: rockchip-otp: alloc clks with main struct srini
2026-05-30 20:53 ` srini [this message]
2026-05-30 20:53 ` [PATCH 04/14] dt-bindings: nvmem: qfprom: qcom: Add Hawi compatible srini
2026-05-30 20:53 ` [PATCH 05/14] nvmem: nintendo-otp: Use of_device_get_match_data() srini
2026-05-30 20:53 ` [PATCH 06/14] dt-bindings: nvmem: qfprom: Add Milos compatible srini
2026-05-30 20:53 ` [PATCH 07/14] dt-bindings: nvmem: lan9662-otpc: Add LAN969x series srini
2026-05-30 20:53 ` [PATCH 08/14] nvmem: lan9662-otp: add support for LAN969x srini
2026-05-30 20:53 ` [PATCH 09/14] dt-bindings: nvmem: qcom,qfprom: Add Shikra compatible srini
2026-05-30 20:53 ` [PATCH 10/14] dt-bindings: nvmem: airoha: add SMC eFuses schema srini
2026-05-30 20:53 ` [PATCH 11/14] nvmem: airoha: Add support for SMC eFUSE srini
2026-05-30 20:53 ` [PATCH 12/14] nvmem: qcom: Unify user-visible "Qualcomm" name srini
2026-05-30 20:53 ` [PATCH 13/14] nvmem: cleanup dead code in Kconfig srini
2026-05-30 20:53 ` [PATCH 14/14] nvmem: layouts: u-boot-env: check earlier for ethaddr length srini
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=20260530205333.117458-4-srini@kernel.org \
--to=srini@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@nabladev.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox