From: Wenbin Yao quic_wenbyao@quicinc.com
[ Upstream commit af3c6eacce0c464f28fe0e3d365b3860aba07931 ]
As per DWC PCIe registers description 4.30a, section 1.13.43, NUM_OF_LANES named as PORT_LOGIC_LINK_WIDTH in PCIe DWC driver, is referred to as the "Predetermined Number of Lanes" in PCIe r6.0, sec 4.2.7.2.1, which explains the conditions required to enter Polling.Configuration:
Next state is Polling.Configuration after at least 1024 TS1 Ordered Sets were transmitted, and all Lanes that detected a Receiver during Detect receive eight consecutive training sequences ...
Otherwise, after a 24 ms timeout the next state is:
Polling.Configuration if,
(i) Any Lane, which detected a Receiver during Detect, received eight consecutive training sequences ... and a minimum of 1024 TS1 Ordered Sets are transmitted after receiving one TS1 or TS2 Ordered Set.
And
(ii) At least a predetermined set of Lanes that detected a Receiver during Detect have detected an exit from Electrical Idle at least once since entering Polling.Active.
Note: This may prevent one or more bad Receivers or Transmitters from holding up a valid Link from being configured, and allow for additional training in Polling.Configuration. The exact set of predetermined Lanes is implementation specific.
Note: Any Lane that receives eight consecutive TS1 or TS2 Ordered Sets should have detected an exit from Electrical Idle at least once since entering Polling.Active.
In a PCIe link supporting multiple lanes, if PORT_LOGIC_LINK_WIDTH is set to lane width the hardware supports, all lanes that detect a receiver during the Detect phase must receive eight consecutive training sequences. Otherwise, LTSSM will not enter Polling.Configuration and link training will fail.
Therefore, always set PORT_LOGIC_LINK_WIDTH to 1, regardless of the number of lanes the port actually supports, to make link up more robust. This setting will not affect the intended link width if all lanes are functional. Additionally, the link can still be established with at least one lane if other lanes are faulty.
Co-developed-by: Qiang Yu quic_qianyu@quicinc.com Signed-off-by: Qiang Yu quic_qianyu@quicinc.com Signed-off-by: Wenbin Yao quic_wenbyao@quicinc.com [mani: subject change] Signed-off-by: Manivannan Sadhasivam manivannan.sadhasivam@linaro.org [bhelgaas: update PCIe spec citation, format quote] Signed-off-by: Bjorn Helgaas bhelgaas@google.com Tested-by: Niklas Cassel cassel@kernel.org Link: https://patch.msgid.link/20250422103623.462277-1-quic_wenbyao@quicinc.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## **Primary Justification for Backporting**
**1. Critical Reliability Fix** The commit addresses a fundamental PCIe link training robustness issue in DesignWare (DWC) PCIe controllers. The core problem is that when `PORT_LOGIC_LINK_WIDTH` is set to match the actual lane count (2, 4, or 8 lanes), ALL lanes must receive eight consecutive training sequences during the Polling.Active phase to transition to Polling.Configuration. If any single lane has poor signal integrity or is faulty, the entire link training fails.
**2. Minimal Risk, High Reward Change** The code change is surgically precise: ```c lwsc &= ~PORT_LOGIC_LINK_WIDTH_MASK; +lwsc |= PORT_LOGIC_LINK_WIDTH_1_LANES; // Always set to 1 lane ```
The fix removes lane-specific `PORT_LOGIC_LINK_WIDTH` assignments from the switch statement while preserving `PORT_LINK_MODE` settings. This maintains full functionality for working configurations while improving robustness for marginal hardware.
**3. Standards-Compliant Solution** The fix is based on official PCIe specification guidance (PCIe r6.0, Section 4.2.7.2.1) regarding "Predetermined Number of Lanes" and follows DWC hardware manual recommendations (DWC PCIe registers 4.30a, Section 1.13.43).
## **Technical Analysis Supporting Backporting**
**Comparison with Historical Similar Commits:**
Looking at the provided examples, this commit closely resembles **Similar Commit #1** and **Similar Commit #3** (both marked YES for backporting):
- **Similar to Commit #1**: Both fix hardware capability exposure issues in DWC PCIe controllers - **Similar to Commit #3**: Both address link training problems with clear technical justification and minimal code changes - **Unlike Commit #2**: This is not a vendor-specific workaround but a general robustness improvement - **Unlike Commit #5**: This doesn't remove functionality but enhances reliability
**Code Quality Indicators:** - **Well-tested**: Includes `Tested-by: Niklas Cassel cassel@kernel.org` - **Vendor-originated**: Comes from Qualcomm engineers with deep DWC hardware knowledge - **Maintainer-approved**: Processed through standard PCIe subsystem review (Manivannan Sadhasivam → Bjorn Helgaas)
## **Backporting Risk Assessment**
**Low Risk Factors:** 1. **No architectural changes**: Only modifies initialization values 2. **Backwards compatible**: Working configurations continue to function normally 3. **No new features**: Pure reliability enhancement 4. **Isolated scope**: Changes only affect `dw_pcie_link_set_max_link_width()` function 5. **No external dependencies**: Self-contained change
**Benefits Analysis:** 1. **Broad applicability**: Affects all DWC PCIe implementations (Qualcomm, Rockchip, i.MX, Samsung, etc.) 2. **Field-proven improvement**: Addresses real-world link training failures 3. **Future-proof**: Aligns with PCIe specification best practices 4. **Progressive enhancement**: Improves marginal hardware without affecting good hardware
## **Stable Tree Criteria Compliance**
This commit meets all stable tree requirements: - ✅ **Important bugfix**: Resolves link training failures - ✅ **Minimal risk**: Small, well-understood change - ✅ **No new features**: Pure reliability improvement - ✅ **Contained subsystem**: Limited to DWC PCIe controller logic - ✅ **Clear problem statement**: Based on PCIe specification requirements
## **Conclusion**
This commit represents an exemplary backport candidate that enhances PCIe link training robustness across all DWC-based platforms without introducing regression risk. The technical approach is sound, the implementation is minimal, and the benefit is broad. It should be backported to LTS kernels and any stable branches supporting DWC PCIe controllers.
drivers/pci/controller/dwc/pcie-designware.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c index 2b60d20dfdf59..717af1b757f0a 100644 --- a/drivers/pci/controller/dwc/pcie-designware.c +++ b/drivers/pci/controller/dwc/pcie-designware.c @@ -748,22 +748,19 @@ static void dw_pcie_link_set_max_link_width(struct dw_pcie *pci, u32 num_lanes) /* Set link width speed control register */ lwsc = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL); lwsc &= ~PORT_LOGIC_LINK_WIDTH_MASK; + lwsc |= PORT_LOGIC_LINK_WIDTH_1_LANES; switch (num_lanes) { case 1: plc |= PORT_LINK_MODE_1_LANES; - lwsc |= PORT_LOGIC_LINK_WIDTH_1_LANES; break; case 2: plc |= PORT_LINK_MODE_2_LANES; - lwsc |= PORT_LOGIC_LINK_WIDTH_2_LANES; break; case 4: plc |= PORT_LINK_MODE_4_LANES; - lwsc |= PORT_LOGIC_LINK_WIDTH_4_LANES; break; case 8: plc |= PORT_LINK_MODE_8_LANES; - lwsc |= PORT_LOGIC_LINK_WIDTH_8_LANES; break; default: dev_err(pci->dev, "num-lanes %u: invalid value\n", num_lanes);