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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.