[PATCH v2] iio: adc: ti-ads124s08: Return reset GPIO lookup errors

[PATCH v2] iio: adc: ti-ads124s08: Return reset GPIO lookup errors

[Pengpeng Hou]

devm_gpiod_get_optional() returns NULL when the optional GPIO is absent,
but returns an ERR_PTR when the GPIO provider lookup fails, including
probe deferral.

Probe currently logs the ERR_PTR case as if the reset GPIO were simply
absent and keeps the error pointer in reset_gpio. Later ads124s_reset()
treats any non-NULL reset_gpio as a valid descriptor and passes it to
gpiod_set_value_cansleep().

Return the lookup error instead of retaining the ERR_PTR.

Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
Cc: stable@vger.kernel.org
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes in v2:
- Split from the v1 combined reset-failure patch.
- Keep only the GPIO ERR_PTR/probe-deferral fix.
- Add the Fixes tag requested by Andy.
- Carry Joshua's Reviewed-by, as allowed for a split version.

 drivers/iio/adc/ti-ads124s08.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ti-ads124s08.c b/drivers/iio/adc/ti-ads124s08.c
index 8ea1269f74db..73ad6ea9ef5d 100644
--- a/drivers/iio/adc/ti-ads124s08.c
+++ b/drivers/iio/adc/ti-ads124s08.c
@@ -321,7 +321,8 @@ static int ads124s_probe(struct spi_device *spi)
 	ads124s_priv->reset_gpio = devm_gpiod_get_optional(&spi->dev,
 						   "reset", GPIOD_OUT_LOW);
 	if (IS_ERR(ads124s_priv->reset_gpio))
-		dev_info(&spi->dev, "Reset GPIO not defined\n");
+		return dev_err_probe(&spi->dev, PTR_ERR(ads124s_priv->reset_gpio),
+				     "Failed to get reset GPIO\n");
 
 	ads124s_priv->chip_info = &ads124s_chip_info_tbl[spi_id->driver_data];
 
-- 
2.50.1

Re: [PATCH v2] iio: adc: ti-ads124s08: Return reset GPIO lookup errors

[Andy Shevchenko]

On Thu, Jun 25, 2026 at 01:44:07PM +0800, Pengpeng Hou wrote:
> devm_gpiod_get_optional() returns NULL when the optional GPIO is absent,
> but returns an ERR_PTR when the GPIO provider lookup fails, including
> probe deferral.
> 
> Probe currently logs the ERR_PTR case as if the reset GPIO were simply
> absent and keeps the error pointer in reset_gpio. Later ads124s_reset()
> treats any non-NULL reset_gpio as a valid descriptor and passes it to
> gpiod_set_value_cansleep().

The GPIOLIB code will print an error message each time that's called.
This might flood the logs with a noise.

> Return the lookup error instead of retaining the ERR_PTR.

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

It's good as a fix for backport, but can you consider switching to use reset
framework and reset-gpio driver instead? (As a separate change on top of this
one.)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] iio: adc: ti-ads124s08: Return reset GPIO lookup errors

[Jonathan Cameron]

On Thu, 25 Jun 2026 09:47:33 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Thu, Jun 25, 2026 at 01:44:07PM +0800, Pengpeng Hou wrote:
> > devm_gpiod_get_optional() returns NULL when the optional GPIO is absent,
> > but returns an ERR_PTR when the GPIO provider lookup fails, including
> > probe deferral.
> > 
> > Probe currently logs the ERR_PTR case as if the reset GPIO were simply
> > absent and keeps the error pointer in reset_gpio. Later ads124s_reset()
> > treats any non-NULL reset_gpio as a valid descriptor and passes it to
> > gpiod_set_value_cansleep().  
> 
> The GPIOLIB code will print an error message each time that's called.
> This might flood the logs with a noise.
> 
> > Return the lookup error instead of retaining the ERR_PTR.  
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> 
> It's good as a fix for backport, but can you consider switching to use reset
> framework and reset-gpio driver instead? (As a separate change on top of this
> one.)
> 

Applied to the fixes-togreg branch of iio.git.

One small process thing.  Please don't send new versions in reply to older
ones - just send a new thread.  Doing it as replies makes for confusing threads
and ensures they are many pages up in the maintainers inbox!

Jonathan