kernel/drivers/pci, branch master

Merge tag 'pci-v7.0-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci

2026-03-19T23:13:51Z

Pull pci fixes from Bjorn Helgaas: - Create pwrctrl devices only for DT nodes below a PCI controller that describe PCI devices and are related to a power supply; this prevents waiting indefinitely for pwrctrl drivers that will never probe (Manivannan Sadhasivam) - Restore endpoint BAR mapping on subrange setup failure to make selftest reliable (Koichiro Den) * tag 'pci-v7.0-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails PCI/pwrctrl: Create pwrctrl devices only for PCI device nodes PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement

PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

2026-03-17T15:26:42Z

When the BAR subrange mapping test on DWC-based platforms fails due to insufficient free inbound iATU regions, pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does not restore the original BAR mapping. This causes subsequent test runs to become confusing, since the failure may leave room for the next subrange mapping test to pass. Fix this by restoring the original BAR mapping when preparation of the subrange mapping fails, so that no side effect remains regardless of the test success or failure. Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support") Reported-by: Christian Bruel Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/ Signed-off-by: Koichiro Den Signed-off-by: Bjorn Helgaas Tested-by: Christian Bruel Reviewed-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260316140225.1481658-1-den@valinux.co.jp

PCI/pwrctrl: Create pwrctrl devices only for PCI device nodes

2026-03-16T22:30:43Z

A PCI host bridge node can have non-PCI child nodes (OPP tables, USB hub, etc.) as well as PCI device child nodes. Ensure that pwrctrl devices are only created for PCI device nodes by checking for the 'pci' prefix in the compatible property. Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices") Reported-by: Bjorn Andersson Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260223-pwrctrl-fixes-7-0-v2-2-97566dfb1809@oss.qualcomm.com

PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement

2026-03-16T22:30:39Z

If OF graph is used in the PCI device node, the pwrctrl core creates a pwrctrl device even if the remote endpoint doesn't have power supply requirements. Since the device doesn't have any power supply requirements, there was no pwrctrl driver to probe, leading to PCI controller driver probe deferral as it waits for all pwrctrl drivers to probe before starting bus scan. This issue happens with Qcom ath12k devices with WSI interface attached to the Qcom IPQ platforms. Fix this issue by checking for the existence of at least one power supply property in the remote endpoint parent node. To consolidate all the checks, create a new helper pci_pwrctrl_is_required() and move all the checks there. Fixes: 9db826206f9b ("PCI/pwrctrl: Create pwrctrl device if graph port is found") Reported-by: Raj Kumar Bhagat Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Raj Kumar Bhagat Reviewed-by: Krishna Chaitanya Chundru Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260223-pwrctrl-fixes-7-0-v2-1-97566dfb1809@oss.qualcomm.com

Merge tag 'for-linus-7.0-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2026-03-07T15:44:32Z

Pull xen fixes from Juergen Gross: - a cleanup of arch/x86/kernel/head_64.S removing the pre-built page tables for Xen guests - a small comment update - another cleanup for Xen PVH guests mode - fix an issue with Xen PV-devices backed by driver domains * tag 'for-linus-7.0-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/xenbus: better handle backend crash xenbus: add xenbus_device parameter to xenbus_read_driver_state() x86/PVH: Use boot params to pass RSDP address in start_info page x86/xen: update outdated comment xen/acpi-processor: fix _CST detection using undersized evaluation buffer x86/xen: Build identity mapping page tables dynamically for XENPV

xenbus: add xenbus_device parameter to xenbus_read_driver_state()

2026-03-04T14:31:40Z

In order to prepare checking the xenbus device status in xenbus_read_driver_state(), add the pointer to struct xenbus_device as a parameter. Tested-by: Marek Marczykowski-Górecki Signed-off-by: Juergen Gross Acked-by: "Martin K. Petersen" # SCSI Acked-by: Jakub Kicinski Acked-by: Bjorn Helgaas # drivers/pci/xen-pcifront.c Signed-off-by: Juergen Gross Message-ID: <20260218095205.453657-2-jgross@suse.com>

PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry

2026-02-25T21:44:20Z

Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X interrupt to the host using a writel(), which generates a PCI posted write transaction. There's no completion for posted writes, so the writel() may return before the PCI write completes. dw_pcie_ep_raise_msix_irq() also unmaps the outbound ATU entry used for the PCI write, so the write races with the unmap. If the PCI write loses the race with the ATU unmap, the write may corrupt host memory or cause IOMMU errors, e.g., these when running fio with a larger queue depth against nvmet-pci-epf: arm-smmu-v3 fc900000.iommu: 0x0000010000000010 arm-smmu-v3 fc900000.iommu: 0x0000020000000000 arm-smmu-v3 fc900000.iommu: 0x000000090000f040 arm-smmu-v3 fc900000.iommu: 0x0000000000000000 arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0 arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0 Flush the write by performing a readl() of the same address to ensure that the write has reached the destination before the ATU entry is unmapped. The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but there it was solved by dedicating an outbound iATU only for MSI. We can't do the same for MSI-X because each vector can have a different msg_addr and the msg_addr may be changed while the vector is masked. Fixes: beb4641a787d ("PCI: dwc: Add MSI-X callbacks handler") Signed-off-by: Niklas Cassel [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260211175540.105677-2-cassel@kernel.org

PCI: dwc: ep: Refresh MSI Message Address cache on change

2026-02-25T21:41:43Z

Endpoint drivers use dw_pcie_ep_raise_msi_irq() to raise MSI interrupts to the host. After 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), dw_pcie_ep_raise_msi_irq() caches the Message Address from the MSI Capability in ep->msi_msg_addr. But that Message Address is controlled by the host, and it may change. For example, if: - firmware on the host configures the Message Address and triggers an MSI, - a driver on the Endpoint raises the MSI via dw_pcie_ep_raise_msi_irq(), which caches the Message Address, - a kernel on the host reconfigures the Message Address and the host kernel driver triggers another MSI, dw_pcie_ep_raise_msi_irq() notices that the Message Address no longer matches the cached ep->msi_msg_addr, warns about it, and returns error instead of raising the MSI. The host kernel may hang because it never receives the MSI. This was seen with the nvmet_pci_epf_driver: the host UEFI performs NVMe commands, e.g. Identify Controller to get the name of the controller, nvmet-pci-epf posts the completion queue entry and raises an IRQ using dw_pcie_ep_raise_msi_irq(). When the host boots Linux, we see a WARN_ON_ONCE() from dw_pcie_ep_raise_msi_irq(), and the host kernel hangs because the nvme driver never gets an IRQ. Remove the warning when dw_pcie_ep_raise_msi_irq() notices that Message Address has changed, remap using the new address, and update the ep->msi_msg_addr cache. Fixes: 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping") Signed-off-by: Niklas Cassel [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Tested-by: Shin'ichiro Kawasaki Tested-by: Koichiro Den Acked-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260210181225.3926165-2-cassel@kernel.org

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00Z

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_flex' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds