Re: [PATCH 21/22] iio: dac: ad5686: add triggered buffer support
From: Jonathan Cameron
Date: Fri Apr 24 2026 - 13:17:08 EST
On Fri, 24 Apr 2026 10:20:43 +0100
Rodrigo Alencar <455.rodrigo.alencar@xxxxxxxxx> wrote:
> On 26/04/23 07:27PM, Jonathan Cameron wrote:
> > On Wed, 22 Apr 2026 15:45:55 +0100
> > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@xxxxxxxxxx> wrote:
>
> ...
>
> > > +static irqreturn_t ad5686_trigger_handler(int irq, void *p)
> > > +{
> > > + struct iio_poll_func *pf = p;
> > > + struct iio_dev *indio_dev = pf->indio_dev;
> > > + struct iio_buffer *buffer = indio_dev->buffer;
> > > + struct ad5686_state *st = iio_priv(indio_dev);
> > > + const struct iio_chan_spec *chan;
> > > + u16 val[AD5686_MAX_CHANNELS];
> >
> > I may be wrong but I suspect the static analysers won't like the
> > fact that only part of this is initialised and they can't
> > tell how much of it is then used. We might need some sanity checks
> > to keep them happy even though we know they will always be fine
> > (branch predictors should quickly make them near cost free).
>
> will just add = { } to end, so it get initialized to zero:
>
> u16 val[AD5686_MAX_CHANNELS] = { };
>
> > > + int ret, ch, i = 0;
> > > + bool async_update;
> > > + u8 cmd;
> > > +
> > > + ret = iio_pop_from_buffer(buffer, val);
> > At somepoint we should probably add a sanity check on buffer size to that.
>
> nothing to be done here then, I suppose that should be an API-level change
> for iio_pop_from_buffer().
>
Exactly. One for another day :)
J
> > > + if (ret)
> > > + goto out;
>