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] [day] [month] [year] [list]
Message-ID: <20251027140423.61d96e88@jic23-huawei>
Date: Mon, 27 Oct 2025 14:04:23 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Marcelo Schmitt <marcelo.schmitt@...log.com>
Cc: <linux-iio@...r.kernel.org>, <devicetree@...r.kernel.org>,
 <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <michael.hennerich@...log.com>, <nuno.sa@...log.com>,
 <eblanc@...libre.com>, <dlechner@...libre.com>, <andy@...nel.org>,
 <robh@...nel.org>, <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
 <corbet@....net>, <marcelo.schmitt1@...il.com>
Subject: Re: [PATCH v6 8/8] iio: adc: ad4030: Support common-mode channels
 with SPI offloading

On Mon, 20 Oct 2025 16:15:39 -0300
Marcelo Schmitt <marcelo.schmitt@...log.com> wrote:

> AD4030 and similar devices can read common-mode voltage together with
> ADC sample data. When enabled, common-mode voltage data is provided in a
> separate IIO channel since it measures something other than the primary
> ADC input signal and requires separate scaling to convert to voltage
> units. The initial SPI offload support patch for AD4030 only provided
> differential channels. Now, extend the AD4030 driver to also provide
> common-mode IIO channels when setup with SPI offloading capability.
> 
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@...log.com>
> ---
> New patch.
> I hope this works for ADCs with two channels. It's not clear if works as
> expected with current HDL and single-channel ADCs (like ADAQ4216).
> 
> The ad4630_fmc HDL project was designed for ADCs with two channels and
> always streams two data channels to DMA (even when the ADC has only one
> physical channel). Though, if the ADC has only one physical channel, the
> data that would come from the second ADC channel comes in as noise and
> would have to be discarded. Because of that, when using single-channel
> ADCs, the ADC driver would need to use a special DMA buffer to filter out
> half of the data that reaches DMA memory. With that, the ADC sample data
> could be delivered to user space without any noise being added to the IIO
> buffer. I have implemented a prototype of such specialized buffer
> (industrialio-buffer-dmaengine-filtered), but it is awful and only worked
> with CONFIG_IIO_DMA_BUF_MMAP_LEGACY (only present in ADI Linux tree). Usual
> differential channel data is also affected by the extra 0xFFFFFFFF data
> pushed to DMA. Though, for the differential channel, it's easier to see it
> shall work for two-channel ADCs (the sine wave appears "filled" in
> iio-oscilloscope).
> 
> So, I sign this, but don't guarantee it to work.

So what's the path to resolve this?  Waiting on HDL changes or not support
those devices until we have a clean solution?

Also, just to check, is this only an issue with the additional stuff this
patch adds or do we have a problem with SPI offload in general (+ this
IP) and those single channel devices?

Jonathan




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ