Re: [PATCH v10 3/8] iio: backend: add API for oversampling

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 17 Jan 2025 16:17:13 +0000
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Fri, 2025-01-17 at 15:06 +0200, Antoniu Miclaus wrote:
> > Add backend support for setting oversampling ratio.
> > 
> > Reviewed-by: David Lechner <dlechner@baylibre.com>
> > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
> > ---
> > no changes in v10.
> >  drivers/iio/industrialio-backend.c | 15 +++++++++++++++
> >  include/linux/iio/backend.h        |  5 +++++
> >  2 files changed, 20 insertions(+)
> > 
> > diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-
> > backend.c
> > index 2088afa7a55c..d4ad36f54090 100644
> > --- a/drivers/iio/industrialio-backend.c
> > +++ b/drivers/iio/industrialio-backend.c
> > @@ -681,6 +681,21 @@ int iio_backend_data_size_set(struct iio_backend *back,
> > unsigned int size)
> >  }
> >  EXPORT_SYMBOL_NS_GPL(iio_backend_data_size_set, "IIO_BACKEND");
> >  
> > +/**
> > + * iio_backend_oversampling_ratio_set - set the oversampling ratio
> > + * @back: Backend device
> > + * @ratio: The oversampling ratio - value 1 corresponds to no oversampling.
> > + *
> > + * Return:
> > + * 0 on success, negative error number on failure.
> > + */
> > +int iio_backend_oversampling_ratio_set(struct iio_backend *back,
> > +				       unsigned int ratio)
> > +{
> > +	return iio_backend_op_call(back, oversampling_ratio_set, ratio);
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iio_backend_oversampling_ratio_set, "IIO_BACKEND");
> > +  
> 
> Hmm, I'm very late to the party so don't bother in sending another revision
> unless you have too. But if you do, I would prefer to have this through a
> write_raw() interface. Meaning we would only have write_raw() as a backend op
> and  then you could add this as a convenient inline helper built on top of
> write_raw(). So this would be inline with what happens with read_raw(). Anyways,
> we can clean it up afterwards since we already have a .set_sample_rate() op that
> could use a similar approach.
I'm not against this, but just to mention that will run into the question of
whether to support the more complex value types.  I guess for now perhaps
pass in val, val2 and the write type and just reject anything that isn't
supported by a particular backend.

> 
> - Nuno Sá
> 
>