Re: [PATCH 21/22] iio: dac: ad5686: add triggered buffer support

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 24 Apr 2026 10:20:43 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> 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@kernel.org> 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;  
>