Re: [PATCH v2 2/7] nvmem: return -EOPNOTSUPP to in-kernel users on missing callbacks

[Bartosz Golaszewski]

On Mon, Mar 23, 2026 at 5:21 PM Johan Hovold <johan@xxxxxxxxxx> wrote:
>
> >  static int __nvmem_reg_write(struct nvmem_device *nvmem, unsigned int offset,
> > @@ -66,14 +66,14 @@ static int __nvmem_reg_write(struct nvmem_device *nvmem, unsigned int offset,
> >  {
> >       int ret;
> >
> > -     if (nvmem->reg_write) {
> > -             gpiod_set_value_cansleep(nvmem->wp_gpio, 0);
> > -             ret = nvmem->reg_write(nvmem->priv, offset, val, bytes);
> > -             gpiod_set_value_cansleep(nvmem->wp_gpio, 1);
> > -             return ret;
> > -     }
> > +     if (!nvmem->reg_write)
> > +             return -EOPNOTSUPP;
> > +
> > +     gpiod_set_value_cansleep(nvmem->wp_gpio, 0);
> > +     ret = nvmem->reg_write(nvmem->priv, offset, val, bytes);
> > +     gpiod_set_value_cansleep(nvmem->wp_gpio, 1);
> >
> > -     return -EINVAL;
> > +     return ret;
> >  }
>
> The above looks like good clean ups in their own right.
>
> But shouldn't the check be moved to to nvmem_reg_read/write() to avoid
> calling into nvmem_access_with_keepouts()?
>

That would make the later SRCU patch more complex (we'd need to
dereference ops earlier and pass them un-rcu'ed separately) and extend
the read critical sections unnecessairly. I think it's better to keep
it as is.

>
> Did you make sure that there are no in-kernel callers that will get
> confused by the -EINVAL => -EOPNOTSUPP change?
>

I made reasonably sure by grepping the code myself as well as asking
Claude to take a look. Looks safe.

Bart