Re: [PATCH net-next] i2c: tegra: runtime PM is not IRQ-safe

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Wed, Feb 18, 2026 at 08:30:49AM +0000, Jon Hunter wrote:
> 
> On 18/02/2026 01:35, Mikko Perttunen wrote:
> 
> ...
> 
> > > > > Yes we should always follow that rule. However, in this case, I believe
> > > > > that the build time dependency on the PINCTRL subsystem was only exposed
> > > > > by adding the 'i2c_dev->dev->pins'. Unless I am misunderstanding ...
> > > > 
> > > > Yes, it looks like it.
> > > > 
> > > > However, I wonder why the dependency has to be complicated.
> > > > 
> > > > ARCH_TEGRA in both arm64 and arm selects PINCTRL, so we can assume that
> > > > 
> > > > PINCTRL will be set for ARCH_TEGRA. So:
> > > >    config I2C_TEGRA
> > > >    	tristate "NVIDIA Tegra internal I2C controller"
> > > >    	depends on ARCH_TEGRA || (COMPILE_TEST && (ARC || ARM || ARM64 ||
> > M68K
> > > >    	|| RISCV || SUPERH || SPARC))>
> > > > +	depends on PINCTRL
> > > > 
> > > > is a shorter way of writing this, and it makes sense - pinctrl isn't
> > > > required because we're doing a compile test, it's required because
> > > > the driver itself fundamentally requires it with this change whether
> > > > or not we're doing a compile test.
> > > 
> > > Yes that's true indeed.
> > > 
> > > Mikko, do you want to take care of this?
> > 
> > My thought was it would be better to keep the PINCTRL dependency grouped with
> > COMPILE_TEST. That makes it clear it's only needed because of it -- clearer to
> > the reader that ARCH_TEGRA implies it. Kind of like not checking for NULL
> > pointers in C code when the contract is that the pointer is not NULL.
> 
> Russell's point is that regardless of the compile test, the driver has a
> dependency on pinctrl and so should always be dependent on it. The I2C
> instances for the DPAUX device on certain devices require this and will not
> work without it (before your change was added). I guess I should have added
> this dependency back with commit 718917b9875f ("i2c: tegra: Add pinctrl
> support").
> 
> > I can change it though if you'd like.
> 
> I think we should.
> 
> Thanks!

When is this bug going to be fixed? This is a regression that's
affecting Xavier systems. It's been over a month since I proposed
a patch to fix this:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 59, name: kworker/u24:6

Please see:

https://lore.kernel.org/r/E1vsNBv-00000009nfA-27ZK@rmk-PC.armlinux.org.uk

for my original proposed fix, complete kernel messages and analysis.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!