kernel/drivers/pci/controller/dwc/pcie-qcom.c, branch linux-6.5.y

PCI: qcom: Fix IPQ8074 enumeration

2023-10-10T20:02:57Z

commit 6a878a54d0053ef21f3b829dc267487c2302b012 upstream. PARF_SLV_ADDR_SPACE_SIZE_2_3_3 is used by qcom_pcie_post_init_2_3_3(). This PCIe slave address space size register offset is 0x358 but was incorrectly changed to 0x16c by 39171b33f652 ("PCI: qcom: Remove PCIE20_ prefix from register definitions"). This prevented access to slave address space registers like iATU, etc., so the IPQ8074 PCIe controller was not enumerated. Revert back to the correct 0x358 offset and remove the unused PARF_SLV_ADDR_SPACE_SIZE_2_3_3. Fixes: 39171b33f652 ("PCI: qcom: Remove PCIE20_ prefix from register definitions") Link: https://lore.kernel.org/r/20230919102948.1844909-1-quic_srichara@quicinc.com Tested-by: Robert Marko Signed-off-by: Sricharan Ramabadhran [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Greg Kroah-Hartman

PCI: qcom: Do not advertise hotplug capability for IP v2.1.0

2023-06-20T10:12:44Z

SoCs making use of Qcom PCIe controller IP v2.1.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-10-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi

PCI: qcom: Do not advertise hotplug capability for IP v1.0.0

2023-06-20T10:12:44Z

SoCs making use of Qcom PCIe controller IP v1.0.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-9-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi

PCI: qcom: Use post init sequence of IP v2.3.2 for v2.4.0

2023-06-20T10:12:44Z

The post init sequence of IP v2.4.0 is same as v2.3.2. So let's reuse the v2.3.2 sequence which now also disables hotplug capability of the controller as it is not at all supported on any SoCs making use of this IP. Link: https://lore.kernel.org/r/20230619150408.8468-8-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi Reviewed-by: Dmitry Baryshkov

PCI: qcom: Do not advertise hotplug capability for IP v2.3.2

2023-06-20T10:12:44Z

SoCs making use of Qcom PCIe controller IP v2.3.2 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-7-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi

PCI: qcom: Do not advertise hotplug capability for IPs v2.3.3 and v2.9.0

2023-06-20T10:12:44Z

SoCs making use of Qcom PCIe controller IPs v2.3.3 and v2.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's not set the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-6-manivannan.sadhasivam@linaro.org Tested-by: Sricharan Ramabadhran Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi Reviewed-by: Dmitry Baryshkov

PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0

2023-06-20T10:12:44Z

SoCs making use of Qcom PCIe controller IPs v2.7.0 and v1.9.0 do not support hotplug functionality. But the hotplug capability bit is set by default in the hardware. This causes the kernel PCI core to register hotplug service for the controller and send hotplug commands to it. But those commands will timeout generating messages as below during boot and suspend/resume. [ 5.782159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2020 msec ago) [ 5.810161] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x03c0 (issued 2048 msec ago) [ 7.838162] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2020 msec ago) [ 7.870159] pcieport 0001:00:00.0: pciehp: Timeout on hotplug command 0x07c0 (issued 2052 msec ago) This not only spams the console output but also induces a delay of a couple of seconds. To fix this issue, let's clear the HPC bit in PCI_EXP_SLTCAP register as a part of the post init sequence to not advertise the hotplug capability for the controller. Link: https://lore.kernel.org/r/20230619150408.8468-5-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi Reviewed-by: Dmitry Baryshkov

PCI: qcom: Disable write access to read only registers for IP v2.9.0

2023-06-20T10:12:44Z

In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. While at it, let's also add a newline after existing dw_pcie_dbi_ro_wr_en() guard function to align with rest of the driver. Link: https://lore.kernel.org/r/20230619150408.8468-4-manivannan.sadhasivam@linaro.org Fixes: 0cf7c2efe8ac ("PCI: qcom: Add IPQ60xx support") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi Reviewed-by: Dmitry Baryshkov

PCI: qcom: Use DWC helpers for modifying the read-only DBI registers

2023-06-20T10:12:44Z

DWC core already exposes dw_pcie_dbi_ro_wr_{en/dis} helper APIs for enabling and disabling the write access to read only DBI registers. So let's use them instead of doing it manually. Also, the existing code doesn't disable the write access when it's done. This is also fixed now. Link: https://lore.kernel.org/r/20230619150408.8468-3-manivannan.sadhasivam@linaro.org Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi Reviewed-by: Dmitry Baryshkov

PCI: qcom: Disable write access to read only registers for IP v2.3.3

2023-06-20T10:12:44Z

In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. Link: https://lore.kernel.org/r/20230619150408.8468-2-manivannan.sadhasivam@linaro.org Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Pieralisi Cc: