kernel/linux.git/drivers/pci/of.c, branch v7.0.12

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices

2026-01-16T19:23:38+00:00

Previously, the PCI core created pwrctrl devices during pci_scan_device() on its own and then skipped enumeration of those devices, hoping the pwrctrl driver would power them on and trigger a bus rescan. This approach works for endpoint devices directly connected to Root Ports, but it fails for PCIe switches acting as bus extenders. When the switch requires pwrctrl support and the pwrctrl driver is not available during the pwrctrl device creation, its enumeration will be skipped during the initial PCI bus scan. This premature scan leads the PCI core to allocate resources (bridge windows, bus numbers) for the upstream bridge based on available downstream buses at scan time. For non-hotplug capable bridges, PCI core typically allocates resources based on the number of buses available during the initial bus scan, which happens to be just one if the switch is not powered on and enumerated at that time. When the switch gets enumerated later on, it will fail due to the lack of upstream resources. As a result, a PCIe switch powered on by the pwrctrl driver cannot be reliably enumerated currently. Either the switch has to be enabled in the bootloader or the switch pwrctrl driver has to be loaded during the pwrctrl device creation time to work around these issues. Introduce new APIs to explicitly create and destroy pwrctrl devices from controller drivers by recursively scanning the PCI child nodes of the controller. These APIs allow creating pwrctrl devices based on the original criteria and are intended to be called during controller probe and removal. These APIs, together with the upcoming APIs for power on/off will allow the controller drivers to power on all the devices before starting the initial bus scan, thereby solving the resource allocation issue. Signed-off-by: Krishna Chaitanya Chundru [mani: splitted the patch, cleaned up the code, and rewrote description] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Chen-Yu Tsai Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260115-pci-pwrctrl-rework-v5-10-9d26da3ce903@oss.qualcomm.com

PCI: of: Add of_pci_get_equalization_presets() API

2025-04-19T14:12:33+00:00

PCIe equalization presets are predefined settings used to optimize signal integrity by compensating for signal loss and distortion in high-speed data transmission. As per PCIe spec 6.0.1 revision section 8.3.3.3 & 4.2.4 for data rates of 8.0 GT/s, 16.0 GT/s, 32.0 GT/s, and 64.0 GT/s, there is a way to configure lane equalization presets for each lane to enhance the PCIe link reliability. Each preset value represents a different combination of pre-shoot and de-emphasis values. For each data rate, different registers are defined: for 8.0 GT/s, registers are defined in section 7.7.3.4; for 16.0 GT/s, in section 7.7.5.9, etc. The 8.0 GT/s rate has an extra receiver preset hint, requiring 16 bits per lane, while the remaining data rates use 8 bits per lane. Based on the number of lanes and the supported data rate, of_pci_get_equalization_presets() reads the device tree property and stores in the presets structure. Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Manivannan Sadhasivam Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250328-preset_v6-v9-2-22cfa0490518@oss.qualcomm.com

Merge branch 'pci/misc'

2025-03-27T18:15:05+00:00

- Remove unused tools 'pci' build target left over after moving tests to tools/testing/selftests/pci_endpoint (Jianfeng Liu) - Fix typos and whitespace errors (Bjorn Helgaas) * pci/misc: PCI: Fix typos tools/Makefile: Remove pci target # Conflicts: # drivers/pci/endpoint/functions/pci-epf-test.c

PCI: Fix typos

2025-03-08T21:08:45+00:00

Fix typos and whitespace errors. Link: https://lore.kernel.org/r/20250307231715.438518-1-helgaas@kernel.org Signed-off-by: Bjorn Helgaas

PCI: of: Create device tree PCI host bridge node

2025-02-28T21:13:51+00:00

PCI devices device tree nodes can be already created. This was introduced by commit 407d1a51921e ("PCI: Create device tree node for bridge"). In order to have device tree nodes related to PCI devices attached on their PCI root bus (the PCI bus handled by the PCI host bridge), a PCI root bus device tree node is needed. This root bus node will be used as the parent node of the first level devices scanned on the bus. On device tree based systems, this PCI root bus device tree node is set to the node of the related PCI host bridge. The PCI host bridge node is available in the device tree used to describe the hardware passed at boot. On non device tree based system (such as ACPI), a device tree node for the PCI host bridge or for the root bus does not exist. Indeed, the PCI host bridge is not described in a device tree used at boot simply because no device tree is passed at boot. The device tree PCI host bridge node creation needs to be done at runtime. This is done in the same way as for the creation of the PCI device nodes. I.e. node and properties are created based on computed information done by the PCI core. Also, as is done on device tree based systems, this PCI host bridge node is used for the PCI root bus. With this done, hardware available in a PCI device that doesn't follow the PCI model consisting in one PCI function handled by one driver can be described by a device tree overlay loaded by the PCI device driver on non device tree based systems. Those PCI devices provide a single PCI function that includes several functionalities that require different drivers. The device tree overlay describes the internal devices and their relationships. It allows to load drivers needed by those different devices in order to have functionalities handled. Link: https://lore.kernel.org/r/20250224141356.36325-6-herve.codina@bootlin.com Signed-off-by: Herve Codina Signed-off-by: Bjorn Helgaas Reviewed-by: Rob Herring (Arm)

PCI: of: Use device_{add,remove}_of_node() to attach of_node to existing device

2025-02-28T21:13:07+00:00

The commit 407d1a51921e ("PCI: Create device tree node for bridge") creates of_node for PCI devices. The newly created of_node is attached to an existing device. This is done setting directly pdev->dev.of_node in the code. Even if pdev->dev.of_node cannot be previously set, this doesn't handle the fwnode field of the struct device. Indeed, this field needs to be set if it hasn't already been set. device_{add,remove}_of_node() have been introduced to handle this case. Use them instead of the direct setting. Link: https://lore.kernel.org/r/20250224141356.36325-3-herve.codina@bootlin.com Signed-off-by: Herve Codina Signed-off-by: Bjorn Helgaas Reviewed-by: Rob Herring (Arm)

PCI: of: Simplify devm_of_pci_get_host_bridge_resources() interface

2025-01-15T21:26:51+00:00

Previously pci_parse_request_of_pci_ranges() supplied the default bus range to devm_of_pci_get_host_bridge_resources(), but that function is static and has no other callers, so there's no reason to complicate its interface by passing the default bus range. Drop the busno and bus_max parameters and use 0x0 and 0xff directly in devm_of_pci_get_host_bridge_resources(). Link: https://lore.kernel.org/r/20250113231557.441289-4-helgaas@kernel.org [bhelgaas: dev_warn() for invalid end of bus-range] Signed-off-by: Bjorn Helgaas

PCI: of: Drop 'No bus range found' message

2025-01-15T21:24:44+00:00

The typical bus range for a host bridge is [bus 00-ff], and devm_of_pci_get_host_bridge_resources() defaults to that unless DT contains a "bus-range" property. devm_of_pci_get_host_bridge_resources() previously emitted a message when there was no "bus-range" property, but that seems unnecessary for this common situation. Remove the message. Link: https://lore.kernel.org/r/20250113231557.441289-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan