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

[Bartosz Golaszewski]

On Wed, Apr 22, 2026 at 7:01 PM Marek Vasut <marex@xxxxxxxxxxxx> wrote:
>
> On 4/22/26 1:33 PM, Marek Vasut wrote:
> > 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 to amend my statement, I would also like to adjust an already
> upstream DT to make use of this default-read-only functionality now.
>
> I would however like to get go/no-go on this patch before I roll out the
> DT patches.
>

Yes, go ahead.

> > 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.
>
> Also, this default-read-only behavior is effectively the same behavior
> like the eMMC HW BOOT partitions have, they are also default read-only,
> but can be switched and written to by setting their force_ro sysfs
> attribute.

I see. Ok, please send a v2.

Bart