The mux implementation is no real device with registers and such…it is pnly a dumb switch which reacts on moddef0 gpio and sets another gpio which switches the serdes lanes in hardware. So you cannot read much except gpio states.
frank-w — confirmed with hard data, this is exactly it.
Decoded the devicetree reset-gpio mapping:
ethernet-phy@24(MDIO 0x18, the healthy mxl_lan5) → GPIO local pin 0x53=83 → global gpio-595ethernet-phy@28(MDIO 0x1c, our broken eth1) → GPIO local pin 0x52=82 → global gpio-594
Cross-referencing with the debugfs GPIO dump:
gpio-594 (PHY reset) out lo ACTIVE LOW ← eth1's AS21xxx — RESET ASSERTED
gpio-595 (PHY reset) out hi ACTIVE LOW ← mxl_lan5's AS21xxx — reset released, working fine
So eth1’s PHY chip is sitting in hardware reset. That explains everything — zeroed SerDes regs, intermittent IPC (probably just enough leaking through for firmware version to answer from some latched/cached state), no amount of OS-level reboot or aeon_normal_retrain fixing it, since the chip itself isn’t even out of reset.
What I still don’t understand: I did a full power-off (10 min, module removed) and gpio-594 still comes back asserted after boot. Is this GPIO driven by:
- A boot-time default in the pinctrl/DT setup that’s wrong for this specific board revision, or
- Some sequencing in the mux/reset driver that’s supposed to release it after detecting the module (via moddef0) but isn’t doing so anymore because of some other state I broke earlier (the failed
unbind)?
If it’s (2), is there a way to manually drive gpio-594 high from userspace to test (e.g. via /sys/class/gpio or gpioset) to confirm the chip comes alive once released, without risking anything? Or is manually toggling this GPIO something that could conflict with the mux_poll logic and cause more harm than good?