[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aItk4vWPnFk6lYjn@shell.armlinux.org.uk>
Date: Thu, 31 Jul 2025 13:43:14 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Mark Brown <broonie@...nel.org>
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 01:31:32PM +0100, Mark Brown wrote:
> On Thu, Jul 31, 2025 at 01:18:19PM +0100, Russell King (Oracle) wrote:
>
> > I can't see that anything has changed in the code with regards to the
> > locking, so I think this is a bug that's been present ever since these
> > drivers were introduced, and regmap-irq is deficient in that it causes
> > the same lockdep lock class to be taken recursively when the IRQ wake
> > state changes.
>
> > From what I can see, irq wake support for regmap-irq was added in
> > commit a43fd50dc99a5 ("regmap: Implement support for wake IRQs") and
> > this is the only operation that is propagated to the parent
> > interupt(s). Thus, the above splat is unlikely to occur unless one
> > makes use of wake support on a regmap-irq based interrupt whose
> > parent is also regmap-irq based.
>
> Yes, your analysis is right here - it's not come up before because it's
> very rare to chain regmap-irq chips.
Yep, I just changed all the "d" variables in regmap-irq to "ricd"
(first letter of the each word of the struct name), and lockdep
confirms that it's the mutex.
I'm not familiar enough with lockdep to know how to fix this, so what's
the solution here?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists