kernel/linux.git/include/linux/pci-acpi.h, branch v7.1-rc5

ACPI: PCI: PM: Rework root bus notification setup

2025-12-17T12:52:53+00:00

Since pci_acpi_add_bus_pm_notifier() is only suitable for adding ACPI PM notifiers to root buses, rename it to pci_acpi_add_root_pm_notifier() and modify it to take an additional "root" argument, which is then used for passing a PCI root bridge device pointer to acpi_add_pm_notifier(). That function uses it to populate the "dev" field in the context structure attached to the ACPI device object that will receive the ACPI "wake" notifications on behalf of the given PCI root bus. The context structure in question is passed to pci_acpi_wake_bus(), so the latter can be simplified quite a bit now because the target PCI host bridge structure address can be derived from "dev". No intentional functional impact. This change will also facilitate a subsequent update related to the registration of wakeup sources. Signed-off-by: Rafael J. Wysocki Reviewed-by: Armin Wolf [ rjw: Kerneldoc comment fixup ] Link: https://patch.msgid.link/2395263.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki

PCI: ACPI: Drop acpi_pci_bus

2021-09-27T15:00:21+00:00

The acpi_pci_bus structure was used primarily for running acpi_pci_find_companion() during PCI device objects registration, but after commit 375553a93201 ("PCI: Setup ACPI fwnode early and at the same time with OF") that function is called by pci_setup_device() via pci_set_acpi_fwnode(), which happens before calling pci_device_add() on the new PCI device object, so its ACPI companion has been set already when acpi_device_notify() runs and it will never call ->find_companion() from acpi_pci_bus. For this reason, modify acpi_device_notify() and acpi_device_notify_remove() to call pci_acpi_setup() and pci_acpi_cleanup(), respectively, directly on PCI device objects and drop acpi_pci_bus altogether. While at it, notice that pci_acpi_setup() and pci_acpi_cleanup() can obtain the ACPI companion pointer, which is guaranteed to not be NULL, from their callers and modify them to work that way so as to reduce the number of redundant checks somewhat. Signed-off-by: Rafael J. Wysocki Tested-by: Ferry Toth

PCI: VMD: ACPI: Make ACPI companion lookup work for VMD bus

2021-09-02T15:59:58+00:00

On some systems, in order to get to the deepest low-power state of the platform (which may be necessary to save significant enough amounts of energy while suspended to idle. for example), devices on the PCI bus exposed by the VMD driver need to be power-managed via ACPI. However, the layout of the ACPI namespace below the VMD controller device object does not reflect the layout of the PCI bus under the VMD host bridge, so in order to identify the ACPI companion objects for the devices on that bus, it is necessary to use a special _ADR encoding on the ACPI side. In other words, acpi_pci_find_companion() does not work for these devices, so it needs to be amended with a special lookup logic specific to the VMD bus. Address this issue by allowing the VMD driver to temporarily install an ACPI companion lookup hook containing the code matching the devices on the VMD PCI bus with the corresponding objects in the ACPI namespace. Signed-off-by: Rafael J. Wysocki Acked-by: Jon Derrick

Merge branch 'remotes/lorenzo/pci/host-generic'

2020-06-04T17:59:16+00:00

- Constify struct pci_ecam_ops (Rob Herring) - Support building as modules (Rob Herring) - Eliminate wrappers for pci_host_common_probe() by using DT match table data (Rob Herring) * remotes/lorenzo/pci/host-generic: PCI: host-generic: Eliminate pci_host_common_probe wrappers PCI: host-generic: Support building as modules PCI: Constify struct pci_ecam_ops # Conflicts: # drivers/pci/controller/dwc/pcie-hisi.c

Merge branch 'pci/misc'

2020-06-04T17:59:11+00:00

- Clarify that platform_get_irq() should never return 0 (Bjorn Helgaas) - Check for platform_get_irq() failure consistently (Bjorn Helgaas) - Replace zero-length array with flexible-array (Gustavo A. R. Silva) - Unify pcie_find_root_port() and pci_find_pcie_root_port() (Yicong Yang) - Quirk Intel C620 MROMs, which have non-BARs in BAR locations (Xiaochun Lee) - Fix pcie_pme_resume() and pcie_pme_remove() kernel-doc (Jay Fang) - Rename _DSM constants to align with spec (Krzysztof Wilczyński) * pci/misc: PCI: Rename _DSM constants to align with spec PCI/PME: Fix kernel-doc of pcie_pme_resume() and pcie_pme_remove() x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port() PCI: Replace zero-length array with flexible-array PCI: Check for platform_get_irq() failure consistently driver core: platform: Clarify that IRQ 0 is invalid

PCI: Rename _DSM constants to align with spec

2020-05-27T21:48:21+00:00

Rename PCI-related _DSM constants to align them with the PCI Firmware Spec, r3.2, sec 4.6. No functional change intended. Link: https://lore.kernel.org/r/20200526213905.2479381-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas

PCI: Constify struct pci_ecam_ops

2020-05-01T15:28:59+00:00

struct pci_ecam_ops is typically DT match table data which is defined to be const. It's also best practice for ops structs to be const. Ideally, we'd make struct pci_ops const as well, but that becomes pretty invasive, so for now we just cast it where needed. Link: https://lore.kernel.org/r/20200409234923.21598-2-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Lorenzo Pieralisi Acked-by: Bjorn Helgaas Acked-by: Catalin Marinas Cc: Catalin Marinas Cc: Will Deacon Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Jonathan Chocron Cc: Zhou Wang Cc: Robert Richter Cc: Toan Le Cc: Marc Gonzalez Cc: Mans Rullgard Cc: linux-acpi@vger.kernel.org

PCI/AER: Use only _OSC to determine AER ownership

2020-04-30T22:19:12+00:00

Per the PCI Firmware spec, r3.2, sec 4.5.1, the OS can request control of AER via bit 3 of the _OSC Control Field. In the returned value of the Control Field: The firmware sets [bit 3] to 1 to grant control over PCI Express Advanced Error Reporting. ... after control is transferred to the operating system, firmware must not modify the Advanced Error Reporting Capability. If control of this feature was requested and denied or was not requested, firmware returns this bit set to 0. Previously the pci_root driver looked at the HEST FIRMWARE_FIRST bit to determine whether to request ownership of the AER Capability. This was based on ACPI spec v6.3, sec 18.3.2.4, and similar sections, which say things like: Bit [0] - FIRMWARE_FIRST: If set, indicates that system firmware will handle errors from this source first. Bit [1] - GLOBAL: If set, indicates that the settings contained in this structure apply globally to all PCI Express Devices. These ACPI references don't say anything about ownership of the AER Capability. Remove use of the FIRMWARE_FIRST bit and rely only on the _OSC bit to determine whether we have control of the AER Capability. Link: https://lore.kernel.org/r/20181115231605.24352-1-mr.nuke.me@gmail.com/ v1 Link: https://lore.kernel.org/r/20190326172343.28946-1-mr.nuke.me@gmail.com/ v2 Link: https://lore.kernel.org/r/67af2931705bed9a588b5a39d369cb70b9942190.1587925636.git.sathyanarayanan.kuppuswamy@linux.intel.com [bhelgaas: commit log, note: Alex posted this identical patch 18 months ago, and I failed to apply it then, so I made him the author, added links to his postings, and added his Signed-off-by] Signed-off-by: Alexandru Gagniuc Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Bjorn Helgaas Reviewed-by: Jon Derrick

PCI/DPC: Add Error Disconnect Recover (EDR) support

2020-03-28T18:19:04+00:00

Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to notify OSPM that a device has been disconnected due to an error condition (ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler should invalidate software state associated with disconnected devices and may attempt to recover them. OSPM communicates the status of recovery to the firmware via _OST (sec 6.3.5.2). For PCIe, firmware may use Downstream Port Containment (DPC) to support EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control of DPC, OSPM may read/write DPC control and status registers during the EDR notification processing window, i.e., from the time it receives an EDR notification until it clears the DPC Trigger Status. Note that per [1], sec 4.5.1 and 4.5.2.4, 1. If the OS supports EDR, it should advertise that to firmware by setting OSC_PCI_EDR_SUPPORT in _OSC Support. 2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in _OSC Support. Add an EDR notify handler to attempt recovery. [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 [bhelgaas: squash add/enable patches into one] Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Bjorn Helgaas Cc: "Rafael J. Wysocki" Cc: Len Brown

PCI/ACPI: Evaluate PCI Boot Configuration _DSM

2019-06-21T23:11:53+00:00

Evaluate _DSM Function #5, the "PCI Boot Configuration" function. If the result is 0, the OS should preserve any resource assignments made by the firmware. Link: https://lore.kernel.org/r/20190615002359.29577-2-benh@kernel.crashing.org Signed-off-by: Benjamin Herrenschmidt [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas