Re: [PATCH v1 1/1] iio: adc: ad7191: Don't check for specific errors when parsing properties

From: Nuno Sá

Date: Tue Apr 14 2026 - 06:04:49 EST


On Tue, Apr 14, 2026 at 12:33:50PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 14, 2026 at 12:31:14PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 14, 2026 at 10:10:38AM +0100, Nuno Sá wrote:
> > > On Sun, Apr 12, 2026 at 03:30:40PM +0100, Jonathan Cameron wrote:
> > > > On Tue, 17 Mar 2026 12:42:07 +0200
> > > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> ...
>
> > > > I left this one for a while to see if the discussion would continue but seems not.
> > > > I'm not sure it is always the case, but in this particular example I think the
> > > > resulting code is a little nicer to read so applied.
> > > >
> > > > So for me, case by case basis for this sort of change.
> > >
> > > Yeah, I missed this one! Anyways seems the way will be to explicitly
> > > use device_property_present() to check property presence. Still don't
> > > love the dual call thing so I might just stop checking for -EINVAL (was
> > > not doing it religiously anyways).
> > >
> > > Maybe we could have a set of optional variants of the API like
> > > device_property_read_*_optional() kind of thing where we just return 0
> > > if the property is not present. But might also be too noisy...
> >
> > I think that's what usually Sakari likes (tons of wrappers for each case :-).
> > I prefer be on the compromise side.
>
> Ah, and note, now we have kernel-doc updated to point out that _present is
> recommended way of unambiguously checking for the property presence.
>
> 70fa0c308aa2 ("device property: Document how to check for the property presence")

Yes, I did looked at it! That's why I said

"Anyways seems the way will be to explicitly use device_property_present()..."

- Nuno Sá

>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>