Re: [PATCH] iio: adc: nxp-sar-adc: notify trigger on channel read error in buffer ISR

[Jonathan Cameron]

On Sun, 17 May 2026 12:07:33 -0500
David Lechner <dlechner@xxxxxxxxxxxx> wrote:

> On 5/17/26 11:23 AM, Stepan Ionichev wrote:
> > nxp_sar_adc_isr_buffer() bails on the first channel-read failure
> > without calling iio_trigger_notify_done(), so a single I/O error
> > leaves the trigger's use_count stuck and the buffer flow wedged
> > until rebind.
> > 
> > Route the error exit through a 'done:' label that always calls
> > iio_trigger_notify_done().
> > 
> > Fixes: 4434072a893e ("iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Stepan Ionichev <sozdayvek@xxxxxxxxx>
> > ---
> >  drivers/iio/adc/nxp-sar-adc.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/iio/adc/nxp-sar-adc.c b/drivers/iio/adc/nxp-sar-adc.c
> > index 9d9f2c76b..ed004812c 100644
> > --- a/drivers/iio/adc/nxp-sar-adc.c
> > +++ b/drivers/iio/adc/nxp-sar-adc.c
> > @@ -341,7 +341,7 @@ static void nxp_sar_adc_isr_buffer(struct iio_dev *indio_dev)
> >  		ret = nxp_sar_adc_read_data(info, info->buffered_chan[i]);
> >  		if (ret < 0) {
> >  			nxp_sar_adc_read_notify(info);
> > -			return;
> > +			goto done;
> >  		}
> >  
> >  		info->buffer[i] = ret;
> > @@ -352,6 +352,7 @@ static void nxp_sar_adc_isr_buffer(struct iio_dev *indio_dev)
> >  	iio_push_to_buffers_with_ts(indio_dev, info->buffer, sizeof(info->buffer),
> >  				    iio_get_time_ns(indio_dev));
> >  
> > +done:
> >  	iio_trigger_notify_done(indio_dev->trig);
> >  }
> >    
> 
> This is fine. Although we are already duplicating the call to
> nxp_sar_adc_read_notify(). So could be OK to just call
> iio_trigger_notify_done() and return too. Let's see if anyone
> else has an opinion.

Similar questions arise for this one to the rohm one I just reviewed
- does this actually help us?  What is the trigger, and is it going to
be in a state where it will ever refire if an error occurs in here?
Here we aren't dealing in bus issues, it's a state machine issue
(either software bug or hardware in wrong state) if we hit these
error paths.

That info needs to be in the commit description and again to me this
is a hardening change rather than a fix (with need to backport etc).

Jonathan

>