[PATCH 1/1] net: phy: Do not do CL22 phy reset before ethernet phy driver probe

[Marek Vasut]

On 10/26/25 4:43 PM, Tom Rini wrote:
> On Tue, Aug 05, 2025 at 08:00:29PM +0200, Paul Kocialkowski wrote:
>> Hi,
>>
>> Le Mon 14 Oct 24, 10:43, Marek Vasut a écrit :
>>> On 10/14/24 9:06 AM, Sky Huang wrote:
>>>> From: "SkyLake.Huang" <skylake.huang at mediatek.com>
>>>>
>>>> Remove unnecessary CL22 phy reset before ethernet phy driver
>>>> probe. Lots of ethernet phys requires driver to load firmware.
>>>> Before that, CL22 phy reset may lead to malfunction.
>>>>
>>>> Signed-off-by: SkyLake.Huang <skylake.huang at mediatek.com>
>>>> ---
>>>>    drivers/net/phy/phy.c | 2 --
>>>>    1 file changed, 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>>>> index 716a1d46111..e6fed8c41d7 100644
>>>> --- a/drivers/net/phy/phy.c
>>>> +++ b/drivers/net/phy/phy.c
>>>> @@ -839,8 +839,6 @@ struct phy_device *phy_find_by_mask(struct mii_dev *bus, uint phy_mask)
>>>>    static void phy_connect_dev(struct phy_device *phydev, struct udevice *dev,
>>>>    			    phy_interface_t interface)
>>>>    {
>>>> -	/* Soft Reset the PHY */
>>>> -	phy_reset(phydev);
>>>>    	if (phydev->dev && phydev->dev != dev) {
>>>>    		printf("%s:%d is connected to %s.  Reconnecting to %s\n",
>>>>    		       phydev->bus->name, phydev->addr,
>>>
>>> This needs clarification and likely has to be handled differently. Removing
>>> the reset would leave the PHY in potentially undefined state.
>>>
>>> Which PHY is affected by this ?
>>
>> Good hunch. I just bisected down to this commit as I had some issues with my
>> Allwinner V3 board using the internal CL22 PHY. The symptom is that the LEDS's
>> polarity was inverted. Network still seems to work (although not tested beyond
>> ping).
>>
>> This change can have very significant consequences in general, which were not
>> explored at all in the commit. This may break many boards that do rely on that
>> PHY reset, in various scenarios and for various reasons.
>>
>> I think it should be reverted as soon as possible to restore previous behavior.
> 
> I'm wondering if anyone has further comments here? If I do go and revert
> this what is then going to break on the MediaTek side for example?
Let's revert it, and if MTK stuff breaks, let's fix it properly then.