summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2025-07-14PCI/IOV: Check that VF BAR fits within the reservationMichał Winiarski
When the resource representing a VF MMIO BAR reservation is created, its size is always large enough to accommodate the BAR of all SR-IOV Virtual Functions that can potentially be created (total VFs). If for whatever reason it's not possible to accommodate all VFs, the resource is not assigned and no VFs can be created. An upcoming change will allow VF BAR size to be modified by drivers at a later point in time, which means that the check for resource assignment is no longer sufficient. Add an additional check that verifies that the VF BAR for all enabled VFs fits within the underlying reservation resource. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20250702093522.518099-5-michal.winiarski@intel.com
2025-07-14PCI/IOV: Allow IOV resources to be resized in pci_resize_resource()Michał Winiarski
Similar to regular resizable BARs, VF BARs can also be resized. The capability layout is the same as PCI_EXT_CAP_ID_REBAR, which means we can reuse most of the implementation, the only difference being resource size calculation (which is multiplied by total VFs) and memory decoding (which is controlled by a separate VF MSE field in SR-IOV cap). Extend the pci_resize_resource() function to accept IOV resources. See PCIe r6.2, sec 7.8.7. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20250702093522.518099-4-michal.winiarski@intel.com
2025-07-14PCI/IOV: Add pci_resource_num_to_vf_bar() to convert VF BAR number to/from ↵Michał Winiarski
IOV resource There are multiple places where conversions between IOV resources and corresponding VF BAR numbers are done. Extract the logic to pci_resource_num_from_vf_bar() and pci_resource_num_to_vf_bar() helpers. Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20250702093522.518099-3-michal.winiarski@intel.com
2025-07-14PCI/IOV: Restore VF resizable BAR state after resetMichał Winiarski
Similar to regular resizable BARs, VF BARs can also be resized, e.g. by the system firmware or the PCI subsystem itself. The capability layout is the same as PCI_EXT_CAP_ID_REBAR. Add the capability ID and restore it as a part of IOV state. See PCIe r6.2, sec 7.8.7. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20250702093522.518099-2-michal.winiarski@intel.com
2025-07-13Merge tag 'irq_urgent_for_v6.16_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Borislav Petkov: - Fix a case of recursive locking in the MSI code - Fix a randconfig build failure in armada-370-xp irqchip * tag 'irq_urgent_for_v6.16_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/irq-msi-lib: Fix build with PCI disabled PCI/MSI: Prevent recursive locking in pci_msix_write_tph_tag()
2025-07-11Merge tag 'pci-v6.16-fixes-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Track apple Root Ports explicitly and look up the driver data from the struct device instead of using dev->driver_data, which is used by pci_host_common_init() for the generic host bridge pointer (Marc Zyngier) - Set dev->driver_data before pci_host_common_init() calls gen_pci_init() because some drivers need it to set up ECAM mappings; this fixes a regression on MicroChip MPFS Icicle (Geert Uytterhoeven) - Revert the now-unnecessary use of ECAM pci_config_window.priv to store a copy of dev->driver_data (Marc Zyngier) * tag 'pci-v6.16-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: Revert "PCI: ecam: Allow cfg->priv to be pre-populated from the root port device" PCI: host-generic: Set driver_data before calling gen_pci_init() PCI: apple: Add tracking of probed root ports
2025-07-11PCI: hv: Switch to msi_create_parent_irq_domain()Nam Cao
Move away from the legacy MSI domain setup, switch to use msi_create_parent_irq_domain(). While doing the conversion, I noticed that hv_compose_msi_msg() is doing more than it is supposed to (composing message). This function also allocates and populates struct tran_int_desc, which should be done in hv_pcie_domain_alloc() instead. It works, but it is not the correct design. However, I have no hardware to test such change, therefore I leave a TODO note. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-07-11Merge back earlier changes related to system suspend and hibernationRafael J. Wysocki
2025-07-10PCI/MSI: Prevent recursive locking in pci_msix_write_tph_tag()Himanshu Madhani
pci_msix_write_tph_tag() takes the per device MSI descriptor mutex and then invokes msi_domain_get_virq(), which takes the same mutex again. That obviously results in a system hang which is exposed by a softlockup or lockdep warning. Move the lock guard after the invocation of msi_domain_get_virq() to fix this. [ tglx: Massage changelog by adding a proper explanation and removing the not really useful stacktrace ] Fixes: d5124a9957b2 ("PCI/MSI: Provide a sane mechanism for TPH") Reported-by: Jorge Lopez <jorge.jo.lopez@oracle.com> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Jorge Lopez <jorge.jo.lopez@oracle.com> Link: https://lore.kernel.org/all/20250708222530.1041477-1-himanshu.madhani@oracle.com
2025-07-09PCI: hv: Don't load the driver for baremetal root partitionMukesh Rathor
The root partition only uses VMBus when running nested. When running on baremetal the Hyper-V PCI driver is not needed, so do not initialize it. Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/1751582677-30930-2-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1751582677-30930-2-git-send-email-nunodasneves@linux.microsoft.com>
2025-07-09PCI: hv: Fix warnings for missing export.h header inclusionNaman Jain
Fix below warning in Hyper-V PCI driver that comes when kernel is compiled with W=1 option. Include export.h in driver files to fix it. * warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250611100459.92900-6-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250611100459.92900-6-namjain@linux.microsoft.com>
2025-07-09PCI: endpoint: pci-epf-vntb: Allow BAR assignment via configfsJerome Brunet
The current BAR configuration for the PCI vNTB endpoint function allocates BARs in order, which lacks flexibility and does not account for platform-specific quirks. This is problematic on Renesas platforms, where BAR_4 is a fixed 256B region that ends up being used for MW1, despite being better suited for doorbells. Add new configfs attributes to allow users to specify arbitrary BAR assignments. If no configuration is provided, the driver retains its original behavior of sequential BAR allocation, preserving compatibility with existing userspace setups. This enables use cases such as assigning BAR_2 for MW1 and using the limited BAR_4 for doorbells on Renesas platforms. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> [mani: adjusted the indent of EPF_NTB_BAR_W, fixed kdoc & squashed bar fix] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-3-fc685a22ad28@baylibre.com
2025-07-08PCI/MSI: Add pci_msi_map_rid_ctlr_node() helper functionLorenzo Pieralisi
IRQchip drivers need a PCI/MSI function to map a RID to a MSI controller deviceID namespace and at the same time retrieve the struct device_node pointer of the MSI controller the RID is mapped to. Add pci_msi_map_rid_ctlr_node() to achieve this purpose. Cc Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250703-gicv5-host-v7-25-12e71f1b3528@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-07-07PCI: rockchip: Set Target Link Speed to 5.0 GT/s before retrainingGeraldo Nascimento
Rockchip controllers can support up to 5.0 GT/s link speed. But the driver doesn't set the Target Link Speed currently. This may cause failure in retraining the link to 5.0 GT/s if supported by the endpoint. So set the Target Link Speed to 5.0 GT/s in the Link Control and Status Register 2. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com> [mani: fixed whitespace warning, commit message rewording, added fixes tag] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Robin Murphy <robin.murphy@arm.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/0afa6bc47b7f50e2e81b0b47d51c66feb0fb565f.1751322015.git.geraldogabriel@gmail.com
2025-07-07PCI: rockchip: Use standard PCIe definitionsGeraldo Nascimento
Current code uses custom-defined register offsets and bitfields for the standard PCIe registers. This creates duplication as the PCI header already defines them. So, switch to using the standard PCIe definitions and drop the custom ones. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com> [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: include bitfield.h] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/e81700ef4b49f584bc8834bfb07b6d8995fc1f42.1751322015.git.geraldogabriel@gmail.com
2025-07-07PCI: dwc: Make dw_pcie_ptm_ops staticManivannan Sadhasivam
dw_pcie_ptm_ops is not used outside of this file, so make it static. This also fixes the sparse warning: drivers/pci/controller/dwc/pcie-designware-debugfs.c:868:27: warning: symbol 'dw_pcie_ptm_ops' was not declared. Should it be static? Fixes: 852a1fdd34a8 ("PCI: dwc: Add debugfs support for PTM context") Reported-by: Bjorn Helgaas <helgaas@kernel.org> Closes: https://lore.kernel.org/linux-pci/20250617231210.GA1172093@bhelgaas Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250701120856.15839-1-mani@kernel.org
2025-07-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni
Cross-merge networking fixes after downstream PR (net-6.16-rc5). No conflicts. No adjacent changes. Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-03PCI/PM: Set power.strict_midlayer in pci_pm_init()Rafael J. Wysocki
The PCI bus type does not expect its runtime PM suspend callback function, pci_pm_runtime_suspend(), to be invoked at all during system- wide suspend and resume, and it does not expect its runtime resume callback function, pci_pm_runtime_resume(), to be invoked at any point when runtime PM is disabled for the given device during system-wide suspend and resume, so make it express that expectation by setting power.strict_midlayer for all PCI devices in pci_pm_prepare() and clear it in pci_pm_complete(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/1925097.atdPhlSkOF@rjwysocki.net
2025-07-03Merge tag 'renesas-dts-for-v6.17-tag1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt Renesas DTS updates for v6.17 - Add SPI FLASH, camera, and Ethernet support on the RZ/G3E SoC and/or the RZ/G3E SoM and SMARC Carrier-II EVK development board, - Add Ethernet, USB2, and PMIC support on the RZ/V2H and RZ/V2N SoCs and EVK boards, - Add timer, I2C, watchdog, and GPU support on the RZ/V2N SoC and the RZ/V2N EVK board, - Add debug LED support for the RZN1D-DB development board, - Improve PCIe clock description on the Retronix Sparrow Hawk board, - Miscellaneous fixes and improvements. * tag 'renesas-dts-for-v6.17-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (34 commits) arm64: dts: renesas: r9a09g047: Add GBETH nodes arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Rename fixed regulator node names arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Add RAA215300 PMIC arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add RAA215300 PMIC arm64: dts: renesas: rcar-gen3: Add bootph-all to sysinfo EEPROMs arm64: dts: renesas: sparrow-hawk: Describe split PCIe clock arm64: dts: renesas: r8a779g0: Describe PCIe root ports arm64: dts: renesas: ebisu: Add CAN0 support ARM: dts: renesas: r9a06g032: Add second clock input to RTC arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable USB2.0 support arm64: dts: renesas: r9a09g056: Add USB2.0 support arm64: dts: renesas: r8a779g3-sparrow-hawk: Sort DTS ARM: dts: renesas: r9a06g032-rzn1d400-db: Describe debug LEDs arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable USB2.0 support PCI/pwrctrl: Add optional slot clock for PCI slots arm64: dts: renesas: r9a09g057: Add USB2.0 support arm64: dts: renesas: r9a09g047e57-smarc: Enable CRU, CSI support arm64: dts: renesas: renesas-smarc2: Enable I2C0 node arm64: dts: renesas: r9a09g047e57-smarc: Add I2C0 pincontrol arm64: dts: renesas: r9a09g047: Add CRU, CSI2 nodes ... Link: https://lore.kernel.org/r/cover.1751026664.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-01PCI: host-generic: Rename and export gen_pci_init() for PCIe controller driversMayank Rana
Rename gen_pci_init() API as pci_host_common_ecam_create() and export it to allow the PCIe controller drivers to create and configure the ECAM region. Note that this API should only used by the drivers managing the drvdata on their own. Rest should continue using pci_host_common_init() API. Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com> [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250616224259.3549811-3-mayank.rana@oss.qualcomm.com
2025-07-01PCI: dwc: Export DWC MSI controller related APIsMayank Rana
Export dw_pcie_msi_host_init(), dw_pcie_msi_init(), and dw_pcie_free_msi() APIs to allow them to be reused by the upcoming DWC based ECAM driver implementation. Also, move MSI IRQ related initialization code to dw_pcie_msi_init(), as this code must be executed before dw_pcie_msi_init() API can be used with ECAM driver. Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com> [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250616224259.3549811-2-mayank.rana@oss.qualcomm.com
2025-06-30Revert "PCI: ecam: Allow cfg->priv to be pre-populated from the root port ↵Marc Zyngier
device" This reverts commit 4900454b4f819e88e9c57ed93542bf9325d7e161. Now that nobody relies of cfg->priv containing anything useful before the .init() callback is used, restore the previous behaviour. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250625111806.4153773-4-maz@kernel.org
2025-06-30PCI: host-generic: Set driver_data before calling gen_pci_init()Geert Uytterhoeven
On MicroChip MPFS Icicle: microchip-pcie 2000000000.pcie: host bridge /soc/pcie@2000000000 ranges: microchip-pcie 2000000000.pcie: Parsing ranges property... microchip-pcie 2000000000.pcie: MEM 0x2008000000..0x2087ffffff -> 0x0008000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000368 Current swapper/0 pgtable: 4K pagesize, 39-bit VAs, pgdp=0x00000000814f1000 [0000000000000368] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Oops [#1] Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-rc1-icicle-00003-gafc0a570bb61 #232 NONE Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) [...] [<ffffffff803fb8a4>] plda_pcie_setup_iomems+0xe/0x78 [<ffffffff803fc246>] mc_platform_init+0x80/0x1d2 [<ffffffff803f9c88>] pci_ecam_create+0x104/0x1e2 [<ffffffff8000adbe>] pci_host_common_init+0x120/0x228 [<ffffffff8000af42>] pci_host_common_probe+0x7c/0x8a The initialization of driver_data was moved after the call to gen_pci_init(), while the pci_ecam_ops.init() callback mc_platform_init() expects it has already been initialized. Fix this by moving the initialization of driver_data up. Fixes: afc0a570bb613871 ("PCI: host-generic: Extract an ECAM bridge creation helper from pci_host_common_probe()") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/774290708a6f0f683711914fda110742c18a7fb2.1750787223.git.geert+renesas@glider.be Link: https://patch.msgid.link/20250625111806.4153773-2-maz@kernel.org
2025-06-30PCI: apple: Add tracking of probed root portsMarc Zyngier
The apple driver relies on being able to directly find the matching root port structure from the platform device that represents this port. A previous hack stashed a pointer to the root port structure in the config window private pointer, but that ended up relying on assumptions that break other drivers. Instead, bite the bullet and track the association as part of the driver itself as a list of probed root ports. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250625111806.4153773-3-maz@kernel.org
2025-06-27Merge tag 'pci-v6.16-fixes-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fix from Bjorn Helgaas: - Fix a PTM debugfs build error with CONFIG_DEBUG_FS=n && CONFIG_PCIE_PTM=y (Manivannan Sadhasivam) * tag 'pci-v6.16-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/PTM: Build debugfs code only if CONFIG_DEBUG_FS is enabled
2025-06-26PCI/AER: Add message when AER_MAX_MULTI_ERR_DEVICES limit is hitAkshay Jindal
When a PCIe device detects an error, it logs the error locally and issues an error Message routed to the Root Complex (PCIe r6.0, sec 6.2.5). If the Root Port or RCEC supports AER and Linux has enabled the AER interrupt, aer_isr() traverses the relevant devices and adds those with AER errors logged to the aer_err_info.dev[] array for error logging and recovery. If aer_isr() finds more than AER_MAX_MULTI_ERR_DEVICES devices with AER errors logged, it silently ignores them, and those extra devices are not included in the recovery flow. Emit an error message if we find more than AER_MAX_MULTI_ERR_DEVICES devices with AER errors logged. Testing details at link below. Signed-off-by: Akshay Jindal <akshayaj.lkd@gmail.com> [bhelgaas: commit log, join error message] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250619185041.73240-1-akshayaj.lkd@gmail.com
2025-06-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.16-rc4). Conflicts: Documentation/netlink/specs/mptcp_pm.yaml 9e6dd4c256d0 ("netlink: specs: mptcp: replace underscores with dashes in names") ec362192aa9e ("netlink: specs: fix up indentation errors") https://lore.kernel.org/20250626122205.389c2cd4@canb.auug.org.au Adjacent changes: Documentation/netlink/specs/fou.yaml 791a9ed0a40d ("netlink: specs: fou: replace underscores with dashes in names") 880d43ca9aa4 ("netlink: specs: clean up spaces in brackets") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-25PCI: endpoint: Fix configfs group removal on driver teardownDamien Le Moal
An endpoint driver configfs attributes group is added to the epf_group list of struct pci_epf_driver by pci_epf_add_cfs() but an added group is not removed from this list when the attribute group is unregistered with pci_ep_cfs_remove_epf_group(). Add the missing list_del() call in pci_ep_cfs_remove_epf_group() to correctly remove the attribute group from the driver list. With this change, once the loop over all attribute groups in pci_epf_remove_cfs() completes, the driver epf_group list should be empty. Add a WARN_ON() to make sure of that. Fixes: ef1433f717a2 ("PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry") Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250624114544.342159-3-dlemoal@kernel.org
2025-06-25PCI: endpoint: Fix configfs group list head handlingDamien Le Moal
Doing a list_del() on the epf_group field of struct pci_epf_driver in pci_epf_remove_cfs() is not correct as this field is a list head, not a list entry. This list_del() call triggers a KASAN warning when an endpoint function driver which has a configfs attribute group is torn down: ================================================================== BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198 Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319 CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONE Hardware name: Radxa ROCK 5B (DT) Call trace: show_stack+0x2c/0x84 (C) dump_stack_lvl+0x70/0x98 print_report+0x17c/0x538 kasan_report+0xb8/0x190 __asan_report_store8_noabort+0x20/0x2c pci_epf_remove_cfs+0x17c/0x198 pci_epf_unregister_driver+0x18/0x30 nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf] __arm64_sys_delete_module+0x264/0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ... Remove this incorrect list_del() call from pci_epf_remove_cfs(). Fixes: ef1433f717a2 ("PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry") Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250624114544.342159-2-dlemoal@kernel.org
2025-06-25PCI: dwc: Simplify the return value of PTM debugfs functions returning boolHans Zhang
Replace redundant ternary conditional expressions with direct boolean returns in PTM debugfs functions. Specifically change this pattern: return (condition) ? true : false; to the simpler: return condition; Signed-off-by: Hans Zhang <18255117159@163.com> [mani: subject rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20250612161226.950937-1-18255117159@163.com
2025-06-25PCI: Move link up wait time and max retries macros to pci.hNiklas Cassel
Move the LINK_WAIT_SLEEP_MS and LINK_WAIT_MAX_RETRIES macros to pci.h. Prefix the macros with PCIE_ in order to avoid redefining these for drivers that already have macros named like this. No functional changes. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250625102347.1205584-15-cassel@kernel.org
2025-06-25PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link upNiklas Cassel
As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request. Add this delay in dw_pcie_wait_for_link(), after the link is reported as up. The delay will only be performed in the success case where the link came up. DWC glue drivers that have a link up IRQ (drivers that set use_linkup_irq = true) do not call dw_pcie_wait_for_link(), instead they perform this delay in their threaded link up IRQ handler. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Link: https://patch.msgid.link/20250625102347.1205584-14-cassel@kernel.org
2025-06-25PCI: qcom: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQNiklas Cassel
Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to 36971d6c5a9a ("PCI: qcom: Don't wait for link if we can detect Link Up"), qcom used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After 36971d6c5a9a, qcom_pcie_global_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Link: https://patch.msgid.link/20250625102347.1205584-13-cassel@kernel.org
2025-06-25PCI: dw-rockchip: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQNiklas Cassel
Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we can detect Link Up"), dw-rockchip used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After ec9fd499b9c6, rockchip_pcie_rc_sys_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Cc: Laszlo Fiat <laszlo.fiat@proton.me> Link: https://patch.msgid.link/20250625102347.1205584-12-cassel@kernel.org
2025-06-25PCI: rockchip-host: Use macro PCIE_RESET_CONFIG_WAIT_MSNiklas Cassel
Macro PCIE_RESET_CONFIG_DEVICE_WAIT_MS was added to pci.h in commit d5ceb9496c56 ("PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value"). Later, in commit 70a7bfb1e515 ("PCI: rockchip-host: Wait 100ms after reset before starting configuration"), PCIE_T_RRS_READY_MS was added to pci.h. These macros are duplicates, and represent the exact same delay in the PCIe specification. Since the comment above PCIE_RESET_CONFIG_WAIT_MS is strictly more correct than the comment above PCIE_T_RRS_READY_MS, change rockchip-host to use PCIE_RESET_CONFIG_WAIT_MS, and remove PCIE_T_RRS_READY_MS, as rockchip-host is the only user of this macro. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Link: https://patch.msgid.link/20250625102347.1205584-11-cassel@kernel.org
2025-06-25PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MSNiklas Cassel
Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250625102347.1205584-10-cassel@kernel.org
2025-06-24PCI: Adjust the position of reading the Link Control 2 registerJiwei Sun
In a89c82249c37 ("PCI: Work around PCIe link training failures"), if the speed limit is set to 2.5 GT/s and the retraining is successful, an attempt will be made to lift the speed limit. One condition for lifting the speed limit is to check whether the link speed field of the Link Control 2 register is PCI_EXP_LNKCTL2_TLS_2_5GT. However, since de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed"), the `lnkctl2` local variable does not undergo any changes during the speed limit setting and retraining process. As a result, the code intended to lift the speed limit is not executed. To address this issue, adjust the position of the Link Control 2 register read operation in the code and place it before its use. Fixes: de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiwei Sun <sunjw10@lenovo.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250123055155.22648-3-sjiwei@163.com
2025-06-24PCI: Fix link speed calculation on retrain failureJiwei Sun
When pcie_failed_link_retrain() fails to retrain, it tries to revert to the previous link speed. However it calculates that speed from the Link Control 2 register without masking out non-speed bits first. PCIE_LNKCTL2_TLS2SPEED() converts such incorrect values to PCI_SPEED_UNKNOWN (0xff), which in turn causes a WARN splat in pcie_set_target_speed(): pci 0000:00:01.1: [1022:14ed] type 01 class 0x060400 PCIe Root Port pci 0000:00:01.1: broken device, retraining non-functional downstream link at 2.5GT/s pci 0000:00:01.1: retraining failed WARNING: CPU: 1 PID: 1 at drivers/pci/pcie/bwctrl.c:168 pcie_set_target_speed RDX: 0000000000000001 RSI: 00000000000000ff RDI: ffff9acd82efa000 pcie_failed_link_retrain pci_device_add pci_scan_single_device Mask out the non-speed bits in PCIE_LNKCTL2_TLS2SPEED() and PCIE_LNKCAP_SLS2SPEED() so they don't incorrectly return PCI_SPEED_UNKNOWN. Fixes: de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") Reported-by: Andrew <andreasx0@protonmail.com> Closes: https://lore.kernel.org/r/7iNzXbCGpf8yUMJZBQjLdbjPcXrEJqBxy5-bHfppz0ek-h4_-G93b1KUrm106r2VNF2FV_sSq0nENv4RsRIUGnlYZMlQr2ZD2NyB5sdj5aU=@protonmail.com/ Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiwei Sun <sunjw10@lenovo.com> [bhelgaas: commit log, add details from https://lore.kernel.org/r/1c92ef6bcb314ee6977839b46b393282e4f52e74.1750684771.git.lukas@wunner.de] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: stable@vger.kernel.org # v6.13+ Link: https://patch.msgid.link/20250123055155.22648-2-sjiwei@163.com
2025-06-23Revert "PCI/ACPI: Fix allocated memory release on error in pci_acpi_scan_root()"Zhe Qiao
This reverts commit 631b2af2f357 ("PCI/ACPI: Fix allocated memory release on error in pci_acpi_scan_root()"). The reverted patch causes the 'ri->cfg' and 'root_ops' resources to be released multiple times. When acpi_pci_root_create() fails, these resources have already been released internally by the __acpi_pci_root_release_info() function. Releasing them again in pci_acpi_scan_root() leads to incorrect behavior and potential memory issues. We plan to resolve the issue using a more appropriate fix. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/aEmdnuw715btq7Q5@stanley.mountain/ Signed-off-by: Zhe Qiao <qiaozhe@iscas.ac.cn> Acked-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20250619072608.2075475-1-qiaozhe@iscas.ac.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-23PCI/PTM: Build debugfs code only if CONFIG_DEBUG_FS is enabledManivannan Sadhasivam
Otherwise, the following build error will happen for CONFIG_DEBUG_FS=n && CONFIG_PCIE_PTM=y: drivers/pci/pcie/ptm.c:498:25: error: redefinition of 'pcie_ptm_create_debugfs' 498 | struct pci_ptm_debugfs *pcie_ptm_create_debugfs(struct device *dev, void *pdata, | ^ ./include/linux/pci.h:1915:2: note: previous definition is here 1915 | *pcie_ptm_create_debugfs(struct device *dev, void *pdata, | ^ drivers/pci/pcie/ptm.c:546:6: error: redefinition of 'pcie_ptm_destroy_debugfs' 546 | void pcie_ptm_destroy_debugfs(struct pci_ptm_debugfs *ptm_debugfs) | ^ ./include/linux/pci.h:1918:1: note: previous definition is here 1918 | pcie_ptm_destroy_debugfs(struct pci_ptm_debugfs *ptm_debugfs) { } | Fixes: 132833405e61 ("PCI: Add debugfs support for exposing PTM context") Reported-by: Eric Biggers <ebiggers@kernel.org> Closes: https://lore.kernel.org/linux-pci/20250607025506.GA16607@sol Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Eric Biggers <ebiggers@kernel.org> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://patch.msgid.link/20250608033305.15214-1-manivannan.sadhasivam@linaro.org
2025-06-23PCI: endpoint: pci-epf-vntb: Align MW naming with config namesJerome Brunet
The config file related to the memory windows start the numbering of the MW from 1. The other NTB function does the same, yet the enumeration defining the BARs of the vNTB function starts numbering the MW from 0. Both numbering should be fine, but mixing the two is a bit confusing. The configfs file being the interface with userspace, keep that stable and consistently start the numbering of the MW from 1. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-2-fc685a22ad28@baylibre.com
2025-06-23PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() failsJerome Brunet
According the function documentation of epf_ntb_init_epc_bar(), the function should return an error code on error. However, it returns -1 when no BAR is available i.e., when pci_epc_get_next_free_bar() fails. Return -ENOENT instead. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> [mani: changed err code to -ENOENT] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-1-fc685a22ad28@baylibre.com
2025-06-23PCI: brcmstb: Set MLW based on "num-lanes" DT property if presentJim Quinlan
By default, the driver relies on the default hardware defined value for the Max Link Width (MLW) capability. But if the "num-lanes" DT property is present, assume that the chip's default capability information is incorrect or undesired, and use the specified value instead. Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> [mani: reworded the description and comments] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250530224035.41886-3-james.quinlan@broadcom.com
2025-06-23PCI: vmd: Add VMD Device ID Support for Panther Lake (PTL)-H/P/UGeorge D Sworo
Add VMD Device ID Support for PTL-H/P/U processors. Signed-off-by: George D Sworo <george.d.sworo@intel.com> [mani: expanded PTL] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250606210230.340803-2-george.d.sworo@intel.com
2025-06-23Merge 6.16-rc3 into driver-core-nextGreg Kroah-Hartman
We need the driver-core fixes that are in 6.16-rc3 into here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19PCI: dw-rockchip: Delay link training after hot reset in EP modeWilfred Mallawa
RK3588 TRM, section "11.6.1.3.3 Hot Reset and Link-Down Reset" states that: If you want to delay link re-establishment (after reset) so that you can reprogram some registers through DBI, you must set app_ltssm_enable =0 immediately after core_rst_n as shown in above. This can be achieved by enable the app_dly2_en, and end-up the delay by assert app_dly2_done. I.e. setting app_dly2_en will automatically deassert app_ltssm_enable on a hot reset, and setting app_dly2_done will re-assert app_ltssm_enable, re-enabling link training. When receiving a hot reset/link-down IRQ when running in EP mode, we will call dw_pcie_ep_linkdown(), which may update registers through DBI. Unless link training is inhibited, these register updates race with the link training. To avoid the race, set PCIE_LTSSM_APP_DLY2_EN so the controller never automatically trains the link after a link-down or hot reset interrupt. That way any DBI updates done in the dw_pcie_ep_linkdown() path will happen while the link is still down. Then allow link training by setting PCIE_LTSSM_APP_DLY2_DONE Co-developed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250613101908.2182053-2-cassel@kernel.org
2025-06-19PCI: rockchip: Remove redundant PCIe message routing definitionsHans Zhang
The Rockchip driver contains duplicated message routing and INTx code definitions (e.g., ROCKCHIP_PCIE_MSG_ROUTING_TO_RC, ROCKCHIP_PCIE_MSG_CODE_ASSERT_INTA). These are already provided by the PCI core in drivers/pci/pci.h as PCIE_MSG_TYPE_R_RC and PCIE_MSG_CODE_ASSERT_INTA, respectively. Remove the driver-specific definitions in favor of the core definitions instead. This aligns the driver with the PCIe specification and reduces maintenance overhead. Signed-off-by: Hans Zhang <18255117159@163.com> [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250607154913.805027-3-18255117159@163.com
2025-06-19PCI: cadence: Replace private message routing enums with PCI core definitionsHans Zhang
The Cadence driver previously defined its own message routing enums (e.g., MSG_ROUTING_LOCAL) and message codes, which duplicated existing PCI core macros (PCIE_MSG_TYPE_R_LOCAL, PCIE_MSG_CODE_ASSERT_INTA, etc.) in drivers/pci/pci.h. These core definitions align with the PCIe r6.0 spec. Remove the driver-specific enums and switch to the centralized PCI core macros. This eliminates redundancy, ensures consistency, and simplifies future updates. No functional changes are introduced. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250607154913.805027-2-18255117159@163.com
2025-06-18PCI/MSI: Remove duplicated to_pci_dev() conversionChris Li
In pci_msi_update_mask(), "lock = &to_pci_dev()" does the to_pci_dev() lookup, and there's another one buried inside msi_desc_to_pci_dev(). Introduce a local variable to remove that duplication. Signed-off-by: Chris Li <chrisl@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/all/20250617-pci-msi-avoid-dup-pcidev-v1-1-ed75b0419023@kernel.org
2025-06-18PCI: pciehp: Ignore belated Presence Detect Changed caused by DPCLukas Wunner
Commit c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by DPC") sought to ignore Presence Detect Changed events occurring as a side effect of Downstream Port Containment. The commit awaits recovery from DPC and then clears events which occurred in the meantime. However if the first event seen after DPC is Data Link Layer State Changed, only that event is cleared and not Presence Detect Changed. The object of the commit is thus defeated. That's because pciehp_ist() computes the events to clear based on the local "events" variable instead of "ctrl->pending_events". The former contains the events that had occurred when pciehp_ist() was entered, whereas the latter also contains events that have accumulated while awaiting DPC recovery. In practice, the order of PDC and DLLSC events is arbitrary and the delay in-between can be several milliseconds. So change the logic to always clear PDC events, even if they come after an initial DLLSC event. Fixes: c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by DPC") Reported-by: Lương Việt Hoàng <tcm4095@gmail.com> Reported-by: Joel Mathew Thomas <proxy0@tutamail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219765#c165 Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Lương Việt Hoàng <tcm4095@gmail.com> Tested-by: Joel Mathew Thomas <proxy0@tutamail.com> Link: https://patch.msgid.link/d9c4286a16253af7e93eaf12e076e3ef3546367a.1750257164.git.lukas@wunner.de
generated by cgit (git 2.34.1) at 2025-09-11 17:38:11 +0000