blaster4385/linux-IllusionX/drivers/pci/controller, branch v6.12.10

PCI: starfive: Enable controller runtime PM before probing host bridge

2024-12-14T19:04:04Z

[ Upstream commit 6168efbebace0db443185d4c6701ca8170a8788d ] A PCI controller device, e.g., StarFive, is parent to PCI host bridge device. We must enable runtime PM of the controller before enabling runtime PM of the host bridge, which will happen in pci_host_probe(), to avoid this warning: pcie-starfive 940000000.pcie: Enabling runtime PM for inactive device with active children Fix this issue by enabling StarFive controller device's runtime PM before calling pci_host_probe() in plda_pcie_host_init(). Link: https://lore.kernel.org/r/20241111-runtime_pm-v7-1-9c164eefcd87@quicinc.com Tested-by: Marek Szyprowski Signed-off-by: Mayank Rana [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin

PCI: vmd: Set devices to D0 before enabling PM L1 Substates

2024-12-14T19:04:04Z

[ Upstream commit d66041063192497a4a97d21dbf86b79a03a7f4fb ] The remapped PCIe Root Port and the child device have PM L1 Substates capability, but they are disabled originally. Here is a failed example on ASUS B1400CEAE: Capabilities: [900 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+ PortCommonModeRestoreTime=32us PortTPowerOnTime=10us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=101376ns L1SubCtl2: T_PwrOn=50us Enable PCI-PM L1 PM Substates for devices below VMD while they are in D0 (see PCIe r6.0, sec 5.5.4). Link: https://lore.kernel.org/r/20241001083438.10070-4-jhp@endlessos.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=218394 Signed-off-by: Jian-Hong Pan Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Sasha Levin

PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs

2024-12-14T19:04:04Z

[ Upstream commit b727484cace4be22be9321cc0bc9487648ba447b ] Add support for this VMD device which supports the bus restriction mode. The feature that turns off vector 0 for MSI-X remapping is also enabled. Link: https://lore.kernel.org/r/20241011175657.249948-1-nirmal.patel@linux.intel.com Signed-off-by: Nirmal Patel Signed-off-by: Krzysztof Wilczyński Reviewed-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin

PCI: qcom: Add support for IPQ9574

2024-12-14T19:04:04Z

[ Upstream commit a63b74f2e35be3829f256922037ae5cee6bb844a ] Add the new IPQ9574 platform which is based on the Qcom IP rev. 1.27.0 and Synopsys IP rev. 5.80a. The platform itself has four PCIe Gen3 controllers: two single-lane and two dual-lane, all are based on Synopsys IP rev. 5.70a. As such, reuse all the members of 'ops_2_9_0'. Link: https://lore.kernel.org/r/20240801054803.3015572-5-quic_srichara@quicinc.com Co-developed-by: Anusha Rao Signed-off-by: Anusha Rao Signed-off-by: devi priya Signed-off-by: Sricharan Ramabadhran [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Dmitry Baryshkov Reviewed-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin

PCI: rockchip-ep: Fix address translation unit programming

2024-12-09T09:41:09Z

commit 64f093c4d99d797b68b407a9d8767aadc3e3ea7a upstream. The Rockchip PCIe endpoint controller handles PCIe transfers addresses by masking the lower bits of the programmed PCI address and using the same number of lower bits masked from the CPU address space used for the mapping. For a PCI mapping of bytes starting from , the number of bits masked is the number of address bits changing in the address range [pci_addr..pci_addr + size - 1]. However, rockchip_pcie_prog_ep_ob_atu() calculates num_pass_bits only using the size of the mapping, resulting in an incorrect number of mask bits depending on the value of the PCI address to map. Fix this by introducing the helper function rockchip_pcie_ep_ob_atu_num_bits() to correctly calculate the number of mask bits to use to program the address translation unit. The number of mask bits is calculated depending on both the PCI address and size of the mapping, and clamped between 8 and 20 using the macros ROCKCHIP_PCIE_AT_MIN_NUM_BITS and ROCKCHIP_PCIE_AT_MAX_NUM_BITS. As defined in the Rockchip RK3399 TRM V1.3 Part2, Sections 17.5.5.1.1 and 17.6.8.2.1, this clamping is necessary because: 1) The lower 8 bits of the PCI address to be mapped by the outbound region are ignored. So a minimum of 8 address bits are needed and imply that the PCI address must be aligned to 256. 2) The outbound memory regions are 1MB in size. So while we can specify up to 63-bits for the PCI address (num_bits filed uses bits 0 to 5 of the outbound address region 0 register), we must limit the number of valid address bits to 20 to match the memory window maximum size (1 << 20 = 1MB). Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller") Link: https://lore.kernel.org/r/20241017015849.190271-2-dlemoal@kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: dwc: ep: Fix advertised resizable BAR size regression

2024-12-09T09:41:08Z

commit 118397c9baaac0b7ec81896f8d755d09aa82c485 upstream. The advertised resizable BAR size was fixed in commit 72e34b8593e0 ("PCI: dwc: endpoint: Fix advertised resizable BAR size"). Commit 867ab111b242 ("PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event") was included shortly after this, and moved the code to another function. When the code was moved, this fix was mistakenly lost. According to the spec, it is illegal to not have a bit set in PCI_REBAR_CAP, and 1 MB is the smallest size allowed. So, set bit 4 in PCI_REBAR_CAP, so that we actually advertise support for a 1 MB BAR size. Fixes: 867ab111b242 ("PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event") Link: https://lore.kernel.org/r/20241116005950.2480427-2-cassel@kernel.org Link: https://lore.kernel.org/r/20240606-pci-deinit-v1-3-4395534520dc@linaro.org Link: https://lore.kernel.org/r/20240307111520.3303774-1-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: keystone: Add link up check to ks_pcie_other_map_bus()

2024-12-09T09:41:07Z

commit 9e9ec8d8692a6f64d81ef67d4fb6255af6be684b upstream. K2G forwards the error triggered by a link-down state (e.g., no connected endpoint device) on the system bus for PCI configuration transactions; these errors are reported as an SError at system level, which is fatal and hangs the system. So, apply fix similar to how it was done in the DesignWare Core driver commit 15b23906347c ("PCI: dwc: Add link up check in dw_child_pcie_ops.map_bus()"). Fixes: 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors") Link: https://lore.kernel.org/r/20240524105714.191642-3-s-vadapalli@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Siddharth Vadapalli [kwilczynski: commit log, added tag for stable releases] Signed-off-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: keystone: Set mode as Root Complex for "ti,keystone-pcie" compatible

2024-12-09T09:41:07Z

commit 5a938ed9481b0c06cb97aec45e722a80568256fd upstream. commit 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") introduced configuring "enum dw_pcie_device_mode" as part of device data ("struct ks_pcie_of_data"). However it failed to set the mode for "ti,keystone-pcie" compatible. Since the mode defaults to "DW_PCIE_UNKNOWN_TYPE", the following error message is displayed for the v3.65a controller: "INVALID device type 0" Despite the driver probing successfully, the controller may not be functional in the Root Complex mode of operation. So, set the mode as Root Complex for "ti,keystone-pcie" compatible to fix this. Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") Link: https://lore.kernel.org/r/20240524105714.191642-2-s-vadapalli@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Siddharth Vadapalli [kwilczynski: commit log, added tag for stable releases] Signed-off-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Fix suspend/resume support on i.MX6QDL

2024-12-09T09:41:04Z

commit 0a726f542d7c8cc0f9c5ed7df5a4bd4b59ac21b3 upstream. The suspend/resume functionality is currently broken on the i.MX6QDL platform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf This patch addresses the issue by sharing most of the suspend/resume sequences used by other i.MX devices, while avoiding modifications to critical registers that disrupt the PCIe functionality. It targets the same problem as the following downstream commit: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995 Unlike the downstream commit, this patch also resets the connected PCIe device if possible. Without this reset, certain drivers, such as ath10k or iwlwifi, will crash on resume. The device reset is also done by the driver on other i.MX platforms, making this patch consistent with existing practices. Upon resuming, the kernel will hang and display an error. Here's an example of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944 Without this patch, suspend/resume will fail on i.MX6QDL devices if a PCIe device is connected. Link: https://lore.kernel.org/r/20241030103250.83640-1-eichest@gmail.com Signed-off-by: Stefan Eichenberger [kwilczynski: commit log, added tag for stable releases] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Manivannan Sadhasivam Acked-by: Richard Zhu Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: qcom: Disable ASPM L0s for X1E80100

2024-12-09T09:41:04Z

commit fba6045161d686adc102b6ef71b2fd1e5f90a616 upstream. Currently, the cfg_1_9_0 which is being used for X1E80100 doesn't disable ASPM L0s. However, hardware team recommends to disable L0s as the PHY init sequence is not tuned support L0s. Hence reuse cfg_sc8280xp for X1E80100. Note that the config_sid() callback is not present in cfg_sc8280xp, don't concern about this because config_sid() callback is originally a no-op for X1E80100. Fixes: 6d0c39324c5f ("PCI: qcom: Add X1E80100 PCIe support") Link: https://lore.kernel.org/r/20241101030902.579789-5-quic_qianyu@quicinc.com Signed-off-by: Qiang Yu Signed-off-by: Krzysztof Wilczyński Reviewed-by: Dmitry Baryshkov Reviewed-by: Johan Hovold Reviewed-by: Manivannan Sadhasivam Cc: # 6.9 Signed-off-by: Greg Kroah-Hartman