linux-kernel - Re: [RFC PATCH 0/2] iio: adc: ad7476: Simplifications

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] [day] [month] [year] [list]

Message-ID: <20250802115923.4521fa9d@jic23-huawei>
Date: Sat, 2 Aug 2025 11:59:23 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>, Lars-Peter Clausen
 <lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>, David
 Lechner <dlechner@...libre.com>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Liam Girdwood
 <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] iio: adc: ad7476: Simplifications

On Fri, 1 Aug 2025 13:06:46 +0300
Matti Vaittinen <mazziesaccount@...il.com> wrote:

> This series suggests some simplifications to the ad7476 ADC. It is
> currently 100% untested, and shouldn't be merged as is. I'd like to hear
> opinions on these changes before adding support to the ROHM BD79105 ADC.
> 
> Intention of the patch 1 is pretty trivial. I'd just like to hear if
> people think the enum + ID table approach is preferred over direct
> pointers to IC specific structs in SPI device's driver_data.

Definitely prefer direct pointers as you have here.

> 
> Real reason for the RFC version is the patch 2. It aims to clear the
> supply handling logic. I did also an alternate version which requires
> the names of the regulators to be provided in the chip_data:
> https://github.com/M-Vaittinen/linux/commit/cf5b3078
> 
> I believe the version in the link --^
> is clearer, but it can potentially help people to add issues with supply
> enable ordering.
> 
> I can't still say if the patch 2 contained in this series is better, or
> if the one behind the link is better way to go. So, RFC it is :)

I missed this (who reads cover letters?) in first look.  Anyhow, having
taken a quick look at that alternative I slightly prefer the one you have here.

Even if we have supply ordering issues, it seems like they are unlikely to
vary randomly across supported parts so should be easy to incorporate those
rules with the approach here if needed.

Jonathan


> 
> Matti Vaittinen (2):
>   iio: adc: ad7476: Simplify chip type detection
>   iio: adc: ad7476: Simplify scale handling
> 
>  drivers/iio/adc/ad7476.c | 376 +++++++++++++++++----------------------
>  1 file changed, 164 insertions(+), 212 deletions(-)
>