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

[Marek Vasut]

On 4/23/26 9:42 AM, Bartosz Golaszewski wrote:
> 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.
Does this patch require any changes ?

I will be sending the DT changes separately.