Re: [PATCH v7 05/10] iio: adc: sun20i-gpadc: Use adc-helpers

[Matti Vaittinen]

On 17/03/2025 09:51, Andy Shevchenko wrote:
> On Mon, Mar 17, 2025 at 09:11:08AM +0200, Matti Vaittinen wrote:
> > On 16/03/2025 11:41, Jonathan Cameron wrote:
> > > On Thu, 13 Mar 2025 14:34:24 +0200
> > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > > On Thu, Mar 13, 2025 at 09:18:49AM +0200, Matti Vaittinen wrote:
>
> ...
>
> > > > > +	num_channels = devm_iio_adc_device_alloc_chaninfo_se(dev,
> > > > > +				&sun20i_gpadc_chan_template, -1, &channels);
> > > > > +	if (num_channels < 0)
> > > > > +		return num_channels;
> > > > > +
> > > > >    	if (num_channels == 0)
> > > > >    		return dev_err_probe(dev, -ENODEV, "no channel children\n");
> > > >
> > > > Note, this what I would expected in your helper to see, i.e. separated cases
> > > > for < 0 (error code) and == 0, no channels.
> > > >
> > > > Also, are all users going to have this check? Usually in other similar APIs
> > > > we return -ENOENT. And user won't need to have an additional check in case of
> > > > 0 being considered as an error case too.
> > > In a few cases we'll need to do the dance the other way in the caller.
> > > So specifically check for -ENOENT and not treat it as an error.
> > >
> > > That stems from channel nodes being optionally added to drivers after
> > > they have been around a while (usually to add more specific configuration)
> > > and needing to maintain old behaviour of presenting all channels with default
> > > settings.
> > >
> > > I agree that returning -ENOENT is a reasonable way to handle this.
> >
> > I agree - but I'm going to use -ENODEV instead of -ENOENT because that's
> > what the current callers return if they find no channels. That way the
> > drivers can return the value directly without converting -ENOENT to -ENODEV.
>
> ENODEV can be easily clashed with other irrelevant cases,

Can you please explain what cases?

> ENOENT is the correct
> error code.

I kind of agree if we look this from the fwnode perspective. But, when 
we look this from the intended user's perspective, I can very well 
understand the -ENODEV. Returning -ENODEV from ADC driver's probe which 
can't find any of the channels feels correct to me.

> If drivers return this instead of another error code, nothing bad
> happen, it's not an ABI path, correct?

I don't know if failure returned from a probe is an ABI. I still feel 
-ENODEV is correct value, and I don't want to change it for existing 
users - and I think also new ADC drivers should use -ENODEV if they find 
no channels at all.

Besides that I think -ENODEV to be right, changing it to -ENOENT for 
existing callers requires a buy-in from Jonathan (and/or) the driver 
maintainers.

Yours,
	-- Matti