linux-kernel - Re: [PATCH v2 5/5] regulator: ltm8054: Support output current limit control

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <12768289.O9o76ZdvQC@fw-rgant>
Date: Fri, 24 Oct 2025 09:55:16 +0200
From: Romain Gantois <romain.gantois@...tlin.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: 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>, Jonathan Cameron <jic23@...nel.org>,
 David Lechner <dlechner@...libre.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, Hans de Goede <hansg@...nel.org>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
 linux-iio@...r.kernel.org, Herve Codina <herve.codina@...tlin.com>
Subject:
 Re: [PATCH v2 5/5] regulator: ltm8054: Support output current limit control

On Wednesday, 22 October 2025 18:37:31 CEST Andy Shevchenko wrote:
> On Wed, Oct 22, 2025 at 11:06 AM Romain Gantois
> <romain.gantois@...tlin.com> wrote:
> 
> ...
> > For part 2., I'm having more trouble finding a proper solution. One
> > potential fix would be to put the IIO channel reads/writes in a LTM8054
> > driver work item and have them run without the regulator lock held. This
> > would incidentally also solve part 1., however it would make the current
> > limit operations asynchronous, and it seems like a lot of unnecessary
> > complexity.
> 
> Interesting that locking a single  regulator, there is no context and
> hence the lock class is global. Hence whoever calls a regulator will
> have the same lockdep splat, even when false positive. Basically the
> solution for those cases (and I don't know if yours / this one falls
> into the category) is to enable context for the single regulator
> locking and set up a lockdep class (so the regulator core should call
> lockdep_set_class() at mutex initialisation).

The strange part is that this "global lock" is actually a lockdep-provided
mutex which isn't taken when lockdep is disabled. It seems to be there to
ensure that ww_mutex contexts are not taken recursively, but then again the
IIO driver is calling regulator_lock_*nested*() so it sounds like
recursively taking the ww_mutex context might be expected here...

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)