Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both read-only and wp-gpios
From: Marek Vasut
Date: Wed Apr 22 2026 - 12:28:38 EST
On 4/22/26 11:07 AM, Bartosz Golaszewski wrote:
On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut <marex@xxxxxxxxxxxx> wrote:
Handle special-case of AT24 EEPROM described in DT, which contains both
"read-only" and "wp-gpios" properties. Interpret this configuration as
default read-only, but with the possibility of unlock via force_ro sysfs
attribute.
Patch looks ok code-wise but does this really make sense? If an EEPROM
is read-only, we should forbid writes in the kernel. Which board uses
it? Can we simply remove the read-only flag from DT?
Currently I am not aware of any upstream users, I plan to introduce one once this patch or some for of it lands.
I have is an ID EEPROM which I would like to be able to program under special circumstances (hence the wp-gpios control) , but it should be by default read-only .
If I remove the read-only, then by default the EEPROM is read-write, which is undesired. If I remote wp-gpios then I loose access to the force_ro attribute which controls the nWP GPIO from userspace, which is undesired.
So I think defining this special-case where wp-gpios and read-only are used together as default-read-only is sensible.
Admittedly: the DT bindings do allow it as read-only and wp-gpios areI think it is currently an undefined behavior, and this patch defines it.
not mutually exclusive but I think it's more of an accidental omission
than a planned feature.