linux-kernel - Re: [RFC PATCH 0/5] Support ROHM BD79124 ADC/GPO

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: <20250201163051.1d54cdd7@jic23-huawei>
Date: Sat, 1 Feb 2025 16:30:51 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Matti Vaittinen
 <matti.vaittinen@...rohmeurope.com>, Lee Jones <lee@...nel.org>, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>, Linus
 Walleij <linus.walleij@...aro.org>, Nuno Sa <nuno.sa@...log.com>, David
 Lechner <dlechner@...libre.com>, Dumitru Ceclan <mitrutzceclan@...il.com>,
 Trevor Gamblin <tgamblin@...libre.com>, Matteo Martelli
 <matteomartelli3@...il.com>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
 linux-gpio@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] Support ROHM BD79124 ADC/GPO

On Sat, 1 Feb 2025 17:00:51 +0200
Matti Vaittinen <mazziesaccount@...il.com> wrote:

> Hi Jonathan,
> 
> Thanks a ton for the help! :)
> 
> On 31/01/2025 19:08, Jonathan Cameron wrote:
> > On Fri, 31 Jan 2025 15:34:43 +0200
> > Matti Vaittinen <mazziesaccount@...il.com> wrote:
> >   
> >> Support ROHM BD79124 ADC.
> >>
> >> Quite usual stuff. 12-bit, 8-channel ADC with threshold monitoring.
> >>
> >> Except that:
> >>   - each ADC input pin can be configured as a general purpose output.
> >>   - manually starting an ADC conversion and reading the result would
> >>     require the I2C _master_ to do clock stretching(!) for the duration
> >>     of the conversion... Let's just say this is not well supported.
> >>   - IC supports 'autonomous measurement mode' and storing latest results
> >>     to the result registers. This mode is used by the driver due to the
> >>     "peculiar" I2C when doing manual reads.
> >>
> >> I sent this as an RFC because I implemented the pin purposing (GPO/ADC)
> >> using pinmux - which I've never done for upstream stuff before. Hence
> >> it's better to ask if this makes sense, or if there is better way to go.
> >> Anyways, resulted drivers spread to 3 subsystems (MFD, pinctrl and IIO)  
> > In principle nothing against pin mux for this.
> > There are other options though if pin mux ends up being too complex.
> > 
> > - provide ADC channels in the binding channel@x etc.
> > Anything else is freely available as a GPIO.
> > Normal GPIO bindings etc for those.
> > 
> > The channel bit is common on SoC ADC anyway where we don't want to
> > expose channels that aren't wired out.  
> 
> Thanks for the insight on how things are usually done :)
> 
> I think the only reason for having all the channels visible in IIO, 
> could be, if there was a need to provide a runtime configuration.
> 
> > For combined ADC GPIO chips we normally don't bother with an MFD.
> > Just host the gpio driver in the ADC one unless there is a strong
> > reasons someone will put this down for GPIO usage only.  
> 
> I don't really know about that. I don't like arguing, yet I seem to do 
> that all the time XD
> 
> I personally like using MFD and having smaller drivers in relevant 
> subsystems, because it tends to keep the drivers leaner - and allows 
> re-use of drivers when some of the hardware blocks are re-used. In some 
> cases this results (much) cleaner drivers.

I'm fully in agreement with MFD being useful, but for very simple
parts of a device it can be overkill. 
> 
> (Let's assume they did "new" ADC, and just dropped the GPO from it. With 
> the MFD the deal is to add new compatible, and have an MFD cell array 
> without the pinctrl/GPO matching this new device. And lets imagine they 
> later add this ADC to a PMIC. We add yet another MFD cell array for this 
> new device, with a cell for the regulators, power-supply and the ADC... 
> The same platform subdevice can be re-used to drive ADC (well, with 
> added register offsets)).
> 
> Allright. I believe you have more experience on this area than I do, but 
> I definitely think MFD has it's merits also for ADCs - they do tend to 
> put ADCs to all kinds of devices (like in PMICs after all, although 
> maybe not with 8 channels and less often without an accumulator).

It's a trade off.  Sometimes we just have a little code duplication
to the need for a more complex design.

Enjoy the rest of Fosdem

Jonathan