phy_connect_dev calling phy_reset???

[Michael Walle]

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