kernel/linux.git/drivers/pci/controller/dwc, branch v6.1.124

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

2024-12-14T18:54:15+00:00

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-14T18:54:15+00:00

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 missing call to phy_power_off() in error handling

2024-10-17T13:21:15+00:00

commit 5b04d44d5c74e4d8aab1678496b84700b4b343fe upstream. Fix missing call to phy_power_off() in the error path of imx6_pcie_host_init(). Remove unnecessary check for imx6_pcie->phy as the PHY API already handles NULL pointers. Fixes: cbcf8722b523 ("phy: freescale: imx8m-pcie: Fix the wrong order of phy_init() and phy_power_on()") Link: https://lore.kernel.org/linux-pci/20240729-pci2_upstream-v8-3-b68ee5ef2b4d@nxp.com Signed-off-by: Frank Li [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Manivannan Sadhasivam Cc: # 6.1+ Signed-off-by: Greg Kroah-Hartman

PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()

2024-10-17T13:21:06+00:00

[ Upstream commit c500a86693a126c9393e602741e348f80f1b0fc5 ] Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: b22dbbb24571 ("PCI: kirin: Support PERST# GPIOs for HiKey970 external PEX 8606 bridge") Link: https://lore.kernel.org/linux-pci/20240903115823.30647-1-adiupina@astralinux.ru Signed-off-by: Alexandra Diupina [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

PCI: keystone: Fix if-statement expression in ks_pcie_quirk()

2024-10-17T13:21:04+00:00

[ Upstream commit 6188a1c762eb9bbd444f47696eda77a5eae6207a ] This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. Fixes: 86f271f22bbb ("PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)") Link: https://lore.kernel.org/linux-pci/1b762a93-e1b2-4af3-8c04-c8843905c279@stanley.mountain Signed-off-by: Dan Carpenter [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Manivannan Sadhasivam Reviewed-by: Siddharth Vadapalli Signed-off-by: Sasha Levin

PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)

2024-09-12T09:10:20+00:00

[ Upstream commit 86f271f22bbb6391410a07e08d6ca3757fda01fa ] Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf Link: https://lore.kernel.org/linux-pci/16e1fcae-1ea7-46be-b157-096e05661b15@siemens.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Achal Verma Signed-off-by: Vignesh Raghavendra Signed-off-by: Jan Kiszka Signed-off-by: Krzysztof Wilczyński Reviewed-by: Siddharth Vadapalli Signed-off-by: Sasha Levin

PCI: al: Check IORESOURCE_BUS existence during probe

2024-09-08T05:53:09+00:00

[ Upstream commit a9927c2cac6e9831361e43a14d91277818154e6a ] If IORESOURCE_BUS is not provided in Device Tree it will be fabricated in of_pci_parse_bus_range(), so NULL pointer dereference should not happen here. But that's hard to verify, so check for NULL anyway. Found by Linux Verification Center (linuxtesting.org) with SVACE. Link: https://lore.kernel.org/linux-pci/20240503125705.46055-1-amishin@t-argos.ru Suggested-by: Bjorn Helgaas Signed-off-by: Aleksandr Mishin Signed-off-by: Krzysztof Wilczyński [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: dw-rockchip: Fix initial PERST# GPIO value

2024-08-03T06:49:37+00:00

commit 28b8d7793b8573563b3d45321376f36168d77b1e upstream. PERST# is active low according to the PCIe specification. However, the existing pcie-dw-rockchip.c driver does: gpiod_set_value(..., 0); msleep(100); gpiod_set_value(..., 1); when asserting + deasserting PERST#. This is of course wrong, but because all the device trees for this compatible string have also incorrectly marked this GPIO as ACTIVE_HIGH: $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3568* $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3588* The actual toggling of PERST# is correct, and we cannot change it anyway, since that would break device tree compatibility. However, this driver does request the GPIO to be initialized as GPIOD_OUT_HIGH, which does cause a silly sequence where PERST# gets toggled back and forth for no good reason. Fix this by requesting the GPIO to be initialized as GPIOD_OUT_LOW (which for this driver means PERST# asserted). This will avoid an unnecessary signal change where PERST# gets deasserted (by devm_gpiod_get_optional()) and then gets asserted (by rockchip_pcie_start_link()) just a few instructions later. Before patch, debug prints on EP side, when booting RC: [ 845.606810] pci: PERST# asserted by host! [ 852.483985] pci: PERST# de-asserted by host! [ 852.503041] pci: PERST# asserted by host! [ 852.610318] pci: PERST# de-asserted by host! After patch, debug prints on EP side, when booting RC: [ 125.107921] pci: PERST# asserted by host! [ 132.111429] pci: PERST# de-asserted by host! This extra, very short, PERST# assertion + deassertion has been reported to cause issues with certain WLAN controllers, e.g. RTL8822CE. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Link: https://lore.kernel.org/linux-pci/20240417164227.398901-1-cassel@kernel.org Tested-by: Heiko Stuebner Tested-by: Jianfeng Liu Signed-off-by: Niklas Cassel Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Heiko Stuebner Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Greg Kroah-Hartman

PCI: dwc: Fix index 0 incorrectly being interpreted as a free ATU slot

2024-08-03T06:49:22+00:00

[ Upstream commit c2a57ee0f2f1ad8c970ff58b78a43e85abbdeb7f ] When PERST# assert and deassert happens on the PERST# supported platforms, both iATU0 and iATU6 will map inbound window to BAR0. DMA will access the area that was previously allocated (iATU0) for BAR0, instead of the new area (iATU6) for BAR0. Right now, this isn't an issue because both iATU0 and iATU6 should translate inbound accesses to BAR0 to the same allocated memory area. However, having two separate inbound mappings for the same BAR is a disaster waiting to happen. The mappings between PCI BAR and iATU inbound window are maintained in the dw_pcie_ep::bar_to_atu[] array. While allocating a new inbound iATU map for a BAR, dw_pcie_ep_inbound_atu() API checks for the availability of the existing mapping in the array and if it is not found (i.e., value in the array indexed by the BAR is found to be 0), it allocates a new map value using find_first_zero_bit(). The issue is the existing logic failed to consider the fact that the map value '0' is a valid value for BAR0, so find_first_zero_bit() will return '0' as the map value for BAR0 (note that it returns the first zero bit position). Due to this, when PERST# assert + deassert happens on the PERST# supported platforms, the inbound window allocation restarts from BAR0 and the existing logic to find the BAR mapping will return '6' for BAR0 instead of '0' due to the fact that it considers '0' as an invalid map value. Fix this issue by always incrementing the map value before assigning to bar_to_atu[] array and then decrementing it while fetching. This will make sure that the map value '0' always represents the invalid mapping." Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") Closes: https://lore.kernel.org/linux-pci/ZXsRp+Lzg3x%2Fnhk3@x1-carbon/ Link: https://lore.kernel.org/linux-pci/20240412160841.925927-1-Frank.Li@nxp.com Reported-by: Niklas Cassel Tested-by: Niklas Cassel Signed-off-by: Frank Li Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin

PCI: qcom-ep: Disable resources unconditionally during PERST# assert

2024-08-03T06:49:22+00:00

[ Upstream commit 912315715d7b74f7abdb6f063ebace44ee288af9 ] All EP specific resources are enabled during PERST# deassert. As a counter operation, all resources should be disabled during PERST# assert. There is no point in skipping that if the link was not enabled. This will also result in enablement of the resources twice if PERST# got deasserted again. So remove the check from qcom_pcie_perst_assert() and disable all the resources unconditionally. Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver") Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-1-22832d0d456f@linaro.org Tested-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin