lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241006144841.08fb2102@jic23-huawei>
Date: Sun, 6 Oct 2024 14:48:41 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Angelo Dureghello <adureghello@...libre.com>
Cc: Nuno Sá <noname.nuno@...il.com>, Lars-Peter Clausen
 <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>, Nuno
 Sa <nuno.sa@...log.com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Mihail Chindris
 <mihail.chindris@...log.com>, Olivier Moysan <olivier.moysan@...s.st.com>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, devicetree@...r.kernel.org,
 dlechner@...libre.com, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v4 06/11] iio: backend: extend features

On Fri, 4 Oct 2024 15:45:21 +0200
Angelo Dureghello <adureghello@...libre.com> wrote:

> Hi Nuno,
> 
> On 04.10.2024 14:54, Nuno Sá wrote:
> > On Thu, 2024-10-03 at 19:29 +0200, Angelo Dureghello wrote:  
> > > From: Angelo Dureghello <adureghello@...libre.com>
> > > 
> > > Extend backend features with new calls needed later on this
> > > patchset from axi version of ad3552r.
> > > 
> > > The follwoing calls are added:
> > > 
> > > iio_backend_ddr_enable
> > > 	enable ddr bus transfer
> > > iio_backend_ddr_disable
> > > 	disable ddr bus transfer
> > > iio_backend_buffer_enable
> > > 	enable buffer
> > > iio_backend_buffer_disable
> > > 	disable buffer
> > > iio_backend_data_transfer_addr
> > > 	define the target register address where the DAC sample
> > > 	will be written.
> > > 
> > > Signed-off-by: Angelo Dureghello <adureghello@...libre.com>
> > > ---
> > >  drivers/iio/industrialio-backend.c | 79 ++++++++++++++++++++++++++++++++++++++
> > >  include/linux/iio/backend.h        | 17 ++++++++
> > >  2 files changed, 96 insertions(+)
> > > 
> > > diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-
> > > backend.c
> > > index 20b3b5212da7..d5e0a4da761e 100644
> > > --- a/drivers/iio/industrialio-backend.c
> > > +++ b/drivers/iio/industrialio-backend.c
> > > @@ -718,6 +718,85 @@ static int __devm_iio_backend_get(struct device *dev, struct
> > > iio_backend *back)
> > >  	return 0;
> > >  }
> > >  
> > > +/**
> > > + * iio_backend_ddr_enable - Enable interface DDR (Double Data Rate) mode
> > > + * @back: Backend device
> > > + *
> > > + * Enable DDR, data is generated by the IP at each front (raising and falling)
> > > + * of the bus clock signal.
> > > + *
> > > + * RETURNS:
> > > + * 0 on success, negative error number on failure.
> > > + */
> > > +int iio_backend_ddr_enable(struct iio_backend *back)
> > > +{
> > > +	return iio_backend_op_call(back, ddr_enable);
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iio_backend_ddr_enable, IIO_BACKEND);
> > > +
> > > +/**
> > > + * iio_backend_ddr_disable - Disable interface DDR (Double Data Rate) mode
> > > + * @back: Backend device
> > > + *
> > > + * Disable DDR, setting into SDR mode (Single Data Rate).
> > > + *
> > > + * RETURNS:
> > > + * 0 on success, negative error number on failure.
> > > + */
> > > +int iio_backend_ddr_disable(struct iio_backend *back)
> > > +{
> > > +	return iio_backend_op_call(back, ddr_disable);
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iio_backend_ddr_disable, IIO_BACKEND);
> > > +
> > > +/**
> > > + * iio_backend_dma_stream_enable - Enable iio buffering
> > > + * @back: Backend device
> > > + *
> > > + * Enabling sending the dma data stream over the bus.
> > > + * bus interface.
> > > + *
> > > + * RETURNS:
> > > + * 0 on success, negative error number on failure.
> > > + */
> > > +int iio_backend_dma_stream_enable(struct iio_backend *back)
> > > +{
> > > +	return iio_backend_op_call(back, dma_stream_enable);
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iio_backend_dma_stream_enable, IIO_BACKEND);
> > > +
> > > +/**
> > > + * iio_backend_dma_stream_disable - Disable iio buffering
> > > + * @back: Backend device
> > > + *
> > > + * Disable sending the dma data stream over the bus.
> > > + *
> > > + * RETURNS:
> > > + * 0 on success, negative error number on failure.
> > > + */
> > > +int iio_backend_dma_stream_disable(struct iio_backend *back)
> > > +{
> > > +	return iio_backend_op_call(back, dma_stream_disable);
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(iio_backend_dma_stream_disable, IIO_BACKEND);
> > > +  
> > 
> > I'm not sure if this is what Jonathan was suggesting... Ate least I don't really
> > agree with it. I mean, yes, this is about buffering and to start receiving (or
> > sending) a stream of data. But AFAICT, it might have nothing to do with DMA. Same as
> > .request_buffer() - It's pretty much always a DMA one but we should not take that for
> > granted.

Agreed. The stream bit works, the DMA is more tenuous.  Maybe *data_stream_enable()
is generic enough.

> > 
> > So going back to the RFC [1], you can see I was suggesting something like struct
> > iio_buffer_setup_ops. Maybe just add the ones we use for now? So that would
> > be.buffer_postenable() and .buffer_predisable(). Like this, it should be obvious the
> > intent of the ops.
> >   
> ok, thanks,
> 
> so something as :
> 
> struct iio_backend_setup_ops {
> 	int (*buffer_postenable)(struct iio_backend *back);
> 	int (*buffer_predisable)(struct iio_backend *back);

Hmm. Maybe.  My issue with the original naming was the lack of clarify of
what it actually meant.  I'm not sure this helps though in some cases we
do put similar calls in the postenable callback (ones that start the
data flow) so at least it's consistent with that.

Jonathan
> };
> 
> struct iio_backend_ops {
> 	struct iio_backend_setup_ops setup_ops;
> 
> ?
> 
> > - Nuno Sá
> > 
> >   
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ