linux-kernel - RE: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit ADC-DAC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 Jan 2022 09:38:45 +0000
From:   "Sa, Nuno" <Nuno.Sa@...log.com>
To:     Jonathan Cameron <jic23@...nel.org>,
        "Pop, Cristian" <Cristian.Pop@...log.com>
CC:     "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Subject: RE: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit
 ADC-DAC

Hi Jonathan,

> From: Jonathan Cameron <jic23@...nel.org>
> Sent: Sunday, January 16, 2022 12:52 PM
> To: Pop, Cristian <Cristian.Pop@...log.com>
> Cc: linux-iio@...r.kernel.org; linux-gpio@...r.kernel.org; linux-
> kernel@...r.kernel.org; devicetree@...r.kernel.org;
> robh+dt@...nel.org
> Subject: Re: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one
> bit ADC-DAC
> 
> [External]
> 
> On Tue, 11 Jan 2022 13:59:19 +0200
> Cristian Pop <cristian.pop@...log.com> wrote:
> 
> > This allows remote reading and writing of the GPIOs. This is useful in
> > application that run on another PC, at system level, where multiple
> iio
> > devices and GPIO devices are integrated together.
> Hi Cristian,
> 
> So I fully understand why this can be useful, but it is a software only
> construction so I'm not convinced that it makes sense to necessarily
> configure it via device tree.   A better fit may well be configfs.
> (note I always meant to add configfs controls for iio_hwmon but
> haven't
> found the time to do it yet...)
> 
> As it currently stands, doing only polled / sysfs reads this driver doesn't
> do enough to justify its existence. You could just do all this in
> userspace
> using the existing gpio interfaces.  So to be useful I'd expect it to
> at least do triggered buffer capture.
> 
> When we have talked about handling digital signals int he past we
> discussed
> whether the IIO channel description would also benefit from tighter
> packing
> than the current minimum of a byte per channel.  Perhaps we don't

That reminded me about this series [1] Alex tried to upstream. It's slightly
related and this was all about supporting buffered channels with less than
8 bits (IIRC). I didn't went through the all thread but I remember you had some
"questions" about the whole thing. That series is something that I definitely want
to revive at some point (might be that I just need to change things in ADI kernel)
to stop having these custom patches in our tree.

> technically
> 'need' it here but if we do add it in future it will be hard to retrofit into
> this driver without big userspace ABI changes (i.e. breaking all existing
> users).

I think this is the perfect opportunity to add support for it (either with the series
I mentioned or something else) if we ever really want to have this in IIO. 


[1]: https://lore.kernel.org/linux-iio/20200424051818.6408-1-alexandru.ardelean@analog.com/
- Nuno Sá