Hi Shinichiro,
Thank you for your work on this.
On 3/2/24 08:28, Shinichiro Kawasaki wrote:
> On Mar 02, 2024 / 10:28, Shin'ichiro Kawasaki wrote:
>> The commit 5913320eb0b3 ("platform/x86: p2sb: Allow p2sb_bar() calls
>> during PCI device probe") triggered repeated ACPI errors on ASUS
>> VivoBook D540NV-GQ065T [1]. It was confirmed that the P2SB device scan
>> and remove at the fs_initcall stage triggered the errors.
>>
>> To avoid the error, defer the P2SB device scan on the concerned device.
>> The error was observed on the system with Pentium N4200 in Goldmont micro-
>> architecture, and on which P2SB has function 0. Then refer to the P2SB
>> function to decide whether to defer or not.
>>
>> When the device scan is deferred, do the scan later when p2sb_bar() is
>> called for the first time. If this first scan is triggered by sysfs
>> pci bus rescan, deadlock happens. In most cases, the scan happens during
>> system boot process, then there is no chance of deadlock.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218531 [1]
>> Fixes: 5913320eb0b3 ("platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe")
>> Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@xxxxxxx>
>
> Let me drop this patch. danilrybakov found that the ACPI errors are still
> reported even with this patch. Will try another fix approach.
Can we not simply just skip scanning function 0 all together when
on Goldmont? I don't think any drivers actually ask for the bar
of function 0 on Goldmont ?
This is likely also why we never had the issue with the old p2sb_bar()
code, because that never touched function 0.
I think this is actually what you did in one of your first test
patches in the bugzilla, right ?
So maybe audit all the callers of p2sb_bar() and see if any
caller asks for function 0 on goldmont ?
Let me know if you need help with this audit.
Regards,
Hans
