> On Mon, Feb 28, 2022 at 12:01 PM Tim Harvey <[email protected]> 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
