kernel/linux.git/drivers/pci/hotplug, branch master

Merge branch 'pci/reset'

2026-04-13T17:50:05+00:00

- Update slot handling so all ARI functions are treated as being in the same slot. They're all reset by Secondary Bus Reset, but previously drivers of ARI functions that appeared to be on a non-zero device weren't notified and fatal hardware errors could result (Keith Busch) - Make sysfs reset_subordinate hotplug safe to avoid spurious hotplug events (Keith Busch) - Consolidate bus iteration across the _lock(), _unlock(), and _trylock() functions for pci_bus and pci_slot (Ilpo Järvinen) - Hide Secondary Bus Reset ('bus') from sysfs reset_methods if masked by CXL because it has no effect (Vidya Sagar) * pci/reset: PCI/CXL: Hide SBR from reset_methods if masked by CXL PCI: Consolidate pci_bus/slot_lock/unlock/trylock() PCI: Make reset_subordinate hotplug safe PCI: Allow all bus devices to use the same slot PCI: Rename __pci_bus_reset() and __pci_slot_reset()

PCI: rpaphp: Simplify with scoped for each OF child loop

2026-03-17T21:19:21+00:00

Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Bjorn Helgaas Reviewed-by: Jonathan Cameron Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20260317133322.266102-8-krzysztof.kozlowski@oss.qualcomm.com

PCI: pnv_php: Simplify with scoped for each OF child loop

2026-03-17T21:19:03+00:00

PCI: Allow all bus devices to use the same slot

2026-03-09T20:39:07+00:00

A PCIe hotplug slot applies to the entire secondary bus. Thus, pciehp only allocates a single hotplug_slot for the bridge to that bus. The existing PCI slot, though, would only match to functions on device 0, meaning any devices beyond that, e.g., ARI functions, are not matched to any slot even though they share it. A slot reset will break all the missing devices because the handling skips them. For example, ARI devices with more than 8 functions fail because their state is not properly handled, nor is the attached driver notified of the reset. In the best case, the device will appear unresponsive to the driver, resulting in unexpected errors. A worse possibility may panic the kernel if in-flight transactions trigger hardware reported errors like this real observation: vfio-pci 0000:01:00.0: resetting vfio-pci 0000:01:00.0: reset done {1}[Hardware Error]: Error 1, type: fatal {1}[Hardware Error]: section_type: PCIe error {1}[Hardware Error]: port_type: 0, PCIe end point {1}[Hardware Error]: version: 0.2 {1}[Hardware Error]: command: 0x0140, status: 0x0010 {1}[Hardware Error]: device_id: 0000:01:01.0 {1}[Hardware Error]: slot: 0 {1}[Hardware Error]: secondary_bus: 0x00 {1}[Hardware Error]: vendor_id: 0x1d9b, device_id: 0x0207 {1}[Hardware Error]: class_code: 020000 {1}[Hardware Error]: bridge: secondary_status: 0x0000, control: 0x0000 {1}[Hardware Error]: aer_cor_status: 0x00008000, aer_cor_mask: 0x00002000 {1}[Hardware Error]: aer_uncor_status: 0x00010000, aer_uncor_mask: 0x00100000 {1}[Hardware Error]: aer_uncor_severity: 0x006f6030 {1}[Hardware Error]: TLP Header: 0a412800 00192080 60000004 00000004 GHES: Fatal hardware error but panic disabled Kernel panic - not syncing: GHES: Fatal hardware error Allow a slot to be created to claim all devices on a bus, not just a matching device. This is done by introducing a sentinel value, named PCI_SLOT_ALL_DEVICES, which then has the PCI slot match to any device on the bus. This fixes slot resets for pciehp. Since 0xff already has special meaning, the chosen value for this new feature is 0xfe. This will not clash with any actual slot number since they are limited to 5 bits. Signed-off-by: Keith Busch Signed-off-by: Bjorn Helgaas Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260217160836.2709885-3-kbusch@meta.com

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00+00:00

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds

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

Merge branch 'pci/workqueue'

2026-02-06T23:09:32+00:00

- Add WQ_PERCPU to alloc_workqueue() users (Marco Crivellari) - Replace use of system_wq with system_percpu_wq (Marco Crivellari) - Check for failure of alloc_workqueue() to avoid NULL pointer dereferences (Haotian Zhang) * pci/workqueue: PCI: endpoint: Add missing NULL check for alloc_workqueue() PCI: endpoint: Replace use of system_wq with system_percpu_wq PCI: Add WQ_PERCPU to alloc_workqueue() users # Conflicts: # drivers/pci/endpoint/pci-ep-cfs.c

PCI: Add WQ_PERCPU to alloc_workqueue() users

2025-12-29T16:18:02+00:00

Currently work items enqueued by schedule_delayed_work() use "system_wq" (a per-CPU wq), while queue_delayed_work() uses WORK_CPU_UNBOUND (used when a CPU is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they're needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue() flag in: 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Add WQ_PERCPU to explicitly request alloc_workqueue() to be per-CPU when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn't explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari [bhelgaas: squash similar commits] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251107142526.234685-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107142835.237636-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143108.240025-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143335.242342-1-marco.crivellari@suse.com Link: https://patch.msgid.link/20251107143624.244978-1-marco.crivellari@suse.com

PCI: trace: Add RAS tracepoint to monitor link speed changes

2025-12-23T22:06:00+00:00

PCIe link speed degradation directly impacts system performance and often indicates hardware issues such as faulty devices, physical layer problems, or configuration errors. To this end, add a RAS tracepoint to monitor link speed changes, enabling proactive health checks and diagnostic analysis. The following output is generated when a device is hotplugged: $ echo 1 > /sys/kernel/debug/tracing/events/pci/pcie_link_event/enable $ cat /sys/kernel/debug/tracing/trace_pipe irq/51-pciehp-88 [001] ..... 381.545386: pcie_link_event: 0000:00:02.0 type:4, reason:4, cur_bus_speed:20, max_bus_speed:23, width:1, flit_mode:0, status:DLLLA Suggested-by: Ilpo Järvinen Suggested-by: Matthew W Carlis Suggested-by: Lukas Wunner Signed-off-by: Shuai Xue Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20251210132907.58799-3-xueshuai@linux.alibaba.com