On Mon, Mar 17, 2025 at 10:42:07AM +0200, Matti Vaittinen wrote: > 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? When it's a code path that returns the same error code for something different. > > 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. Okay, it seems we have got yet another disagreement as I think this has to be ENOENT. Because this is related to the firmware description and not real hardware discovery path. If it is the latter, I may fully agree on ENODEV choice. But AFAICS it's not the case here. > > 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 have the opposite opinion. I think ENODEV is _incorrect_ choice in this case. > 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. Again, the problem is that you are trying to apply the error code for HW to the information that comes from FW. > 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. Yeah, will wait for Jonathan to judge, but I think you can find rationale above. -- With Best Regards, Andy Shevchenko
