From: Wenbin Yao <quic_wenbyao@xxxxxxxxxxx>
[ 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@xxxxxxxxxxx>
Signed-off-by: Qiang Yu <quic_qianyu@xxxxxxxxxxx>
Signed-off-by: Wenbin Yao <quic_wenbyao@xxxxxxxxxxx>
[mani: subject change]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx>
[bhelgaas: update PCIe spec citation, format quote]
Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
Tested-by: Niklas Cassel <cassel@xxxxxxxxxx>
Link: https://patch.msgid.link/20250422103623.462277-1-quic_wenbyao@xxxxxxxxxxx
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
**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@xxxxxxxxxx>`
- **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 97d76d3dc066e..be348b341e3cf 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -797,22 +797,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);
--
2.39.5
