RE: [PATCH] iio: adc: ad4695: Fix call ordering in offload buffer postenable

[Sabau, Radu bogdan]

> -----Original Message-----
> From: David Lechner <dlechner@xxxxxxxxxxxx>
> Sent: Tuesday, March 31, 2026 5:02 PM

...

> >
> >  	/*
> > -	 * NB: technically, this is part the SPI offload trigger enable, but it
> > -	 * doesn't work to call it from the offload trigger enable callback
> > -	 * because it requires accessing the SPI bus. Calling it from the
> > -	 * trigger enable callback could cause a deadlock.
> > +	 * NB: these are technically part of the SPI offload trigger enable, but
> > +	 * they can't be called from the offload trigger enable callback because
> > +	 * they require accessing the SPI bus. Calling them from the trigger
> > +	 * enable callback could cause a deadlock.
> 
> I didn't see a explanation for changing the comment here. I think "this" is
> still correct instead of "these" because only the BUSY pin is the trigger,
> so only the one regmap_set_bits() below would be in the trigger callback
> if it was possible.

I was thinking this comment could be left untouched as well, but couldn't
decide on whether to modify it or not and thought is better to wait for a
second opinion on it. Thanks for clarifying this!

> 
> If we want to improve the comment to make it more clear, I would save that
> for a separate patch and specifically mention the BUSY output.
> 
> >  	 */
> >  	ret = regmap_set_bits(st->regmap, AD4695_REG_GP_MODE,
> >  			      AD4695_REG_GP_MODE_BUSY_GP_EN);
> >  	if (ret)
> >  		goto err_unoptimize_message;

...

> >
> > -err_offload_exit_conversion_mode:
> > +err_trigger_disable:
> >  	/*
> > -	 * We have to unwind in a different order to avoid triggering offload.
> > -	 * ad4695_exit_conversion_mode() triggers a conversion, so it has to
> be
> > -	 * done after spi_offload_trigger_disable().
> > +	 * ad4695_exit_conversion_mode() triggers a conversion, so the
> offload
> > +	 * must be disabled first to avoid capturing a spurious sample.
> 
> Since this becomes the natural unwinding order, I don't think we need
> the comment at all any more.
> 
> There is still a similar comment in ad4695_offload_buffer_predisable()
> so we aren't losing this information if we remove it here.
> 

Yep, I agree on this, too. The comment in postenable could be removed.