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

[Marek Vasut]

On 4/23/26 4:19 PM, Bartosz Golaszewski wrote:
> On Thu, Apr 23, 2026 at 4:06 PM Marek Vasut <marex@xxxxxxxxxxxx> wrote:
> > On 4/23/26 2:17 PM, Bartosz Golaszewski wrote:
> > > On Thu, Apr 23, 2026 at 2:04 PM Marek Vasut <marex@xxxxxxxxxxxx> wrote:
> > > > > I see. Ok, please send a v2.
> > > > Does this patch require any changes ?
> > > >
> > > > I will be sending the DT changes separately.
> > >
> > > Sashiko is saying this:
> > > https://sashiko.dev/#/patchset/20260421140755.54222-1-marex%40nabladev.com
> >
> > What does this mean ?
> >
> > > Shouldn't we report the device as read-only in sysfs unless it was
> > > "unlocked" with force_ro?
> > This would be ideal, but I did not find a way to toggle the "nvmem" bin
> > attr permissions at runtime. Is that even possible ?
>
> Right, it seems like it's set once and can't be changed (Greg: correct
> me if I'm wrong).
>
> Ok, nevermind the comment then. Maybe just split the changes into
> nvmem and at24 changes and I can take both with an Ack from Srini.
I have two more ideas I would like to run past you ... how about either:

- If wp-gpios is present, set the device as default RO after boot, and
  let force_ro sysfs attribute toggle the protection of the device back
  and forth afterward. This would however change the userspace facing
  behavior slightly, because right now, with wp-gpios present in DT, the
  device is default RW.

- Introduce new DT property, wp-gpios-default-read-only or
  default-read-only or some such, to indicate the device should be in
  read-only mode by default. That would mitigate the downside of the
  aforementioned point, but would require a new DT property.

Thoughts ?