Re: [PATCH v7 2/9] iio: ssp_sensors: factor out pending list add/remove helper(s)

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 6 May 2026 10:37:23 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Tue, May 05, 2026 at 05:38:59PM +0100, Jonathan Cameron wrote:
> > On Sun, 03 May 2026 16:53:27 +0530
> > Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:  
> > > On 26 April 2026 7:38:30 pm IST, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > >On Sun, 26 Apr 2026 14:47:03 +0530
> > > >Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:  
> 
> ...
> 
> > > >> +	if (msg->length == 0)
> > > >> +		return;    
> > > >
> > > >I know Andy suggested your bring these into the helpers, but to me
> > > >it's obscuring flow as it looks at the caller like it was added
> > > >to the pending list when it wasn't..  And we end up with multiple
> > > >checks on msg_length where we had one before.
> > > >
> > > >One option would be to have it return a bool to indicate whether
> > > >it was added to the pending list or not.
> > > >
> > > >Andy, would that work for you?  
> 
> I don't remember if I answered anything to this, but returning bool is fine...
> 
> ...
> 
> > > If we convert this change to sub-function then suggested use_irq would be
> > > shifted to sub-function; then how would you suggest to handle that bool ?
> > > - keep msg->length as it is
> > > - in sub function __ssp_do_transfer(data, msg), should we pass additional
> > > parameter to bool for further execution?  
> > Pass in any additional parameters you need. If it becomes too long then 
> > this was a bad idea and you should ignore me ;)  
> 
> ...however, the coding style (or some documentation) suggests against bool
> parameters to the functions.
> 
How much duplication do we actually get if we split it?  So have totally
seperate functions for what would otherwise have been true / false values
of that parameter and pick at the caller?

Maybe that ends up cleaner.  To be honest this needs someone to play around
and see what works out as least hideous.

Jonathan

> > > Or any better alternative to handle both ?
> > >   
> > > >Then we only have a simple check on return value from that to decide
> > > >to increment the counter and exit on error.  
>