linux-stable.git/drivers/pci/controller, branch linux-6.16.y

PCI: mvebu: Fix use of for_each_of_range() iterator

2025-09-19T14:37:35+00:00

[ Upstream commit b816265396daf1beb915e0ffbfd7f3906c2bf4a4 ]

5da3d94a23c6 ("PCI: mvebu: Use for_each_of_range() iterator for parsing
"ranges"") simplified code by using the for_each_of_range() iterator, but
it broke PCI enumeration on Turris Omnia (and probably other mvebu
targets).

Issue #1:

To determine range.flags, of_pci_range_parser_one() uses bus->get_flags(),
which resolves to of_bus_pci_get_flags(), which already returns an
IORESOURCE bit field, and NOT the original flags from the "ranges"
resource.

Then mvebu_get_tgt_attr() attempts the very same conversion again.  Remove
the misinterpretation of range.flags in mvebu_get_tgt_attr(), to restore
the intended behavior.

Issue #2:

The driver needs target and attributes, which are encoded in the raw
address values of the "/soc/pcie/ranges" resource. According to
of_pci_range_parser_one(), the raw values are stored in range.bus_addr and
range.parent_bus_addr, respectively. range.cpu_addr is a translated version
of range.parent_bus_addr, and not relevant here.

Use the correct range structure member, to extract target and attributes.
This restores the intended behavior.

Fixes: 5da3d94a23c6 ("PCI: mvebu: Use for_each_of_range() iterator for parsing "ranges"")
Reported-by: Jan Palus 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220479
Signed-off-by: Klaus Kudielka 
Signed-off-by: Bjorn Helgaas 
Tested-by: Tony Dinh 
Tested-by: Jan Palus 
Link: https://patch.msgid.link/20250907102303.29735-1-klaus.kudielka@gmail.com
Signed-off-by: Sasha Levin

PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up

2025-08-28T14:34:41+00:00

commit 80dc18a0cba8dea42614f021b20a04354b213d86 upstream.

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 
Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Damien Le Moal 
Reviewed-by: Wilfred Mallawa 
Link: https://patch.msgid.link/20250625102347.1205584-14-cassel@kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Set Target Link Speed to 5.0 GT/s before retraining

2025-08-28T14:34:37+00:00

[ Upstream commit 114b06ee108cabc82b995fbac6672230a9776936 ]

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 
[mani: fixed whitespace warning, commit message rewording, added fixes tag]
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Bjorn Helgaas 
Tested-by: Robin Murphy 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/0afa6bc47b7f50e2e81b0b47d51c66feb0fb565f.1751322015.git.geraldogabriel@gmail.com
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Use standard PCIe definitions

2025-08-28T14:34:37+00:00

[ Upstream commit cbbfe9f683f0f9b6a1da2eaa53b995a4b5961086 ]

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 
Signed-off-by: Geraldo Nascimento 
[mani: commit message rewording]
Signed-off-by: Manivannan Sadhasivam 
[bhelgaas: include bitfield.h]
Signed-off-by: Bjorn Helgaas 
Link: https://patch.msgid.link/e81700ef4b49f584bc8834bfb07b6d8995fc1f42.1751322015.git.geraldogabriel@gmail.com
Stable-dep-of: 114b06ee108c ("PCI: rockchip: Set Target Link Speed to 5.0 GT/s before retraining")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Delay link start until configfs 'start' written

2025-08-28T14:34:25+00:00

commit 2e6ea70690ddd1ffa422423fd0d4523e4dfe4b62 upstream.

According to Documentation/PCI/endpoint/pci-endpoint-cfs.rst, the Endpoint
controller (EPC) should only start the link when userspace writes '1' to
the '/sys/kernel/config/pci_ep/controllers//start' attribute, which
ultimately results in calling imx_pcie_start_link() via
pci_epc_start_store().

To align with the documented behavior, do not start the link automatically
when adding the EP controller.

Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support")
Signed-off-by: Richard Zhu 
[mani: reworded commit subject and description]
Signed-off-by: Manivannan Sadhasivam 
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Frank Li 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250709033722.2924372-3-hongxing.zhu@nxp.com
Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Remove apps_reset toggling from imx_pcie_{assert/deassert}_core_reset

2025-08-28T14:34:25+00:00

commit d31eb217425591e100b475fad6360cd3da2073c6 upstream.

apps_reset corresponds to LTSSM_EN in i.MX7, i.MX8MQ, i.MX8MM and i.MX8MP
platforms. Since assertion/de-assertion of apps_reset is done in
imx_pcie_ltssm_enable() and imx_pcie_ltssm_disable(), remove it from
imx_pcie_assert_core_reset() and imx_pcie_deassert_core_reset().

This also fixes a failure in enumerating the PI7C9X2G608GP (hotplug) chip
reliably on i.MX8MM, as reported by Tim.

It should be noted that only i.MX7D, i.MX8MQ, i.MX8MM, and i.MX8MP
platforms have the apps_reset logic, so this change doesn't have any effect
on other platforms.

Fixes: ef61c7d8d032 ("PCI: imx6: Deassert apps_reset in imx_pcie_deassert_core_reset()")
Reported-by: Tim Harvey 
Closes: https://lore.kernel.org/all/CAJ+vNU3ohR2YKTwC4xoYrc1z-neDoH2TTZcMHDy+poj9=jSy+w@mail.gmail.com/
Signed-off-by: Richard Zhu 
[mani: reworded commit subject and description]
Signed-off-by: Manivannan Sadhasivam 
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas 
Tested-by: Tim Harvey  # imx8mp-venice-gw74xx (i.MX8MP + hotplug capable switch)
Reviewed-by: Frank Li 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250709033722.2924372-2-hongxing.zhu@nxp.com
Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Add IMX8MM_EP and IMX8MP_EP fixed 256-byte BAR 4 in epc_features

2025-08-28T14:34:25+00:00

commit 399444a87acdea5d21c218bc8e9b621fea1cd218 upstream.

For IMX8MM_EP and IMX8MP_EP, add fixed 256-byte BAR 4 and reserved BAR 5
in imx8m_pcie_epc_features.

Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support")
Signed-off-by: Richard Zhu 
[bhelgaas: add details in subject]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Frank Li 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250708091003.2582846-3-hongxing.zhu@nxp.com
Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Add IMX8MQ_EP third 64-bit BAR in epc_features

2025-08-28T14:34:25+00:00

commit c523fa63ac1d452abeeb4e699560ec3365037f32 upstream.

IMX8MQ_EP has three 64-bit BAR0/2/4 capable and programmable BARs. For
IMX8MQ_EP, use imx8q_pcie_epc_features (64-bit BARs 0, 2, 4) instead
of imx8m_pcie_epc_features (64-bit BARs 0, 2).

Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support")
Signed-off-by: Richard Zhu 
[bhelgaas: add details in subject]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Frank Li 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250708091003.2582846-2-hongxing.zhu@nxp.com
Signed-off-by: Greg Kroah-Hartman

PCI: dw-rockchip: Delay link training after hot reset in EP mode

2025-08-20T16:41:26+00:00

[ Upstream commit c0b93754547dde16c8370b8fdad5f396e7786647 ]

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 
Signed-off-by: Wilfred Mallawa 
Signed-off-by: Niklas Cassel 
Signed-off-by: Manivannan Sadhasivam 
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas 
Link: https://patch.msgid.link/20250613101908.2182053-2-cassel@kernel.org
Signed-off-by: Sasha Levin

PCI: qcom: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQ

2025-08-15T14:39:01+00:00

[ Upstream commit 15b6b243cc2b1017cf89e2477aa0b4e1a306a82a ]

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 
Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Damien Le Moal 
Reviewed-by: Wilfred Mallawa 
Link: https://patch.msgid.link/20250625102347.1205584-13-cassel@kernel.org
Signed-off-by: Sasha Levin