linux-kernel - Re: [PATCH v3 2/3] iio: adc: Initial support for AD4134

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: <aTBPivrI7iy2cLQ1@smile.fi.intel.com>
Date: Wed, 3 Dec 2025 16:56:10 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Nuno Sá <noname.nuno@...il.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
	Marcelo Schmitt <marcelo.schmitt@...log.com>,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	jic23@...nel.org, nuno.sa@...log.com, dlechner@...libre.com,
	andy@...nel.org, Michael.Hennerich@...log.com, robh@...nel.org,
	krzk+dt@...nel.org, conor+dt@...nel.org, corbet@....net,
	marcelo.schmitt1@...il.com
Subject: Re: [PATCH v3 2/3] iio: adc: Initial support for AD4134

On Wed, Dec 03, 2025 at 02:48:44PM +0000, Nuno Sá wrote:
> On Wed, 2025-12-03 at 14:59 +0200, Andy Shevchenko wrote:
> > On Wed, Dec 03, 2025 at 11:02:45AM +0000, Nuno Sá wrote:
> > > On Tue, 2025-12-02 at 23:26 +0200, Andy Shevchenko wrote:
> > > > On Tue, Dec 2, 2025 at 10:55 PM Marcelo Schmitt
> > > > <marcelo.schmitt@...log.com> wrote:

...

> > Nuno, may you please remove unrelated context when replying?
> 
> It was not that much. That is why I did not bothered :)

2 pages of text on my screen... We definitely have different metrics
for "too much" :-)

...

> > > Hmm, can you share why we should have a reset controller for the above? 
> > 
> > My point here is to have a standard way of handling "reset" pin independently
> > of what's beneath in the HW — GPIO or other means to assert/deassert it.
> 
> That makes sense.
> 
> > > Unless I'm missing something, even with the aux device, you'll need the code to
> > > optionally add it which (I think) will already force you to check the existence for
> > > the pin (which would be a bit odd IMO).
> > 
> > If this is the case, it needs to be fixed, but reset framework provides
> > _optional() API, that's what should be used for the cases where reset is
> > optional. Let reset framework to handle that.
> 
> Ok, I think I was also misunderstanding you. So you mean that instead of doing 
> devm_gpiod_get_optional() we should use one of the devm_reset_control_get_*() calls? 

Yep!

> Ok, I went to check the reset core implementation and with [1] I take back my comment. I can see now
> that the framework will automatically handle creating the auxdevice. So while I still think most of
> the times we'll still see reset-gpios in bindings, it makes sense to have this HW abstraction in the
> code.

...and standardisation.

> One thing to note is that the reset framework always enforces reset-gpios and we do have places
> where reset pins have different ids (just because that's how the datasheet defines them).

This might affect the decision. In any case, please consider using it and we
can see if it makes sense over open-coded approach.

-- 
With Best Regards,
Andy Shevchenko