netdev - Re: [PATCH net] net: phy: smsc: Skip soft reset when a hardware reset GPIO is provided

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOMZO5AsTFLL+Q6qwwi+eftb4ZpVnrmX5rLTz9n5gUhhf26B7A@mail.gmail.com>
Date: Sun, 16 Nov 2025 19:11:14 -0300
From: Fabio Estevam <festevam@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: kuba@...nel.org, andrew@...n.ch, hkallweit1@...il.com, 
	manfred.schlaegl@...zinger.com, netdev@...r.kernel.org, edumazet@...gle.com, 
	pabeni@...hat.com, f.fainelli@...il.com
Subject: Re: [PATCH net] net: phy: smsc: Skip soft reset when a hardware reset
 GPIO is provided

On Sun, Nov 16, 2025 at 2:08 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:

> > +             /* reset the phy */
>
> This would be a more useful comment here:
>
>                 /* The LAN7820 datasheet states that a soft reset causes
>                  * the PHY to reconfigure according to the MODE bits in
>                  * MII_LAN83C185_SPECIAL_MODES. Thus, a soft reset is
>                  * necessary for the above write to take effect.
>                  */
>
> Please also insert a blank line prior to the comment to make the code
> more readable.

Thanks, this is much better indeed.

>
> > +             return genphy_soft_reset(phydev);
> >       }
> >
> > -     /* reset the phy */
> > +     /* If the reset-gpios property exists, hardware reset will be
> > +      * performed by the MDIO core, so do NOT issue a soft reset here.
> > +      */
> > +     if (priv->reset_gpio)
> > +             return 0;
>
> Have you tried adding a 1ms delay before the soft reset, in case the
> hard reset hasn't completed?

I can try it. Actually, I don't have physical access to the board, so
I need to ask someone to test it for me.

> As Andrew's feedback states to the thread that we were discussing it
> (and now we have a forked discussion which is far from ideal) we
> still don't know "why" the PHY is failing, and without knowing why,
> we don't know whether someone else will run into the same issue and
> end up patching the kernel in a different way (e.g. the network
> driver.)

It seems that it is the i.MX6Q MAC that is failing, not the LAN8720.

After the hardware reset via GPIO, the LAN8720 generates a stable
50MHz clock to the i.MX6Q ENET_REF_CLK pin.

After the software reset is triggered, the following happens as per
the LAN8720 datasheet:

"For the first 16us after coming out of reset, the RMII interface will
run at 2.5 MHz. After this time, it will switch
to 25 MHz if auto-negotiation is enabled."

This glitch in the ENET_REF_CLK confuses the MAC, causing CRC and packet loss.

That's why avoiding the software reset in the case the LAN8720 is
driving the clock to i.MX6Q helps.