[PATCH 0/2] clk: qcom: ipq6018/ipq8074: keep port 5 on uniphy1 at SGMII rates

["André Valentin" <avalentin@marcant.net>]

On IPQ6018 and IPQ8074, port 5 can be clocked from uniphy1. Its RX and TX
frequency tables offer uniphy1 only for uniphy1 at 312.5 MHz (2500BASE-X).
In SGMII uniphy1 runs at 125 MHz, and a 1G or 100M rate that reaches the
RCG then picks uniphy0, or stays on uniphy1 with the wrong divider. These
two patches add uniphy1 / 1 and uniphy1 / 5, which the port 6 tables of
gcc-ipq8074 already have for uniphy2.

This came out of a review of an OpenWrt fix for QCA8081 egress corruption
on port 5, where the port RCGs were left on the RX clock by the
bootloader [1]. In the sequence I can reproduce there, the rate change
stops at the divider and the RCG keeps its parent, so these entries are
not exercised. They matter wherever a 1G or 100M rate does reach the RCG.

Tested on IPQ6010 (MikroTik Chateau 5G R17 ax, QCA8081 on port 5) with
6.18.55 plus the OpenWrt patches: after link-ups at 2.5G, 1G and 100M both
port 5 RCGs stay on uniphy1 (CFG 0x300) and pass traffic at line rate,
without errors on the port. The IPQ8074 change is build-tested only.

[1] https://github.com/openwrt/openwrt/pull/24566

André Valentin (2):
  clk: qcom: gcc-ipq6018: keep port 5 on uniphy1 at SGMII rates
  clk: qcom: gcc-ipq8074: keep port 5 on uniphy1 at SGMII rates

 drivers/clk/qcom/gcc-ipq6018.c | 4 ++++
 drivers/clk/qcom/gcc-ipq8074.c | 4 ++++
 2 files changed, 8 insertions(+)


base-commit: fa4ad798f6f681031775266044ba1b0cf3c670bd
-- 
2.47.3