On Mon, Feb 28, 2022 at 12:01 PM Tim Harvey tharvey@gateworks.com wrote:
Greetings,
I'm wondering if it is proper in U-Boot for phy_connect_dev() to always call phy_reset() which generates a soft reset via BMCR_RESET.
FWIW, a PHY might also get a hardware reset prior to probing in eth_phy_pre_probe() if the device tree contains a reset gpio line.
-michael
For some (or most?) PHY's this resets specific PHY config such as RGMII delays and LED configuration that may have been configured by firmware running prior to U-Boot (SPL/TPL).
I believe there was some discussion and thrash about this in the Linux kernel in the past and while I can't find the discussion or patches I see that for the current kernel BMCR_RESET is in genphy_soft_reset which() is not called in the generic phy_connect() but instead only called by a handful of phy drivers which I would expect is ok as those phy drivers would also be re-configuring the PHY.
Specifically I have an issue with this with a board that has custom firmware code that runs prior to U-Boot and the BMCR reset is undoing specific PHY config that I've done in this firmware causing me to look at implementing PHY drivers in U-Boot that otherwise would not be needed.
Joe and Ramon,
Do you have any comment on removing the call to phy_reset in phy_connect_dev? Linux delegates calling genphy_soft_reset to the phy drivers that need to whereas U-Boot seems to take the opposite approach requireing a phy driver to set PHY_FLAG_BROKEN_RESET to skip the reset. I think U-Boot should follow Linux and not perform a reset without a PHY driver specifically needing it.
Best regards,
Tim