linux-kernel - Re: [PATCH v1 2/2] iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms

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: <23b80d52-6149-483b-a159-276dd00d12cd@linaro.org>
Date: Fri, 5 Sep 2025 22:58:41 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: David Lechner <dlechner@...libre.com>, Nuno Sá
 <noname.nuno@...il.com>, jic23@...nel.org, nuno.sa@...log.com,
 andy@...nel.org, robh@...nel.org, conor+dt@...nel.org, krzk+dt@...nel.org
Cc: linux-iio@...r.kernel.org, s32@....com, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, chester62515@...il.com, mbrugger@...e.com,
 ghennadi.procopciuc@....nxp.com
Subject: Re: [PATCH v1 2/2] iio: adc: Add the NXP SAR ADC support for the
 s32g2/3 platforms

On 05/09/2025 17:25, David Lechner wrote:
> On 9/5/25 4:44 AM, Daniel Lezcano wrote:
>> On 04/09/2025 19:49, David Lechner wrote:
>>> On 9/4/25 12:40 PM, Daniel Lezcano wrote:

[ ... ]

> Taking a step back, what sort of real-world uses cases do you need to support?
> Or are you just trying to implement everything that the ADC can do? The latter
> can be a bit risky because you might end making something where you can't do
> a buffered read and a single channel read at the same time, but later find out
> you have a real-world application that needs to do this.
> 
> It looks like it would be possible to implement buffered reads in lots of ways.
> IIO devices can have more than one buffer per device so we can add more in the
> future if we need to. So I would just drop the DMA part of the implementation
> for now and implement the basic triggered buffer using MCR[NSTART] and ECH
> (End of Chain) interrupt request and just reading data from the ICDR registers.
> 
> I would wait to have a real-world application that requires DMA to decide the
> best way to implement that. There are lots of possibilities, like does it need
> an external trigger or is continuous mode good enough? Does it need to be cyclic
> (something the IIO subsystem doesn't really support yet) or not. Is exact sample
> timing important or do we just need a big buffer? These questions we can't
> really answer without a specific application to use it.

In the case of this IP, the use cases are in the automotive context. The 
system running on the APU is supposed to monitor at high rate (or not) 
the different channels which can be connected to any device the 
integrator choose to use.

For this reason, the driver should be able to support the different 
modes because the integrator of the car computer can decide to monitor 
the devices connected to the different channels differently.

Said differently, we need these modes because the capture depends on 
what the integrator decide to connect to the different channels. That 
could be a real high rate sampling, or triggered with a dedicated global 
timer on the system or just read the value at a low rate. We just know 
all these use cases exist.


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog