On Mon, Mar 30, 2026 at 01:18:56PM +0200, Konrad Dybcio wrote:

On 3/27/26 6:02 PM, Russell King (Oracle) wrote:

quoted

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.

FWIW this __may__ possibly differ between platforms, but I'm not sure
to what degree. Will there be visible impact if we e.g. have a 200 or
300 MHz clock somewhere?

When you add other platforms, you're going to have to deal with their
differences.

IEEE 802.3 states that the maximum clock rate for the MDIO bus is
2.5MHz. You need to ensure that is the case.

Current qcom-ethqos code doesn't set clk_csr, and returns zero for
clk_get_rate() on the stmmac clocks because they are managed entirely
in firmware.

This leads to the GMII_Address register field CR "CSR Clock Range"
being programmed with a value of 15, which, according to some
documentation, states that the clock divisor is CSR clock / 18.

With the /18 divisor (assuming your dwmac uses that divisor):

CSR clock	MDIO MDC clock rate
50MHz		2.78MHz (exceeds IEEE 802.3 maximum)
100MHz		5.56MHz (exceeds IEEE 802.3 maximum)
200MHz		11.1MHz (exceeds IEEE 802.3 maximum)
300MHz		16.7MHz (exceeds IEEE 802.3 maximum)

Do you think this is acceptable, or do you think this should be
fixed before anything else happens with the driver?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!