Re: [bug report] lockdep WARN at PCI device rescan

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, Nov 29, 2023 at 03:50:21PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 29, 2023 at 12:17:39PM +0100, Lukas Wunner wrote:
> > 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.
> 
> At least one problem just out of my head. The P2SB on many system is PCI
> function 0. Unhiding the P2SB unhides all functions on that device, and
> we have use cases for those (that's why we have two first parameters to
> p2sb_bar() in case we want non-default device to be looked at).

For the clarity this is true for ATOM_GOLDMONT (see p2sb_cpu_ids array).

-- 
With Best Regards,
Andy Shevchenko