On Thu, Jan 13, 2022 at 03:34:41PM +0800, Yao Hongbo wrote: > 在 2022/1/13 上午2:01, Bjorn Helgaas 写道: > > On Wed, Jan 12, 2022 at 03:33:25PM +0800, Yao Hongbo wrote: > >> 在 2022/1/12 上午2:55, Bjorn Helgaas 写道: > >>> What kind of system are you seeing the problem on? It seems like it > >>> should be safe to drop the HPIE and CCIE disable here for ACPI > >>> systems. And *likely* we could do the same for non-ACPI systems, > >>> though I have no experience there. > >> > >> Hi, Bjorn > >> Thanks for your comments. > >> > >> The problem occurs on ACPI systems. > >> > >> acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] > >> acpi PNP0A08:00: _OSC: platform does not support [SHPCHotplug AER LTR DPC] > >> acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability] > >> > >> We clear HPIE and CCIE here because the firmware doesn't control > >> Hotplug via __OSC. > >> > >> And on ACPI systems, we can also set pcie_ports=native, which will > >> also encounter such problems. > > > > What happens if you just drop that call like the patch below? > > > > If that avoids the problem, then we can talk about whether we need to > > worry about broken firmware in the non-ACPI or "pcie_ports=native" > > cases. > > Hi, Bjorn. > This can avoid the problem currently. Thanks for collecting that data! > But i'm not sure if removing this code will introduce other problems, > such as suprious hotplug before probing hotplug service. I don't think spurious hotplug before probing the hotplug service is an issue because there is always a window like this. It's either between: A: Handoff from firmware to OS B: get_port_device_capability() or between: A: Handoff from firmware to OS C: pciehp initialization Either way there is *some* window, and we have to decide how to deal with it. The exact duration is not very important. Bjorn
