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

[Bartosz Golaszewski]

On Thu, Apr 23, 2026 at 9:15 PM Marek Vasut <marex@xxxxxxxxxxxx> wrote:
>
> 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

Isn't this already what happens though? nvmem core requests the GPIO
as output-high and drives it low only when it's doing the writing.

>    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.
>

Or do you mean just the file permissions?

If the latter, then that does sound logically sound but yeah, it's
asking for a regression report. :)

> - 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 ?

I like "default-read-only" and it both allows to introduce this
behavior and not break existing users. Let's loop in DT maintainers
and see. I'd just like to clarify if we're talking about sysfs
permissions or GPIO behavior here.

Bart