On 3/19/26 10:24 AM, Russell King (Oracle) wrote:

On Thu, Mar 19, 2026 at 12:35:58AM +0000, Russell King (Oracle) wrote:

quoted

On Thu, Mar 19, 2026 at 03:42:05AM +0530, Mohd Ayaan Anwar wrote:

quoted

[    8.650486] qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00 exceeds mask 0x00000f00), truncating

Please look into this first - with the MDIO bus operating at
who-knows-what frequency, this could make reading from the PHY
unreliable.

My guess is clk_get_rate(priv->plat->stmmac_clk) is returning zero,
which means we don't know the rate of the CSR clock.

From what I can see in drivers/clk/qcom/gcc-qcs404.c and
drivers/clk/qcom/gcc-sdx55.c, this looks like this case - the
struct clk_branch makes no mention of any clock rate, nor does it
have any parent. From what I can see, neither of these drivers
specify any rates for any of their clocks, which likely means that
clk_get_rate() will be zero for all of them.

Sadly, when I designed the clk API, I didn't think that people would
be stupid enough not to implement the API properly, more fool me.

Under the old code, we would've used STMMAC_CSR_20_35M, which means
we're assuming that the CSR clock is between 20 and 35MHz, even
though the value is zero. Is that the case? If it's higher than
35MHz, then you've been operating the MDIO bus out of IEEE 802.3
specification, which can make PHY access unrealible.

In any case, please fix your clock drivers.

I'm not 100% sure the currently-passed AXI clock is what we want
there and the docs aren't super helpful.. is there a synopsys-name
for it? What rates would you expect it to run at?

Konrad