On Sat, 2022-06-11 at 16:17 +0100, Jonathan Cameron wrote:
> On Fri, 10 Jun 2022 10:45:33 +0200
> Nuno Sá <nuno.sa@xxxxxxxxxx> wrote:
>
> > APIs like of_iio_channel_get_by_name() and of_iio_channel_get_all()
> > were
> > returning a mix of NULL and error pointers being NULL the way to
>
> pointers with NULL being the way to...
>
> > "notify" that we should do a "system" lookup for channels. This
> > make
> > it very confusing and prone to errors as commit dbbccf7c20bf
> > ("iio: inkern: fix return value in
> > devm_of_iio_channel_get_by_name()")
> > proves. On top of this, patterns like 'if (channel != NULL) return
> > channel'
> > were being used where channel could actually be an error code which
> > makes the code hard to read.
> >
> > Signed-off-by: Nuno Sá <nuno.sa@xxxxxxxxxx>
> > ---
> > drivers/iio/inkern.c | 24 +++++++++++-------------
> > 1 file changed, 11 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> > index 87fd2a0d44f2..31d9c122199a 100644
> > --- a/drivers/iio/inkern.c
> > +++ b/drivers/iio/inkern.c
> > @@ -214,7 +214,7 @@ static struct iio_channel
> > *of_iio_channel_get(struct device_node *np, int index)
> > struct iio_channel *of_iio_channel_get_by_name(struct device_node
> > *np,
> > const char *name)
> > {
> > - struct iio_channel *chan = NULL;
> > + struct iio_channel *chan;
> >
> > /* Walk up the tree of devices looking for a matching iio
> > channel */
> > while (np) {
> > @@ -231,11 +231,11 @@ struct iio_channel
> > *of_iio_channel_get_by_name(struct device_node *np,
> > name);
> > chan = of_iio_channel_get(np, index);
> > if (!IS_ERR(chan) || PTR_ERR(chan) == -
> > EPROBE_DEFER)
> > - break;
>
> This original behaviour is 'interesting'. If we get a error like -
> ENOMEM
> we should return it rather than carry on. Do we have enough
> knowledge
> of possible errors here to be more explicit on when we keep looking
> up
> the tree? I think we can get -ENOENT from
> of_parse_phandle_with_args()
>
> That raises an interesting question on whether -ENODEV is the right
> response
> for the previously NULL case or is -ENOENT more consistent with other
> of_ functions? No device could be thought of as being the case that
> needs
> to defer (in hope it turns up later) whereas no entry means it will
> never
> succeed.
>From what I could see, of_parse_phandle_with_args() either returns
-EINVAL or -ENOENT. We also have the internal of_iio_channel_get()
which can return -ENOMEM. So I guess we should only continue looking if
we get -ENOENT?
To be clear, do you still prefer to explicitly return -ENODEV in the
previous NULL cases or should we honor the return code from
of_parse_phandle_with_args() and just return chans (and thus ENOENT)?
- Nuno Sá
