linux-kernel - Re: [PATCH 06/13] iio: buffer: add hardware triggered buffer support

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: <96e211915fbc2cfb245a377e3ea6ddf3ef55d8f7.camel@gmail.com>
Date: Fri, 12 Jan 2024 17:50:50 +0100
From: Nuno Sá <noname.nuno@...il.com>
To: David Lechner <dlechner@...libre.com>, Jonathan Cameron
	 <Jonathan.Cameron@...wei.com>
Cc: Mark Brown <broonie@...nel.org>, Jonathan Cameron <jic23@...nel.org>, 
 Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
 Michael Hennerich <michael.hennerich@...log.com>,  Nuno
 Sá <nuno.sa@...log.com>, Frank Rowand
 <frowand.list@...il.com>, Thierry Reding <thierry.reding@...il.com>, Uwe
 Kleine-König <u.kleine-koenig@...gutronix.de>, Jonathan
 Corbet <corbet@....net>,  linux-spi@...r.kernel.org,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
 linux-doc@...r.kernel.org, linux-pwm@...r.kernel.org, 
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/13] iio: buffer: add hardware triggered buffer support

On Fri, 2024-01-12 at 09:42 -0600, David Lechner wrote:
> On Fri, Jan 12, 2024 at 6:37 AM Jonathan Cameron
> <Jonathan.Cameron@...wei.com> wrote:
> > 
> > On Wed, 10 Jan 2024 13:49:47 -0600
> > David Lechner <dlechner@...libre.com> wrote:
> > 
> > > This adds a new mode INDIO_HW_BUFFER_TRIGGERED to the IIO subsystem.
> > > 
> > > This mode is essentially the hardware version of INDIO_BUFFER_TRIGGERED
> > > where the trigger has the semantics of INDIO_HARDWARE_TRIGGERED and the
> > > buffer has the semantics of INDIO_BUFFER_HARDWARE.
> > > 
> > > So basically INDIO_HW_BUFFER_TRIGGERED is the same as
> > > INDIO_BUFFER_HARDWARE except that it also enables the trigger when the
> > > buffer is enabled.
> > 
> > If the trigger isn't routeable to multiple devices we normally don't
> > make it visible at all.
> > 
> > I'm not yet understanding what a trigger actually means in this case.
> > Why do you need it to be userspace configurable?
> > 
> > J
> > 
> 
> It looks like this question was answered in another thread (we need to
> configure the sampling frequency from userspace). But there you
> mentioned that adding a trigger for that seemed overkill. So you would
> you suggest to add the sampling_frequency sysfs attribute to the
> iio:deviceX instead and just forget about the trigger part? It seems a
> bit odd to me to have an attribute that may or may not be there
> depending other hardware external to the ADC chip. But if that is a
> normal acceptable thing to do, then it does seem like the simpler
> thing to do.

Well, for these converters you usually always need some sort of trigger to tell the
engine to fetch the data. But if not, you could make it optional in the driver (I
guess a trigger will always be a pwm, gpio, clk, etc...) and only expose the
interface if needed. Yes, if we start having tons of devices with optional triggers
(which is not the case so far) I agree we would be duplicating logic all over the
place.

But let's see where all this discussion leads us. AFAIU, having the triggers somehow
directly in the spi framework is also an option. If we can make that generic enough
and with a nice interface I think that would make the most sense as this trigger
affects the offload engine which is a spi controller thing. Let's see where we end up
:)

- Nuno Sá