Re: [PATCH v6 3/8] iio: backend: add API for oversampling
From: Jonathan Cameron
Date: Sat Nov 23 2024 - 11:03:04 EST
On Mon, 11 Nov 2024 16:41:02 +0100
Nuno Sá <noname.nuno@xxxxxxxxx> wrote:
> On Mon, 2024-11-11 at 14:11 +0200, Antoniu Miclaus wrote:
> > Add backend support for enabling/disabling oversampling.
> >
> > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@xxxxxxxxxx>
> > ---
> > changes in v6:
> > - add iio backend commit for oversampling enable/disable
> > drivers/iio/industrialio-backend.c | 14 ++++++++++++++
> > include/linux/iio/backend.h | 3 +++
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-
> > backend.c
> > index ea184fc2c838..6ba445ba3dd0 100644
> > --- a/drivers/iio/industrialio-backend.c
> > +++ b/drivers/iio/industrialio-backend.c
> > @@ -681,6 +681,20 @@ 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_en - set the data width/size in the data bus.
>
> Seems unrelated?
>
> > + * @back: Backend device
> > + * @en: oversampling enabled/disabled.
> > + *
> > + * Return:
> > + * 0 on success, negative error number on failure.
> > + */
> > +int iio_backend_oversampling_en(struct iio_backend *back, bool en)
Odd to just be on or off vs a count of how much to oversample by
with 1 meaning don't oversample, 2,4,8 etc saying how much to oversample by.
> > +{
> > + return iio_backend_op_call(back, oversampling_en, en);
> > +}
> > +EXPORT_SYMBOL_NS_GPL(iio_backend_oversampling_en, IIO_BACKEND);
> > +
>
> There was some discussion around having APIs with a boolean parameter (actually
> even improving - in terms of callbacks - further with some generic
> getter/setter's) or having two callbacks:
>
> iio_backend_oversampling_enable()
> iio_backend_oversampling_disable()
>
> I'm guessing you don't really want to do any major conversion/refactoring at
> this point in your series so I have a slight preference for just keeping the
> current style of dedicated enable and disable APIs (irrespective of being the
> better approach or not). Please consider it, if you have to re-spin the series.
Agreed. Keep it consistent for now. I don't mind a proposal to refactor
the lot (though not yet convinced either way on it being a good idea)
but I don't want to see it inconsistent.
>
> - Nuno Sá
>
>