On 2/20/2024 6:05 AM, Andrew Lunn wrote:
It's not MAC which behaves wrongly, it's the MDIO bus. If we don't follow
the reset procedure properly. The MDIO bus fails to respond to any
write/read commands. But i believe MAC controller and PHY are still working.
I recalled that it can still transfer network packets, though it fails to
read PHY registers from MDIO bus so only 10Mbps is available (And the phy id
read out is always 0x0, normally it's 0x20669853).
Maybe during initialization, PHY sent some garbage to MDIO bus and killed
it.
MDIO bus masters are really simple things, not much more than a shift
register. I find it hard to believe the MDIO bus master breaks because
of reset order. If the MDIO pins went to SoC pins, it would be simple
to prove, a bus-pirate or similar can capture the signals and sigrok
can decode MDIO.
To me, its more likely the PHY side of the MDIO bus is broken somehow.
The MDIO pins are not accessible from outside, only PHY pins are exported.
Maybe. I've tried many different approaches before i sent this patch.
This is almost the only simple way i can implement to make it work. The
downstream is also not telling us why it is needed to disable MAC
controller before PHY reset. But it is mandatory. All i can do is to
guess, unless HiSilicon people can join this conversion and tell us why.
So the conclusion i got from trial and error is that MAC controller MUST
be disabled during PHY reset, no matter what the reason is. I hope we
can have the framework providing utilities for me to resolve this (e.g.
provide a custom callback for PHY reset, in mdio_device_reset() function).
Also it's very strange that, if the PHY is reset in a wrong order, (i.e.
Now we can not operate MDIO bus), we have to do the PHY reset procedure
once again, simply resetting MAC does not work. So it might also be the
PHY which is broken (partially).
Andrew
--
Regards,
Yang Xiwen
