Failed to reinit phy of spacemit-dwmac when reset-gpio is present
Inochi Amaoto
inochiama at gmail.com
Sat Jul 11 21:52:33 PDT 2026
TL;DR:
The DWMAC on Spacemit K3 is failled to register phy after the reload
the driver module (rmmod then insmod). Because the reset-gpio is
asserted while unloading the driver and is not desserted before reading
the c22 id, which leads to a fault.
Description
In a few days ago, E Shattow reports he has sufferred the a weird issue,
when unloading the spacemit-dwmac driver and then reloading it, he got
the following error:
[ 60.713071] mdio_bus stmmac-0: MDIO device at address 1 is missing.
This only occurs when reloading the driver but the first initialization
successed. After some function tracking, I found it is failed at reading
c22 id. The call graph is as the follows:
stmmac_mdio_register
mdiobus_alloc
of_mdiobus_register
__of_mdiobus_register
__mdiobus_register
__of_mdiobus_parse_phys
of_mdiobus_child_is_phy
of_mdiobus_register_phy
fwnode_mdiobus_register_phy
get_phy_device
get_phy_c22_id
By checking the difference between the initialization process and the
reloading process, I found the reset gpio is asserted in the function
mdiobus_unregister(). And there is no any function desserted this reset
gpio in the loading stage. And in the initialization process, the reset
goio is deasserted.
This bug report is sent as I found it is hard to solve this problem
and ask for help to fix this issue as it is related to the framework
instead of a specific driver.
The possible workaround I found is as the following, just use the phy
id in the compatible string (Confirmed by dlan):
---
--- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
+++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
@@ -196,7 +196,8 @@ ð0 {
mdio {
phy0: phy at 1 {
- compatible = "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id001c.c916",
+ "ethernet-phy-ieee802.3-c22";
reg = <1>;
reset-gpios = <&gpio 0 15 GPIO_ACTIVE_LOW>;
reset-assert-us = <10000>;
---
An interesting thing is, moving the reset-gpio to the MDIO bus level
does not solve this problem. Only setting the right phy id can mitigate
the problem.
Regards,
Inochi
More information about the linux-riscv
mailing list