The clocks for qcom-ethqos return a rate of zero as firmware manages their rate. According to hardware documentation, the clock which is fed to the slave AHB interface can crange between 50 and 100MHz. Currently, stmmac uses an undefined divisor value. Instead, use STMMAC_CSR_60_100M which will mean we meet IEEE 802.3 specification since this will generate between a 1.19MHz and 2.38MHz MDC clock for this range. Add a comment describing this. Link: https://lore.kernel.org/r/acGhQ0oui+dVRdLY@oss.qualcomm.com Signed-off-by: Russell King (Oracle) --- This likely needs the qcom-ethqos 15 patch cleanup series. I think this is what's needed to fix the MDC clocking issue. Please review and test. Thanks. drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c index ad3a983d2a08..ac7d6d3e205a 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c @@ -764,6 +764,12 @@ static int qcom_ethqos_probe(struct platform_device *pdev) qcom_ethqos_set_sgmii_loopback(ethqos, true); ethqos_set_func_clk_en(ethqos); + /* The clocks are controlled by firmware, so we don't know for certain + * what clock rate is being used. Hardware documentation mentions that + * the AHB slave clock will be in the range of 50 to 100MHz, which + * equates to a MDC between 1.19 and 2.38MHz. + */ + plat_dat->clk_csr = STMMAC_CSR_60_100M; plat_dat->bsp_priv = ethqos; plat_dat->set_clk_tx_rate = ethqos_set_clk_tx_rate; plat_dat->dump_debug_regs = rgmii_dump; -- 2.47.3