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: <20251207184818.2ad7cef7@jic23-huawei>
Date: Sun, 7 Dec 2025 18:48:18 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: "H. Nikolaus Schaller" <hns@...delico.com>, Romain Gantois
 <romain.gantois@...tlin.com>, Liam Girdwood <lgirdwood@...il.com>, Mark
 Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, David
 Lechner <dlechner@...libre.com>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-iio@...r.kernel.org, Conor Dooley
 <conor.dooley@...rochip.com>, MyungJoo Ham <myungjoo.ham@...sung.com>,
 Chanwoo Choi <cw00.choi@...sung.com>, Peter Rosin <peda@...ntia.se>, Mariel
 Tinaco <Mariel.Tinaco@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>, Kevin Tsai
 <ktsai@...ellamicro.com>, Linus Walleij <linus.walleij@...aro.org>, Dmitry
 Torokhov <dmitry.torokhov@...il.com>, Eugen Hristev
 <eugen.hristev@...aro.org>, Vinod Koul <vkoul@...nel.org>, Kishon Vijay
 Abraham I <kishon@...nel.org>, Sebastian Reichel <sre@...nel.org>, Chen-Yu
 Tsai <wens@...e.org>, Support Opensource <support.opensource@...semi.com>,
 Paul Cercueil <paul@...pouillou.net>, Iskren Chernev <me@...ren.info>,
 Marek Szyprowski <m.szyprowski@...sung.com>, Matheus Castello
 <matheus@...tello.eng.br>, Saravanan Sekar <sravanhome@...il.com>, Matthias
 Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, Casey Connolly
 <casey.connolly@...aro.org>, Pali Rohár <pali@...nel.org>,
 Orson Zhai <orsonzhai@...il.com>, Baolin Wang
 <baolin.wang@...ux.alibaba.com>, Chunyan Zhang <zhang.lyra@...il.com>, Amit
 Kucheria <amitk@...nel.org>, Thara Gopinath <thara.gopinath@...il.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Daniel Lezcano
 <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>, Lukasz Luba
 <lukasz.luba@....com>, Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Sylwester
 Nawrocki <s.nawrocki@...sung.com>, Olivier Moysan
 <olivier.moysan@...s.st.com>, Arnaud Pouliquen
 <arnaud.pouliquen@...s.st.com>, Maxime Coquelin
 <mcoquelin.stm32@...il.com>, Alexandre Torgue
 <alexandre.torgue@...s.st.com>, Dixit Parmar <dixitparmar19@...il.com>,
 linux-hwmon@...r.kernel.org, linux-input@...r.kernel.org,
 linux-phy@...ts.infradead.org, linux-pm@...r.kernel.org,
 linux-mips@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
 linux-sound@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, Andy
 Shevchenko <andriy.shevchenko@...el.com>
Subject: Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator

On Tue, 25 Nov 2025 08:37:20 -0800
Guenter Roeck <linux@...ck-us.net> wrote:

> On 11/25/25 02:25, H. Nikolaus Schaller wrote:
> ...
> > Another suggestion: what extending the "regulator-fixed", "regulator-gpio",
> > "regulator-fixed-clock" pattern by some "regulator-gpio-iio-dac-current-limiter"
> > driver to make it independent of your specific chip?
> >   
> The name is terrible ;-), but that is what I would have suggested as well.
> I don't see anything chip specific in this code. If there is a need for
> a regulator driver which uses gpio to enable it and a DAC for current limiting,
> it should be made generic.

Agreed - something generic is the ideal way to go.

However, before going too far it is worth exploring what are common circuits with
these things to identify what parameters we need to describe how the DAC channel
is used - e.g is linear scaling enough?  You'll need to that to define a DT
binding. If it turns out to be too complex, then fallback to specific
compatibles in a generic driver to cover the ones that don't fit with a common
scheme.  A similar case we already have is discrete components as analog front
ends for ADCs - mostly they fall into a few categories and we have drivers
covering those, but some are very odd indeed and for those ones we do have a
driver even though they don't have anything to control as such - most extreme
case being when it's a non linear analog sensor. 

The mention of a DAC as part of the analog feedback circuit sounds harder
too generalise but that's specific to this particular buck-boost device,
it's board specific so probably doesn't change the above.

> 
> > By the way, are you aware of this feature of the regulator-gpio driver?
> > 
> > https://elixir.bootlin.com/linux/v6.18-rc7/source/drivers/regulator/gpio-regulator.c#L97
> > 
> > Just to note: I am neither maintainer nor doing any decisions on this, just asking
> > questions for curiosity and from experience and giving hints for alternative approaches,
> > where I hope they help to find the really best solution.
> >   
> Same here.

Only covering the thing you are consuming so not my problem to maintain either ;)

Jonathan

> 
> Thanks,
> Guenter
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ