netdev - Re: LAN8720: RX errors / packet loss when using smsc PHY driver on i.MX6Q

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOMZO5DfK1kxhtbYR3bDbwinpCKotBgHnY-B+YUknnHivUPYDA@mail.gmail.com>
Date: Sat, 15 Nov 2025 21:57:20 -0300
From: Fabio Estevam <festevam@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Heiner Kallweit <hkallweit1@...il.com>, edumazet <edumazet@...gle.com>, 
	netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>
Subject: Re: LAN8720: RX errors / packet loss when using smsc PHY driver on i.MX6Q

On Sat, Nov 15, 2025 at 6:37 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:

> What happens if you replace this with genphy_soft_reset() ?

Packet loss is also observed.

> Is the hardware reset signal wired on this PHY, and does the kernel
> control the hardware reset?

Yes, there is an i.MX6Q GPIO that is connected to the LAN8720 reset pin.

> I note that phy_init_hw() will deassert the hardware reset, and with
> .soft_reset populated, we will immediately thump the PHY with a
> soft reset unless a reset_deassert_delay is specified (e.g. via DT
> reset-deassert-us prioerty). This is probably not a good idea if the
> PHY is still recovering from hardware reset.

The original dts had the PHY reset described in the FEC node:

&fec {
      phy-reset-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
      phy-reset-duration = <100>;

I have also tried describing it inside the ethernet-phy node with:
reset-assert-us; reset-deassert-us; and reset-gpios, but it did not help.

I agree that the combination of a software reset and hardware may be
causing the issue here.

> For reference, LAN8720 requires a minimum period of 100µs for hardware
> reset assertion, and then between 2 and 800ns before the PHY starts
> driving the configuration pin outputs. This _probably_ (it's not
> specified) means we shouldn't be talking to the PHY for approx. the
> first 1µs.
>
> Finally, and this is probably not relevant given that the PHY works
> with the genphy driver, the PHY requires the XTAL1/CLKIN to be running
> during a hardware reset.

A 25MHz oscillator is connected to XTAL1 and XTAL2.

Thanks