[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <db1d1256-8911-4db1-98e2-4f5808cbd712@sirena.org.uk>
Date: Thu, 31 Jul 2025 20:50:25 +0100
From: Mark Brown <broonie@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
Chanwoo Choi <cw00.choi@...sung.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org,
linux-rtc@...r.kernel.org, linux-kernel@...r.kernel.org,
Thierry Reding <treding@...dia.com>
Subject: Re: [BUG] 6.16-rc7: lockdep failure with max77620-gpio/max77686-rtc
On Thu, Jul 31, 2025 at 08:20:51PM +0100, Russell King (Oracle) wrote:
> On Thu, Jul 31, 2025 at 06:03:43PM +0100, Mark Brown wrote:
> > I'm pretty sure it's extremely rare, and I'll have to construct a
> > virtual setup to actually test. After poking at it some more I think
> > we're actually going to need an explicit lock_class_key for each
> > regmap-irq rather than relying on the default lockdep one. I'll try to
> I hope we don't have too many regmap-irq's in a system - see the
> section on "Troubleshooting" in the lockdep documentation. There's
> a limit on the numbe of classes over the entire kernel.
Yeah, we shouldn't I'd hope but obviously there could be some use case
I'm not aware of that results in huge numbers in normal operation.
> As I understand from the documentation, lock classes are create-only,
> there's no way of "freeing" them later, so we better not get into a
> situation where the number of classes steadily increase while the
> system is running!
There is a free function, and it does actually seem to do something
useful these days - looking at the code and changelog the documentation
is bitrotted there, dynamic keys were added in 2019.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists