From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=none Received: from bmailout3.hostsharing.net (bmailout3.hostsharing.net [IPv6:2a01:4f8:150:2161:1:b009:f23e:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE1F42106 for ; Wed, 29 Nov 2023 03:17:46 -0800 (PST) Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id C2324100D9414; Wed, 29 Nov 2023 12:17:39 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 8859AE45B; Wed, 29 Nov 2023 12:17:39 +0100 (CET) Date: Wed, 29 Nov 2023 12:17:39 +0100 From: Lukas Wunner To: Shinichiro Kawasaki Cc: Andy Shevchenko , Heiner Kallweit , Keith Busch , Wolfram Sang , Jean Delvare , "linux-pci@vger.kernel.org" , "linux-i2c@vger.kernel.org" , Bjorn Helgaas Subject: Re: [bug report] lockdep WARN at PCI device rescan Message-ID: <20231129111739.GA14152@wunner.de> References: <6xb24fjmptxxn5js2fjrrddjae6twex5bjaftwqsuawuqqqydx@7cl3uik5ef6j> <20231114155701.GA27547@wunner.de> <2vzf5sj76j3p747dfbhnusu5daxzog25io4s7d5uvzvtghvo24@567tghzifylu> Precedence: bulk X-Mailing-List: linux-i2c@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: <2vzf5sj76j3p747dfbhnusu5daxzog25io4s7d5uvzvtghvo24@567tghzifylu> User-Agent: Mutt/1.10.1 (2018-07-13) On Tue, Nov 28, 2023 at 07:45:06AM +0000, Shinichiro Kawasaki wrote: > On Nov 24, 2023 / 17:22, Andy Shevchenko wrote: > > Another possible solution I was thinking about is to have a local cache, > > so, make p2sb.c to be called just after PCI enumeration at boot time > > to cache the P2SB device's bar, and then cache the bar based on the device > > in question at the first call. Yet it may not remove all theoretical / > > possible scenarios with dead lock (taking into account hotpluggable > > devices), but won't fail the i801 driver in the above use case IIUC. > > Thanks for the idea. I created an experimental patch below (it does not guard > list nor free the list elements, so it is incomplete). I confirmed that this > patch avoids the deadlock. So your idea looks working. I still observe the > deadlock WARN, but it looks better than the hang by the deadlock. Your patch uses a list to store a multitude of struct resource. Is that actually necessary? I thought there can only be a single P2SB device in the system? > Having said that, Heiner says in another mail that "A solution has to support > pci drivers using p2sb_bar() in probe()". This idea does not fulfill it. Hmm. Basically what you need to do is create two initcalls: Add one arch_initcall to unhide the P2SB device. The P2SB subsequently gets enumerated by the PCI core in a subsys_initcall. Then add an fs_initcall which extracts and stashes the struct resource, hides the P2SB device and destroys the corresponding pci_dev. Then you don't need to acquire any locks at runtime, just retrieve the stashed struct resource. This approach will result in the P2SB device briefly being enumerated and a driver could in theory bind to it. Andy, is this a problem? I'm not seeing any drivers in the tree which bind to 8086/c5c5. Thanks, Lukas