Hi, On 3/4/24 3:35 PM, Andy Shevchenko wrote: > On Mon, Mar 04, 2024 at 03:24:58PM +0100, Hans de Goede wrote: >> On 3/4/24 3:17 PM, Andy Shevchenko wrote: >>> On Mon, Mar 04, 2024 at 04:09:49PM +0200, Andy Shevchenko wrote: >>>> On Mon, Mar 04, 2024 at 02:59:57PM +0100, Hans de Goede wrote: >>>>> On 3/4/24 1:13 PM, Shinichiro Kawasaki wrote: >>>>>> On Mar 04, 2024 / 12:04, Hans de Goede wrote: > > ... > >>>>>> Thanks for sharing the insights. >>>>> >>>>> Looking closer at the actual unhiding I don't think accessing func 0 >>>>> is the problem. The unhiding is always done on function 0 even when >>>>> retreiving the bar for function 2 (the SPI function). >>>>> >>>>> So taking that into account, as mentioned in the bugzilla, I think >>>>> the problem is probing the other functions (1, 3-7) by calling >>>>> pci_scan_single_device() on them. >>>> >>>> So, why we can't simply call pci_dev_present() on the function in a loop? >>> >>> pci_device_is_present() >> >> That takes a pci_dev as argument which we only have after calling >> pci_scan_single_device() and the calling of pci_scan_single_device() >> on some of the other functions is what is suspected of maybe causing >> the issue. >> >> Also it is likely that if pci_scan_single_device() is actually >> a problem that then what is a problem is running it on an actual >> present device. > > Which is weird. But okay, let's work around first the real issue, then > if I have time I will look into datasheet to see if there is anything > special about P2SB device(s). Note atm pci_scan_single_device() on one of the "other" being the problem is still only a theory! It is also possible that pci_scan_single_device() on the P2SB itself is somehow an issue on this laptop, since on this laptop p2sb_bar() is only called for the SPI controller, so before the caching to avoid the deadlock issue pci_scan_single_device() was not called on the P2SB devfn itself. Regards, Hans
