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]
Date: Mon, 03 Jun 2024 12:25:55 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: Jonathan Cameron <jic23@...nel.org>, David Lechner
 <dlechner@...libre.com>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>, Nuno
 Sá <nuno.sa@...log.com>, Julien Stephan
 <jstephan@...libre.com>, Esteban Blanc <eblanc@...libre.com>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/5] iio: add support for multiple scan types

On Sun, 2024-06-02 at 10:25 +0100, Jonathan Cameron wrote:
> On Thu, 30 May 2024 10:14:07 -0500
> David Lechner <dlechner@...libre.com> wrote:
> 
> > Up to now, the IIO subsystem has only supported a single scan type per
> > channel. This scan type determines the binary format of the data in the
> > buffer when doing buffered reads.
> > 
> > For simple devices, there is only one scan type and all is well. But
> > for more complex devices, there may be multiple scan types. For example,
> > ADCs with a resolution boost feature that adds more bits to the raw
> > sample data. Traditionally, for slow devices, we've just always used the
> > highest resolution mode, but for high performance ADCs, this may not be
> > always practical. Manipulating data after every read can hurt performance
> > and in the case of hardware buffers, it may not be possible to change the
> > format of the data in the buffer at all. There are also ADCs where
> > enabling the higher resolution can only be done if oversampling is also
> > enabled which may not be desireable.
> > 
> > To allow for more flexibility, we would like to add support for multiple
> > scan types per channel.
> > 
> > To avoid having to touch every driver, we implemented this in a way that
> > preserves the existing scan_type field. See the "iio: add support for
> > multiple scan types per channel" the details. The first couple of patches
> > are just preparation for this.
> > 
> > [1]:
> > https://lore.kernel.org/linux-iio/CAMknhBHOXaff__QyU-wFSNNENvs23vDX5n_ddH-Dw3s6-sQ9sg@mail.gmail.com/
> 
> Nice series. Applied to the togreg branch of iio.git and pushed out as
> testing for 0-day to poke at it.
> 
> Obviously this v3 hasn't been on list that long, but there is still time
> as I doubt I'll push out a non rebasing tree for a week or so.
> This week is looking too busy!

If there's still time, feel free to add my tag:

Reviewed-by: Nuno Sa <nuno.sa@...log.com>



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ