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 <[email protected]> > wrote: > > > From: Rodrigo Alencar <[email protected]> > > > > 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 <[email protected]> > > --- > > 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); > > >
