linux-kernel - Re: [PATCH v2] hwmon: (sun4i-lradc) Add driver for LRADC found on Allwinner A13/A20 SoC

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:   Tue, 3 May 2022 18:14:46 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Ruslan Zalata <rz@...micro.ru>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Icenowy Zheng <icenowy@...c.io>,
        Jean Delvare <jdelvare@...e.com>, Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH v2] hwmon: (sun4i-lradc) Add driver for LRADC found on
 Allwinner A13/A20 SoC

On Tue, May 03, 2022 at 08:26:18PM +0500, Ruslan Zalata wrote:
> LRADC does generate continuous interrupts as long as input voltage is below
> LevelB threshold. The max possible LevelB is 0x3C which in case of A20 SoC
> is close to 1.90V and that's what my driver sets LevelB to. Perhaps this
> needs to be documented more thoroughly.
> 
> It is possible to implement this same driver for IIO subsystem, but I would
> prefer to keep it in hwmon along with many other simple ADC drivers used for
> temp and battery status monitoring.

If you can get it work reliably enough, I think IIO+iio-hwmon is still
the way to go

The main issue here is that drivers that are decided at compile time are
kind of a pain as soon as you try to install a generic distro.

At the hardware level, I'd assume you would either use the LRADC as an
actual ADC, or use it to drive buttons, right?

So, you would have to change the device tree accordingly anyway, to
either list buttons and their associated voltages or use it to probe
whatever signal to have there.

So I don't think a new device tree binding is such a deal breaker since
you have to describe it differently anyway.

Since that would be a completely different use-case, the IIO driver
doesn't have to support input right away, it can be done later if
needed.

And you could have the two drivers compiled at the same time.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)