linux-kernel - Re: [PATCH 6/7] iio: adc: ad485x: add ad485x driver

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: <CAHp75VfChXnRsQVA7nQu0L8evqFZrNoCXMq_KEc6_md4EWPyvA@mail.gmail.com>
Date: Sun, 29 Sep 2024 22:21:52 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: David Lechner <dlechner@...libre.com>, Antoniu Miclaus <antoniu.miclaus@...log.com>, 
	Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Nuno Sa <nuno.sa@...log.com>, Olivier Moysan <olivier.moysan@...s.st.com>, 
	Uwe Kleine-König <ukleinek@...nel.org>, 
	Andy Shevchenko <andy@...nel.org>, Marcelo Schmitt <marcelo.schmitt@...log.com>, 
	João Paulo Gonçalves <joao.goncalves@...adex.com>, 
	Mike Looijmans <mike.looijmans@...ic.nl>, Dumitru Ceclan <mitrutzceclan@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, 
	Alisa-Dariana Roman <alisadariana@...il.com>, Sergiu Cuciurean <sergiu.cuciurean@...log.com>, 
	Dragos Bogdan <dragos.bogdan@...log.com>, linux-iio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-pwm@...r.kernel.org
Subject: Re: [PATCH 6/7] iio: adc: ad485x: add ad485x driver

On Sat, Sep 28, 2024 at 8:30 PM Jonathan Cameron <jic23@...nel.org> wrote:

...

> > We have quite a few parts in the pipline right like this one that have
> > per-sample status bits. In the past, these were generally handled with
> > IIO events, but this doesn't really work for these high-speed backends
> > since the data is being piped directly to DMA and we don't look at
> > each sample in the ADC driver. So it would be worthwhile to try to
> > find some general solution here for handling this sort of thing.
>
> We have previously talked about schemes to describe metadata
> alongside channels. I guess maybe it's time to actually look at how
> that works.  I'm not sure dynamic control of that metadata
> is going to be easy to do though or if we even want to
> (as opposed to always on or off for a particular device).

Time for the kernel to return JSON on a per channel basis?

Just saying :-)

-- 
With Best Regards,
Andy Shevchenko