On Mon, Feb 28, 2022 at 12:01 PM Tim Harvey <thar...@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. > > 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