IQ-9075 EVK ethernet stays NO-CARRIER on qcom-next (7.2 and 7.3-rc2): qca808x only advertises 2500baseT

[ricardosalveti]

Summary

On qcom-next the IQ-9075 EVK ethernet port (23040000.ethernet, QCA8081 PHY, phy-mode = "2500base-x") never gets a link against a 1G link partner: ethtool end0 shows Advertised link modes: 2500baseT/Full only, so autonegotiation with a 10/100/1000 switch cannot succeed. qcom-6.18.y on the same board autonegotiates 1Gbps/Full a few seconds after boot.

Downstream report: qualcomm-linux/meta-qcom#3200. That report had two parts; the first (missing at24/qca808x kernel modules in images that don't install every module) is a meta-qcom packaging bug fixed by qualcomm-linux/meta-qcom#3208 and affects 6.18 and 7.x alike. This issue is about the second part, which is kernel side and 7.x only.

Affected trees

tree	commit	result
qcom-6.18.y	b6e015a3cb19 (tag qcom-6.18.y-20260914)	link up, autoneg 1Gbps/Full
qcom-next 7.2	d49c33864d06 (tag qcom-next-7.2-20260826)	NO-CARRIER, advertises 2500baseT only
qcom-next 7.3-rc2	8f69c5810aa3 (tag qcom-next-7.3-rc2-20260921, proposed in qualcomm-linux/meta-qcom#3203)	same PHY/MAC code as 7.2, not booted yet

Same board, same nodistro image apart from the kernel, same test sequence. Independent of the boot firmware: reproduced with the Qualcomm UEFI stack, the TF-A/FIP open-firmware flow and the U-Boot SPL flow.

Root cause

qcom-6.18.y carries

3f4a09a1ad2f FROMLIST: net: phy: qcom: qca808x: Add .get_rate_matching support

merged via #252. It returns RATE_MATCH_PAUSE for PHY_INTERFACE_MODE_2500BASEX, so phylink stops restricting the PHY's advertisement to link modes reachable over a fixed 2500BASE-X SerDes; its commit message shows exactly this before/after. That commit is not in qcom-next 7.2 nor in the 7.3-rc2 tag, and nothing equivalent is. git merge-tree shows it cherry-picks with zero conflicts onto both.

Upstream it was rejected (netdev, changes-requested, no v2 posted): https://lore.kernel.org/netdev/20250914-qca808x_rate_match-v1-1-0f9e6a331c3b@oss.qualcomm.com/

Russell King's point: the QCA8081 does not rate-match, it switches its SerDes between SGMII (<= 1G) and 2500BASE-X, so the patch only makes ethtool claim the lower speeds. It works in practice on 6.18 because dwmac-qcom-ethqos already reprograms the SerDes per negotiated speed (ethqos_fix_mac_speed_sgmii + ethqos_pcs_set_inband), and Mohd Ayaan Anwar (@ayaan-anwar) confirmed 1G and 2.5G both worked in the thread.

The upstream-acceptable fix he pointed at is on the MAC side: dwmac-qcom-ethqos should register plat->get_interfaces advertising both SGMII and 2500BASE-X, so phylink validates both and lets the PHY negotiate all speeds. That hook exists in stmmac since ca732e990fc8 ("net: stmmac: add get_interfaces() platform method", in 7.2 and 7.3) and is used by dwmac-intel, dwmac-rk and dwmac-spacemit, but dwmac-qcom-ethqos never sets it. A prototype of that was reported working for 1G and 2.5G in the same thread; nothing has been posted since.

Evidence

qcom-next 7.2, autoneg:

end0: PHY [stmmac-0:1c] driver [Qualcomm QCA8081] (irq=POLL)
end0: configuring for phy/2500base-x link mode
# ethtool end0
    Advertised link modes:  2500baseT/Full
    Auto-negotiation: on
    Link detected: no
# ethtool -r end0                                    -> still no carrier after 25 s
# ethtool -s end0 speed 1000 duplex full autoneg off
end0: Link is Up - 1Gbps/Full - flow control off     -> forcing the speed is the only way; DHCP and ping then work

qcom-6.18.y, same board:

end0: configuring for phy/2500base-x link mode
end0: Link is Up - 1Gbps/Full - flow control off     -> 3 s later, no intervention
# ethtool end0
    Advertised link modes:  10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full
                            1000baseT/Full 2500baseT/Full
    Speed: 1000Mb/s   Auto-negotiation: on   Link detected: yes

Workaround until fixed: ethtool -s end0 speed 1000 duplex full autoneg off.

Note: meta-qcom CI does not catch this because qcom-linux-testkit's ethEnsureLinkUpWithFallback forces 1000/full when autoneg fails; the 7.2 CI logs end with Auto-negotiation: off.

Ask

cc Mohd Ayaan Anwar (@ayaan-anwar) (author of the patch / #252), Salendarsingh Gaud (@sgaud-quic) (merged #252), Shiraz Hashim (@shashim-quic)

Send a v2 and have it in qcom-next.

[sgaud-quic]

Mohd Ayaan Anwar (@ayaan-anwar) please check this..

[ayaan-anwar]

The upstream-acceptable fix he pointed at is on the MAC side: dwmac-qcom-ethqos should register plat->get_interfaces advertising both SGMII and 2500BASE-X, so phylink validates both and lets the PHY negotiate all speeds. That hook exists in stmmac since ca732e9 ("net: stmmac: add get_interfaces() platform method", in 7.2 and 7.3) and is used by dwmac-intel, dwmac-rk and dwmac-spacemit, but dwmac-qcom-ethqos never sets it. A prototype of that was reported working for 1G and 2.5G in the same thread; nothing has been posted since.

Later down the thread, Russell had rejected the get_interfaces solution.

We have an alternate solution for this for which we have been having discussions with Maxime. If it proves to be stable during link speed changes, then we can bring this in:
https://lore.kernel.org/netdev/aqzJkYqRgpBTOB9N@oss.qualcomm.com/

Expecting a conclusion for this by end of this week.

[ricardosalveti]

We have an alternate solution for this for which we have been having discussions with Maxime. If it proves to be stable during link speed changes, then we can bring this in: https://lore.kernel.org/netdev/aqzJkYqRgpBTOB9N@oss.qualcomm.com/

Expecting a conclusion for this by end of this week.

Thanks!