Re: [PATCH] nvmem: core: eeprom: at24: Handle EEPROM with both read-only and wp-gpios

[Marek Vasut <marex@nabladev.com>]

On 4/22/26 11:07 AM, Bartosz Golaszewski wrote:
> On Tue, Apr 21, 2026 at 4:08 PM Marek Vasut <marex@nabladev.com> 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 are
> not mutually exclusive but I think it's more of an accidental omission
> than a planned feature.
I think it is currently an undefined behavior, and this patch defines it.