[PATCH v2 0/5] Using dev_err_probe as it simplifies error handling and ensures consistent error reporting.

[PATCH v2 0/5] Using dev_err_probe as it simplifies error handling and ensures consistent error reporting.

[Prashant Rahul]

Errors are logged when enabling the regulator or adding the cleanup action
fails, but not when buffer setup fails. This adds that missing log.

changes in v2:
- ti-adc084s021: drop unnecessary braces around single statement if block

v1: https://lore.kernel.org/linux-iio/20260618231543.413771-1-prashantrahul23@gmail.com/

Prashant Rahul (5):
  iio: adc: ti-adc081c: use dev_err_probe for probe time error
  iio: adc: ti-adc084s021: use dev_err_probe for probe time error
  iio: adc: ti-adc108s102: log buffer setup failure in probe
  iio: adc: ti-adc161s626: log buffer setup failure in probe
  iio: adc: ti-adc0832: log buffer setup failure in probe

 drivers/iio/adc/ti-adc081c.c    | 6 ++----
 drivers/iio/adc/ti-adc0832.c    | 2 +-
 drivers/iio/adc/ti-adc084s021.c | 6 ++----
 drivers/iio/adc/ti-adc108s102.c | 2 +-
 drivers/iio/adc/ti-adc161s626.c | 2 +-
 5 files changed, 7 insertions(+), 11 deletions(-)

--
2.54.0

[PATCH v2 1/5] iio: adc: ti-adc081c: use dev_err_probe for probe time error

[Prashant Rahul]

This simplifies error handling and ensures consistent error reporting.

Signed-off-by: Prashant Rahul <prashantrahul23@gmail.com>
---
 drivers/iio/adc/ti-adc081c.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/ti-adc081c.c b/drivers/iio/adc/ti-adc081c.c
index 33f82bdfeb94..29dd7cf25f79 100644
--- a/drivers/iio/adc/ti-adc081c.c
+++ b/drivers/iio/adc/ti-adc081c.c
@@ -190,10 +190,8 @@ static int adc081c_probe(struct i2c_client *client)
 
 	err = devm_iio_triggered_buffer_setup(&client->dev, iio, NULL,
 					      adc081c_trigger_handler, NULL);
-	if (err < 0) {
-		dev_err(&client->dev, "iio triggered buffer setup failed\n");
-		return err;
-	}
+	if (err < 0)
+		return dev_err_probe(&client->dev, err, "iio triggered buffer setup failed\n");
 
 	return devm_iio_device_register(&client->dev, iio);
 }
-- 
2.54.0

[PATCH v2 2/5] iio: adc: ti-adc084s021: use dev_err_probe for probe time error

[Prashant Rahul]

This simplifies error handling and ensures consistent error reporting.

Signed-off-by: Prashant Rahul <prashantrahul23@gmail.com>
---
 drivers/iio/adc/ti-adc084s021.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/ti-adc084s021.c b/drivers/iio/adc/ti-adc084s021.c
index a100f770fa1c..2b4bd223d816 100644
--- a/drivers/iio/adc/ti-adc084s021.c
+++ b/drivers/iio/adc/ti-adc084s021.c
@@ -229,10 +229,8 @@ static int adc084s021_probe(struct spi_device *spi)
 	ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev, NULL,
 					    adc084s021_buffer_trigger_handler,
 					    &adc084s021_buffer_setup_ops);
-	if (ret) {
-		dev_err(&spi->dev, "Failed to setup triggered buffer\n");
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(&spi->dev, ret, "Failed to setup triggered buffer\n");
 
 	return devm_iio_device_register(&spi->dev, indio_dev);
 }
-- 
2.54.0

[PATCH v2 3/5] iio: adc: ti-adc108s102: log buffer setup failure in probe

[Prashant Rahul]

Errors are logged when enabling the regulator or adding the cleanup
action fails, but not when buffer setup fails. Log the error returned by
the buffer setup path as well.

Signed-off-by: Prashant Rahul <prashantrahul23@gmail.com>
---
 drivers/iio/adc/ti-adc108s102.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ti-adc108s102.c b/drivers/iio/adc/ti-adc108s102.c
index 7d615e2bbf39..440afe584f5d 100644
--- a/drivers/iio/adc/ti-adc108s102.c
+++ b/drivers/iio/adc/ti-adc108s102.c
@@ -256,7 +256,7 @@ static int adc108s102_probe(struct spi_device *spi)
 					      &adc108s102_trigger_handler,
 					      NULL);
 	if (ret)
-		return ret;
+		return dev_err_probe(&spi->dev, ret, "iio triggered buffer setup failed\n");
 
 	ret = devm_iio_device_register(&spi->dev, indio_dev);
 	if (ret)
-- 
2.54.0

[PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Prashant Rahul]

Errors are logged when enabling the regulator or adding the cleanup
action fails, but not when buffer setup fails. Log the error returned by
the buffer setup path as well.

Signed-off-by: Prashant Rahul <prashantrahul23@gmail.com>
---
 drivers/iio/adc/ti-adc161s626.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ti-adc161s626.c b/drivers/iio/adc/ti-adc161s626.c
index be1cc2e77862..f83073280c9c 100644
--- a/drivers/iio/adc/ti-adc161s626.c
+++ b/drivers/iio/adc/ti-adc161s626.c
@@ -217,7 +217,7 @@ static int ti_adc_probe(struct spi_device *spi)
 	ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev, NULL,
 					      ti_adc_trigger_handler, NULL);
 	if (ret)
-		return ret;
+		return dev_err_probe(&spi->dev, ret, "iio triggered buffer setup failed\n");
 
 	return devm_iio_device_register(&spi->dev, indio_dev);
 }
-- 
2.54.0

[PATCH v2 5/5] iio: adc: ti-adc0832: log buffer setup failure in probe

[Prashant Rahul]

Errors are logged when enabling the regulator or adding the cleanup
action fails, but not when buffer setup fails. Log the error returned by
the buffer setup path as well.

Signed-off-by: Prashant Rahul <prashantrahul23@gmail.com>
---
 drivers/iio/adc/ti-adc0832.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ti-adc0832.c b/drivers/iio/adc/ti-adc0832.c
index cfcdafbe284b..417e54223092 100644
--- a/drivers/iio/adc/ti-adc0832.c
+++ b/drivers/iio/adc/ti-adc0832.c
@@ -299,7 +299,7 @@ static int adc0832_probe(struct spi_device *spi)
 	ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev, NULL,
 					      adc0832_trigger_handler, NULL);
 	if (ret)
-		return ret;
+		return dev_err_probe(&spi->dev, ret, "iio triggered buffer setup failed\n");
 
 	return devm_iio_device_register(&spi->dev, indio_dev);
 }
-- 
2.54.0

Re: [PATCH v2 0/5] Using dev_err_probe as it simplifies error handling and ensures consistent error reporting.

[Andy Shevchenko]

On Sat, Jun 20, 2026 at 11:10:52PM +0530, Prashant Rahul wrote:
> Errors are logged when enabling the regulator or adding the cleanup action
> fails, but not when buffer setup fails. This adds that missing log.

OK.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/5] iio: adc: ti-adc084s021: use dev_err_probe for probe time error

[Andy Shevchenko]

On Sat, Jun 20, 2026 at 11:10:54PM +0530, Prashant Rahul wrote:
> This simplifies error handling and ensures consistent error reporting.

...

> +++ b/drivers/iio/adc/ti-adc084s021.c

Side note: this also needs devm_mutex_init().

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 5/5] iio: adc: ti-adc0832: log buffer setup failure in probe

[Andy Shevchenko]

On Sat, Jun 20, 2026 at 11:10:57PM +0530, Prashant Rahul wrote:
> Errors are logged when enabling the regulator or adding the cleanup
> action fails, but not when buffer setup fails. Log the error returned by
> the buffer setup path as well.

...

> +++ b/drivers/iio/adc/ti-adc0832.c

So does this (devm_mutex_init() is needed). But they can be done separately
from this series.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Jonathan Cameron]

On Sat, 20 Jun 2026 23:10:56 +0530
Prashant Rahul <prashantrahul23@gmail.com> wrote:

> Errors are logged when enabling the regulator or adding the cleanup
> action fails, but not when buffer setup fails. Log the error returned by
> the buffer setup path as well.
Why this particular one but not the devm_iio_device_register() below it?
Both pretty much only fail on driver bugs.  Or out of memory for
which dev_err_probe() doesn't print anything anyway (on basis that
is normally pretty noisy).


> 
> Signed-off-by: Prashant Rahul <prashantrahul23@gmail.com>
> ---
>  drivers/iio/adc/ti-adc161s626.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ti-adc161s626.c b/drivers/iio/adc/ti-adc161s626.c
> index be1cc2e77862..f83073280c9c 100644
> --- a/drivers/iio/adc/ti-adc161s626.c
> +++ b/drivers/iio/adc/ti-adc161s626.c
> @@ -217,7 +217,7 @@ static int ti_adc_probe(struct spi_device *spi)
>  	ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev, NULL,
>  					      ti_adc_trigger_handler, NULL);
>  	if (ret)
> -		return ret;
> +		return dev_err_probe(&spi->dev, ret, "iio triggered buffer setup failed\n");
>  
>  	return devm_iio_device_register(&spi->dev, indio_dev);
>  }

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Andy Shevchenko]

On Tue, Jun 23, 2026 at 08:36:36PM +0100, Jonathan Cameron wrote:
> On Sat, 20 Jun 2026 23:10:56 +0530
> Prashant Rahul <prashantrahul23@gmail.com> wrote:
> 
> > Errors are logged when enabling the regulator or adding the cleanup
> > action fails, but not when buffer setup fails. Log the error returned by
> > the buffer setup path as well.
> Why this particular one but not the devm_iio_device_register() below it?
> Both pretty much only fail on driver bugs.  Or out of memory for
> which dev_err_probe() doesn't print anything anyway (on basis that
> is normally pretty noisy).

For the record, I need to withdraw my tag as I haven't noticed that this series
just adds tons of dead code (based on -ENOMEM returned value).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Prashant Rahul]

On Wed Jun 24, 2026 at 1:06 AM IST, Jonathan Cameron wrote:
> Why this particular one but not the devm_iio_device_register() below it?
> Both pretty much only fail on driver bugs.  Or out of memory for
> which dev_err_probe() doesn't print anything anyway (on basis that
> is normally pretty noisy).

My apologies, I wasnt aware that dev_err_probe simply ignores `-ENOMEM`.
Looking at drivers/base/core.c:5096, it is pretty evident that it does.

My goal with the patch series was to change dev_err into dev_err_probe,
as my understanding of dev_err_probe was that it's a specialization of
dev_err for probe contexts.

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Andy Shevchenko]

On Wed, Jun 24, 2026 at 03:43:44PM +0530, Prashant Rahul wrote:
> On Wed Jun 24, 2026 at 1:06 AM IST, Jonathan Cameron wrote:
> > Why this particular one but not the devm_iio_device_register() below it?
> > Both pretty much only fail on driver bugs.  Or out of memory for
> > which dev_err_probe() doesn't print anything anyway (on basis that
> > is normally pretty noisy).
> 
> My apologies, I wasnt aware that dev_err_probe simply ignores `-ENOMEM`.
> Looking at drivers/base/core.c:5096, it is pretty evident that it does.
> 
> My goal with the patch series was to change dev_err into dev_err_probe,
> as my understanding of dev_err_probe was that it's a specialization of
> dev_err for probe contexts.

Jonathan, actually the triggered buffer setup might return not -ENOMEM error
code for the surprise. After all this series does add not a dead code, but
a quite rare to be used one.

https://elixir.bootlin.com/linux/v7.1.1/source/drivers/iio/buffer/industrialio-triggered-buffer.c#L57


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Jonathan Cameron]

On Wed, 24 Jun 2026 14:26:52 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Jun 24, 2026 at 03:43:44PM +0530, Prashant Rahul wrote:
> > On Wed Jun 24, 2026 at 1:06 AM IST, Jonathan Cameron wrote:  
> > > Why this particular one but not the devm_iio_device_register() below it?
> > > Both pretty much only fail on driver bugs.  Or out of memory for
> > > which dev_err_probe() doesn't print anything anyway (on basis that
> > > is normally pretty noisy).  
> > 
> > My apologies, I wasnt aware that dev_err_probe simply ignores `-ENOMEM`.
> > Looking at drivers/base/core.c:5096, it is pretty evident that it does.
> > 
> > My goal with the patch series was to change dev_err into dev_err_probe,
> > as my understanding of dev_err_probe was that it's a specialization of
> > dev_err for probe contexts.  
> 
> Jonathan, actually the triggered buffer setup might return not -ENOMEM error
> code for the surprise. After all this series does add not a dead code, but
> a quite rare to be used one.
> 
> https://elixir.bootlin.com/linux/v7.1.1/source/drivers/iio/buffer/industrialio-triggered-buffer.c#L57
> 
> 

Agreed and I'm not even sure why that is there (lost to the mists of time
/ my failing memory ;)  However I think it's an obvious driver bug case
that should be trivial to see in basic tests so to me it's marginal on
whether a print on these is useful.

Maybe given that one is so rare we should just add a print in the core?
I'm not particularly keen on mass patches to print errors from the core
code but this one is perhaps a reasonable trade off vs series like this
one adding prints to drivers for something we don't think realistically
ever happens.

Jonathan
 

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Andy Shevchenko]

On Thu, Jun 25, 2026 at 12:09:52PM +0100, Jonathan Cameron wrote:
> On Wed, 24 Jun 2026 14:26:52 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Wed, Jun 24, 2026 at 03:43:44PM +0530, Prashant Rahul wrote:
> > > On Wed Jun 24, 2026 at 1:06 AM IST, Jonathan Cameron wrote:  

...

> > > > Why this particular one but not the devm_iio_device_register() below it?
> > > > Both pretty much only fail on driver bugs.  Or out of memory for
> > > > which dev_err_probe() doesn't print anything anyway (on basis that
> > > > is normally pretty noisy).  
> > > 
> > > My apologies, I wasnt aware that dev_err_probe simply ignores `-ENOMEM`.
> > > Looking at drivers/base/core.c:5096, it is pretty evident that it does.
> > > 
> > > My goal with the patch series was to change dev_err into dev_err_probe,
> > > as my understanding of dev_err_probe was that it's a specialization of
> > > dev_err for probe contexts.  
> > 
> > Jonathan, actually the triggered buffer setup might return not -ENOMEM error
> > code for the surprise. After all this series does add not a dead code, but
> > a quite rare to be used one.
> > 
> > https://elixir.bootlin.com/linux/v7.1.1/source/drivers/iio/buffer/industrialio-triggered-buffer.c#L57
> 
> Agreed and I'm not even sure why that is there (lost to the mists of time
> / my failing memory ;)  However I think it's an obvious driver bug case
> that should be trivial to see in basic tests so to me it's marginal on
> whether a print on these is useful.
> 
> Maybe given that one is so rare we should just add a print in the core?
> I'm not particularly keen on mass patches to print errors from the core
> code but this one is perhaps a reasonable trade off vs series like this
> one adding prints to drivers for something we don't think realistically
> ever happens.

While the series ends up not adding a dead code, the rareness of the case
doesn't justify it, so I am still on the side of _not_ applying this series.

For the core printing, I think for devm_*() or other managed resource APIs
it makes a lot of sense (in general). Not sure about plain calls, though.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Jonathan Cameron]

On Thu, 25 Jun 2026 17:03:11 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Thu, Jun 25, 2026 at 12:09:52PM +0100, Jonathan Cameron wrote:
> > On Wed, 24 Jun 2026 14:26:52 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:  
> > > On Wed, Jun 24, 2026 at 03:43:44PM +0530, Prashant Rahul wrote:  
> > > > On Wed Jun 24, 2026 at 1:06 AM IST, Jonathan Cameron wrote:    
> 
> ...
> 
> > > > > Why this particular one but not the devm_iio_device_register() below it?
> > > > > Both pretty much only fail on driver bugs.  Or out of memory for
> > > > > which dev_err_probe() doesn't print anything anyway (on basis that
> > > > > is normally pretty noisy).    
> > > > 
> > > > My apologies, I wasnt aware that dev_err_probe simply ignores `-ENOMEM`.
> > > > Looking at drivers/base/core.c:5096, it is pretty evident that it does.
> > > > 
> > > > My goal with the patch series was to change dev_err into dev_err_probe,
> > > > as my understanding of dev_err_probe was that it's a specialization of
> > > > dev_err for probe contexts.    
> > > 
> > > Jonathan, actually the triggered buffer setup might return not -ENOMEM error
> > > code for the surprise. After all this series does add not a dead code, but
> > > a quite rare to be used one.
> > > 
> > > https://elixir.bootlin.com/linux/v7.1.1/source/drivers/iio/buffer/industrialio-triggered-buffer.c#L57  
> > 
> > Agreed and I'm not even sure why that is there (lost to the mists of time
> > / my failing memory ;)  However I think it's an obvious driver bug case
> > that should be trivial to see in basic tests so to me it's marginal on
> > whether a print on these is useful.
> > 
> > Maybe given that one is so rare we should just add a print in the core?
> > I'm not particularly keen on mass patches to print errors from the core
> > code but this one is perhaps a reasonable trade off vs series like this
> > one adding prints to drivers for something we don't think realistically
> > ever happens.  
> 
> While the series ends up not adding a dead code, the rareness of the case
> doesn't justify it, so I am still on the side of _not_ applying this series.
> 
> For the core printing, I think for devm_*() or other managed resource APIs
> it makes a lot of sense (in general). Not sure about plain calls, though.
> 
For now I've picked up the two straight conversions to dev_err_probe()
because I'm keen to (slowly) stop using dev_err() in probe functions
but lets leave the rest for now at least.  If I get some time (you never
know) I might throw together an RFC that prints appropriate messages from
these IIO registration calls so we can have a debate about whether they
belong in the core or the drivers (or not at all).

Thanks,

Jonathan

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Prashant Rahul]

On Fri Jul 3, 2026 at 6:09 AM IST, Jonathan Cameron wrote:
> For now I've picked up the two straight conversions to dev_err_probe()
> because I'm keen to (slowly) stop using dev_err() in probe functions.

I can look for places where dev_err() is used and can be replaced with
dev_err_probe() in other probe functions, then create a new patch
series for it. Without adding new logs or removing any existing ones, of course.
Shouldn't take a lot of time, what do you think?

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Andy Shevchenko]

On Sat, Jul 04, 2026 at 09:20:46PM +0530, Prashant Rahul wrote:
> On Fri Jul 3, 2026 at 6:09 AM IST, Jonathan Cameron wrote:
> > For now I've picked up the two straight conversions to dev_err_probe()
> > because I'm keen to (slowly) stop using dev_err() in probe functions.
> 
> I can look for places where dev_err() is used and can be replaced with
> dev_err_probe() in other probe functions, then create a new patch
> series for it. Without adding new logs or removing any existing ones, of course.
> Shouldn't take a lot of time, what do you think?

In some cases it would make an additional churn. Each driver may require
a unique set of the cleanups and refactoring patches. Better to do something
that you have HW to test on.

I also removed some people from the Cc list. Why did you add them?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Prashant Rahul]

On Sat Jul 4, 2026 at 10:30 PM IST, Andy Shevchenko wrote:
> On Sat, Jul 04, 2026 at 09:20:46PM +0530, Prashant Rahul wrote:
>> On Fri Jul 3, 2026 at 6:09 AM IST, Jonathan Cameron wrote:
>> > For now I've picked up the two straight conversions to dev_err_probe()
>> > because I'm keen to (slowly) stop using dev_err() in probe functions.
>>
>> I can look for places where dev_err() is used and can be replaced with
>> dev_err_probe() in other probe functions, then create a new patch
>> series for it. Without adding new logs or removing any existing ones, of course.
>> Shouldn't take a lot of time, what do you think?
>
> In some cases it would make an additional churn. Each driver may require
> a unique set of the cleanups and refactoring patches. Better to do something
> that you have HW to test on.

Makes sense.

> I also removed some people from the Cc list. Why did you add them?

I am a little confused here. I only added people to the CC list who were
already present in the CC list of the original email. Am I missing
something?

regards,
Prashant Rahul

Re: [PATCH v2 4/5] iio: adc: ti-adc161s626: log buffer setup failure in probe

[Andy Shevchenko]

On Sat, Jul 4, 2026 at 8:28 PM Prashant Rahul <prashantrahul23@gmail.com> wrote:
>
> On Sat Jul 4, 2026 at 10:30 PM IST, Andy Shevchenko wrote:
> > On Sat, Jul 04, 2026 at 09:20:46PM +0530, Prashant Rahul wrote:
> >> On Fri Jul 3, 2026 at 6:09 AM IST, Jonathan Cameron wrote:
> >> > For now I've picked up the two straight conversions to dev_err_probe()
> >> > because I'm keen to (slowly) stop using dev_err() in probe functions.
> >>
> >> I can look for places where dev_err() is used and can be replaced with
> >> dev_err_probe() in other probe functions, then create a new patch
> >> series for it. Without adding new logs or removing any existing ones, of course.
> >> Shouldn't take a lot of time, what do you think?
> >
> > In some cases it would make an additional churn. Each driver may require
> > a unique set of the cleanups and refactoring patches. Better to do something
> > that you have HW to test on.
>
> Makes sense.
>
> > I also removed some people from the Cc list. Why did you add them?
>
> I am a little confused here. I only added people to the CC list who were
> already present in the CC list of the original email. Am I missing
> something?

Which original email? You sent the original patch with unrelated
people in the Cc list. get_maintainer.pl doesn't mention them in
relation to the patched driver.


-- 
With Best Regards,
Andy Shevchenko