Re: [PATCH 13/22] iio: dac: ad5686: fix input raw value check

[Nuno Sá]

On Thu, Apr 23, 2026 at 07:03:02PM +0100, Jonathan Cameron wrote:
> On Wed, 22 Apr 2026 15:45:47 +0100
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@xxxxxxxxxx> wrote:
> 
> > From: Rodrigo Alencar <rodrigo.alencar@xxxxxxxxxx>
> > 
> > Use in_range() to fix range check for input raw value, which is off by
> > one, i.e., for a 10-bit DAC the max valid value is 1023, but 1 << 10
> > equals 1024, which passes the previous check, allowing an out-of-range
> > write.
> > 
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@xxxxxxxxxx>
> > ---
> >  drivers/iio/dac/ad5686.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> > index 19d791c655b7..07a944311f0e 100644
> > --- a/drivers/iio/dac/ad5686.c
> > +++ b/drivers/iio/dac/ad5686.c
> > @@ -185,7 +185,7 @@ static int ad5686_write_raw(struct iio_dev *indio_dev,
> >  
> >  	switch (mask) {
> >  	case IIO_CHAN_INFO_RAW:
> > -		if (val > (1 << chan->scan_type.realbits) || val < 0)
> > +		if (!in_range(val, 0, 1 << chan->scan_type.realbits))
> 
> Might just be me, but I do find in range a bit weird when the offset is 0.
> 
> I'd be tempted to just make the check >=

FWIW, I also don't love the fact that we need to define the range instead
of pure min/max. But in this case, given that "min" is 0 it actually
works without extra defines :)

Having said the above, no preferences on my side.

- Nuno Sá
>  
> >  			return -EINVAL;
> >  
> >  		mutex_lock(&st->lock);
> > 
>