Re: [PATCH] PCI: qcom: Advertise hotplug with no command completion support

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 10/16/26 12:24 PM, Neil Armstrong wrote:
> Hi,
> 
> On 3/14/26 02:56, Krishna Chaitanya Chundru wrote:
>> QCOM PCIe controller advertise hotplug capability in hardware but do not
>> support hotplug command completion. As a result, the PCI core registers
>> the pciehp service and issues hotplug commands that never gets completions,
>> leading to repeated timeout warnings and multi-second delays during boot
>> and suspend/resume.
>>
>> Commit a54db86ddc153 ("PCI: qcom: Do not advertise hotplug capability for
>> IPs v2.7.0 and v1.9.0") avoided these timeouts by clearing the Hot-Plug
>> Capability bit entirely, which also disabled all hotplug functionality.
>>
>> Instead of disabling hotplug, mark these controllers as not supporting
>> command completion by setting the No Command Completed Support (NCCS) bit
>> in the Slot Capabilities register. This prevents the PCI hotplug driver
>> from waiting for commands completion while still allowing hotplug-related
>> functionality such as Data Link Layer state change events.
> 
> I'm a little late to the party, but marking the RC as Hotplus means the bridge
> is marked as is_pciehp and pci_bridge_d3_possible() returns false.
> 
> This means this breaks D3Cold support completely since in __pci_host_common_d3cold_possible()
> we now check all PCI devices, including bridges, and the RC is not set in D3Hot anymore.
> 
> The only way to enable D3Cold is to pass pcie_port_pm=force to allow D3 on all
> Hotplug bridges. Which may be wrong on TB bridges.

At a glance, may it be that we should advertise pciehp_is_native=true?
(it's currently only a thing in ACPI world)

Konrad