From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25345363C60; Wed, 18 Mar 2026 18:17:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773857879; cv=none; b=t39bjDFA2At4ujy/RrcRm35U+6N5wmUUD4JKwZCQvc3VhmmFycDQswk+lKb+eEDqHp+TAR/SeY/7ZywMbB76R+w4kCtmO99vaN14GTrPh+mF+D7rx02xxDzdEO/WeJB8BPmNZ2cH4FPzcTA1DWe0JNDboZ+n3bUQShVZcQCOOKc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773857879; c=relaxed/simple; bh=e4yzMa5HuMJRcUTMrTesXNJjFSWRTNlzN6y/Dr36S/A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o4NSh0AOYviLgFFu/CiMVnAyp2GgcSIDkrZYOTObqVz3WWG6WLnenwQAB8i/b7M252RY/N5YvYgZrwyUpEzKiWf8VDAwKYtbX4UNtmRVdM8P+TP9H25W9a9Sodvsd5ZX0S3nM+MenA5cRmflZSxEAryb6Fl7NXC0WQs15BC7Qwc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=bWaVeHqz; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="bWaVeHqz" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+XHQ0aGtLx1tevhTAjCKKEhJVloZXEKH4qJpmcE8IDo=; b=bWaVeHqz0dK554wfgHG1/zTvhy epaEK6fkX7fKC8DnBvMGQXXo8PSOlBCy1VoqE9cDkiJpHHjpy4EXcfao2+OKn9pt0mJAO5C+KWPbp BkICYE9+Ms/wapBskvoY0wwzFlZqcoXWihPCvNqG2DLw+cv2z9SsdUM/x7cxnYmR+UO9Aqm+8zcAC 48e4sbQXNqCKNGSyMSoHbWXDChxEsvWRlGxuhiMColJw+Sl5G/PQu74wNxTNKwCCV4mKIFna4/8G3 g3q16XH29uJnxfHawgrulhAZp2JRFlNtHgn+wiEnDfiVM5eE2lwgRes3VDygiCOE+um3J2kaoftlS /h5KCb/w==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:58880) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w2vSn-000000003np-1Vie; Wed, 18 Mar 2026 18:17:49 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1w2vSl-000000007II-2zvC; Wed, 18 Mar 2026 18:17:47 +0000 Date: Wed, 18 Mar 2026 18:17:47 +0000 From: "Russell King (Oracle)" To: Jon Hunter , Linus Torvalds Cc: Mikko Perttunen , Laxman Dewangan , Dmitry Osipenko , Andi Shyti , Linus Walleij , linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH net-next] i2c: tegra: runtime PM is not IRQ-safe Message-ID: References: <046c9bca-f6a5-47ce-8147-6e864b364dc3@nvidia.com> <15817166.RDIVbhacDa@senjougahara> Precedence: bulk X-Mailing-List: linux-gpio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) 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!