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: <20220503161446.tl3qoqqnkzq2f3hn@houat>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ