According to the AD7816/7/8 datasheet, the AD7816 is an 8-pin device
and does not possess a BUSY pin. The BUSY pin is exclusive to the
16-pin AD7817.

The driver previously requested a 'busy' GPIO unconditionally for both
the AD7816 and AD7817. If a device tree correctly modeled the hardware
by omitting the busy-gpios property for the AD7816, devm_gpiod_get()
would return -ENOENT and cause the probe to fail.

Fix this by restricting the busy GPIO request strictly to the AD7817.

Signed-off-by: Taha Narimani <tahanarimani3443@gmail.com>
---
 drivers/staging/iio/adc/ad7816.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index 988eee3..0eac484 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -84,7 +84,7 @@ static int ad7816_spi_read(struct ad7816_chip_info *chip, u16 *data)
 		gpiod_set_value(chip->convert_pin, 1);
 	}
 
-if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
+	if (chip->id == ID_AD7817) {
 		while (gpiod_get_value(chip->busy_pin))
 			cpu_relax();
 	}
@@ -380,7 +380,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
 			ret);
 		return ret;
 	}
-	if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
+	if (chip->id == ID_AD7817) {
 		chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy",
 						GPIOD_IN);
 		if (IS_ERR(chip->busy_pin)) {
-- 
2.53.0

On Sat, May 30, 2026 at 05:35:12PM +0000, Taha Narimani wrote:
> According to the AD7816/7/8 datasheet, the AD7816 is an 8-pin device
> and does not possess a BUSY pin. The BUSY pin is exclusive to the
> 16-pin AD7817.
> 
> The driver previously requested a 'busy' GPIO unconditionally for both
> the AD7816 and AD7817. If a device tree correctly modeled the hardware
> by omitting the busy-gpios property for the AD7816, devm_gpiod_get()
> would return -ENOENT and cause the probe to fail.
> 
> Fix this by restricting the busy GPIO request strictly to the AD7817.
> 
> Signed-off-by: Taha Narimani <tahanarimani3443@gmail.com>

The patch is corrupted.

Otherwise this seems reasonable enough.  (I haven't read the datasheet
but I trust that you have).  Let's add Nishad to the CC list since he
is the one who first limitted it to not check ID_AD7818.

The other way to solve this would be to use devm_gpiod_get_optional()
in the probe() function and test for NULL in ad7816_spi_read().  I
think this would be a cleaner solution because then it works based
on the device trees instead of having to hardcode which devices
have it in the driver itself.

regards,
dan carpenter

Hi Dan,

Thank you very much for the review and the excellent suggestion.

Using devm_gpiod_get_optional() and checking for NULL is indeed a much
cleaner and more elegant approach than hardcoding the chip IDs. I
completely agree and will implement this logic in v2.

I also apologize for the corrupted patch format. I will ensure my git
send-email configuration is properly fixed for the next submission.

I will wait a few days to allow time for any further comments from
Nishad or others before sending out the updated v2 patch.

Thank you again for your time and guidance!

Best regards,
Taha Narimani

On Mon, Jun 1, 2026 at 3:07 PM Dan Carpenter <error27@gmail.com> wrote:
>
> On Sat, May 30, 2026 at 05:35:12PM +0000, Taha Narimani wrote:
> > According to the AD7816/7/8 datasheet, the AD7816 is an 8-pin device
> > and does not possess a BUSY pin. The BUSY pin is exclusive to the
> > 16-pin AD7817.
> >
> > The driver previously requested a 'busy' GPIO unconditionally for both
> > the AD7816 and AD7817. If a device tree correctly modeled the hardware
> > by omitting the busy-gpios property for the AD7816, devm_gpiod_get()
> > would return -ENOENT and cause the probe to fail.
> >
> > Fix this by restricting the busy GPIO request strictly to the AD7817.
> >
> > Signed-off-by: Taha Narimani <tahanarimani3443@gmail.com>
>
> The patch is corrupted.
>
> Otherwise this seems reasonable enough.  (I haven't read the datasheet
> but I trust that you have).  Let's add Nishad to the CC list since he
> is the one who first limitted it to not check ID_AD7818.
>
> The other way to solve this would be to use devm_gpiod_get_optional()
> in the probe() function and test for NULL in ad7816_spi_read().  I
> think this would be a cleaner solution because then it works based
> on the device trees instead of having to hardcode which devices
> have it in the driver itself.
>
> regards,
> dan carpenter
>