Skip to content

Commit 310b010

Browse files
l1kjfvogel
authored andcommitted
PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable ports
[ Upstream commit 6cff20ce3b92ffbf2fc5eb9e5a030b3672aa414a ] pci_bridge_d3_possible() is called from both pcie_portdrv_probe() and pcie_portdrv_remove() to determine whether runtime power management shall be enabled (on probe) or disabled (on remove) on a PCIe port. The underlying assumption is that pci_bridge_d3_possible() always returns the same value, else a runtime PM reference imbalance would occur. That assumption is not given if the PCIe port is inaccessible on remove due to hot-unplug: pci_bridge_d3_possible() calls pciehp_is_native(), which accesses Config Space to determine whether the port is Hot-Plug Capable. An inaccessible port returns "all ones", which is converted to "all zeroes" by pcie_capability_read_dword(). Hence the port no longer seems Hot-Plug Capable on remove even though it was on probe. The resulting runtime PM ref imbalance causes warning messages such as: pcieport 0000:02:04.0: Runtime PM usage count underflow! Avoid the Config Space access (and thus the runtime PM ref imbalance) by caching the Hot-Plug Capable bit in struct pci_dev. The struct already contains an "is_hotplug_bridge" flag, which however is not only set on Hot-Plug Capable PCIe ports, but also Conventional PCI Hot-Plug bridges and ACPI slots. The flag identifies bridges which are allocated additional MMIO and bus number resources to allow for hierarchy expansion. The kernel is somewhat sloppily using "is_hotplug_bridge" in a number of places to identify Hot-Plug Capable PCIe ports, even though the flag encompasses other devices. Subsequent commits replace these occurrences with the new flag to clearly delineate Hot-Plug Capable PCIe ports from other kinds of hotplug bridges. Document the existing "is_hotplug_bridge" and the new "is_pciehp" flag and document the (non-obvious) requirement that pci_bridge_d3_possible() always returns the same value across the entire lifetime of a bridge, including its hot-removal. Fixes: 5352a44 ("PCI: pciehp: Make pciehp_is_native() stricter") Reported-by: Laurent Bigonville <bigon@bigon.be> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220216 Reported-by: Mario Limonciello <mario.limonciello@amd.com> Closes: https://lore.kernel.org/r/20250609020223.269407-3-superm1@kernel.org/ Link: https://lore.kernel.org/all/20250620025535.3425049-3-superm1@kernel.org/T/#u Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Cc: stable@vger.kernel.org # v4.18+ Link: https://patch.msgid.link/fe5dcc3b2e62ee1df7905d746bde161eb1b3291c.1752390101.git.lukas@wunner.de Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 272d619a5301ddc092ca7facaa9e131ae83f2c76) Conflicts: include/linux/pci.h KABI violation, use FILL_HOLE for is_pciehp Signed-off-by: Jack Vogel <jack.vogel@oracle.com>
1 parent 067d508 commit 310b010

File tree

4 files changed

+13
-5
lines changed

4 files changed

+13
-5
lines changed

drivers/pci/pci-acpi.c

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -816,13 +816,11 @@ int pci_acpi_program_hp_params(struct pci_dev *dev)
816816
bool pciehp_is_native(struct pci_dev *bridge)
817817
{
818818
const struct pci_host_bridge *host;
819-
u32 slot_cap;
820819

821820
if (!IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE))
822821
return false;
823822

824-
pcie_capability_read_dword(bridge, PCI_EXP_SLTCAP, &slot_cap);
825-
if (!(slot_cap & PCI_EXP_SLTCAP_HPC))
823+
if (!bridge->is_pciehp)
826824
return false;
827825

828826
if (pcie_ports_native)

drivers/pci/pci.c

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3023,8 +3023,12 @@ static const struct dmi_system_id bridge_d3_blacklist[] = {
30233023
* pci_bridge_d3_possible - Is it possible to put the bridge into D3
30243024
* @bridge: Bridge to check
30253025
*
3026-
* This function checks if it is possible to move the bridge to D3.
30273026
* Currently we only allow D3 for some PCIe ports and for Thunderbolt.
3027+
*
3028+
* Return: Whether it is possible to move the bridge to D3.
3029+
*
3030+
* The return value is guaranteed to be constant across the entire lifetime
3031+
* of the bridge, including its hot-removal.
30283032
*/
30293033
bool pci_bridge_d3_possible(struct pci_dev *bridge)
30303034
{

drivers/pci/probe.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1627,7 +1627,7 @@ void set_pcie_hotplug_bridge(struct pci_dev *pdev)
16271627

16281628
pcie_capability_read_dword(pdev, PCI_EXP_SLTCAP, &reg32);
16291629
if (reg32 & PCI_EXP_SLTCAP_HPC)
1630-
pdev->is_hotplug_bridge = 1;
1630+
pdev->is_hotplug_bridge = pdev->is_pciehp = 1;
16311631
}
16321632

16331633
static void set_pcie_thunderbolt(struct pci_dev *dev)

include/linux/pci.h

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -327,6 +327,11 @@ struct rcec_ea;
327327
* determined (e.g., for Root Complex Integrated
328328
* Endpoints without the relevant Capability
329329
* Registers).
330+
* @is_hotplug_bridge: Hotplug bridge of any kind (e.g. PCIe Hot-Plug Capable,
331+
* Conventional PCI Hot-Plug, ACPI slot).
332+
* Such bridges are allocated additional MMIO and bus
333+
* number resources to allow for hierarchy expansion.
334+
* @is_pciehp: PCIe Hot-Plug Capable bridge.
330335
*/
331336
struct pci_dev {
332337
struct list_head bus_list; /* Node in per-bus list */
@@ -479,6 +484,7 @@ struct pci_dev {
479484
unsigned int no_command_memory:1; /* No PCI_COMMAND_MEMORY */
480485
unsigned int rom_bar_overlap:1; /* ROM BAR disable broken */
481486
unsigned int rom_attr_enabled:1; /* Display of ROM attribute enabled? */
487+
UEK_KABI_FILL_HOLE(unsigned int is_pciehp:1)
482488
pci_dev_flags_t dev_flags;
483489
atomic_t enable_cnt; /* pci_enable_device has been called */
484490

0 commit comments

Comments
 (0)