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

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

[Fabio Estevam]

Hi,

On a custom i.MX6Q-based board using a LAN8720 PHY, we are observing
consistent packet loss when the LAN8720-specific PHY driver
(drivers/net/phy/smsc.c) is in use.

Kernel versions tested: 6.18-rc4 and 6.12
MAC driver: FEC (i.MX6)
PHY: LAN8720 (RMII) providing the 50 MHz ENET_REF clock to the SoC.

Behavior:

- Packet loss occurs when the LAN8720 is bound to the smsc PHY driver.

- No packet loss when using the generic PHY driver.

- No packet loss when the smsc driver is used and the link is forced
to 10 Mbps using ethtool.

The issue is easily reproduced with:

ping -c 1000 -i 0.2 -s 1300 <board-ip>

The board’s relevant DT fragment:

&fec {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_fec>;

    /* FEC ENET REF clock comes from LAN8720 */
    clocks = <&clks IMX6QDL_CLK_ENET>,
             <&clks IMX6QDL_CLK_ENET>,
             <&clks IMX6QDL_CLK_ENET>,
             <&clks IMX6QDL_CLK_ENET_REF>;
    clock-names = "ipg", "ahb", "ptp", "enet_out";

    phy-mode = "rmii";
    phy-reset-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
    phy-reset-duration = <100>;
    phy-handle = <&ethphy0>;

    mdio {
        #address-cells = <1>;
        #size-cells = <0>;
        status = "okay";

        ethphy0: ethernet-phy@0 {
            reg = <0>;
            compatible = "ethernet-phy-ieee802.3-c22";
            max-speed = <100>;
            smsc,disable-energy-detect;
        };
    };
};

Has anyone seen similar behavior with LAN8720 or the smsc PHY driver
on i.MX platforms?
Any guidance on how to further debug this or what additional
information would be useful is appreciated.

Thanks,

Fabio Estevam

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

[Andrew Lunn]

> Behavior:
> 
> - Packet loss occurs when the LAN8720 is bound to the smsc PHY driver.
> 
> - No packet loss when using the generic PHY driver.

> Any guidance on how to further debug this or what additional
> information would be useful is appreciated.

Maybe dump all 32 registers when genphy and smsc driver are being used
and compare them?

	Andrew

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

[Fabio Estevam]

Hi Andrew,

On Thu, Nov 13, 2025 at 7:35 PM Andrew Lunn <andrew@lunn.ch> wrote:

> Maybe dump all 32 registers when genphy and smsc driver are being used
> and compare them?

The dump of all the 32 registers are identical in both cases:

./mii-diag -vvv
mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Using the default interface 'eth0'.
  Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x3100).
 The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
 Basic mode control register 0x3100: Auto-negotiation enabled.
 You have link beat, and everything is working OK.
   This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 Your link partner advertised cde1: Flow-control 100baseTx-FD
100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
   End of basic transceiver information.

libmii.c:v2.11 2/28/2005  Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
 MII PHY #0 transceiver registers:
   3100 782d 0007 c0f1 05e1 cde1 0009 ffff
   ffff ffff ffff ffff ffff ffff ffff 0000
   0040 0002 60e0 ffff 0000 0000 0000 0000
   ffff ffff 0000 000a 0000 00c8 0000 1058.
 Basic mode control register 0x3100: Auto-negotiation enabled.
 Basic mode status register 0x782d ... 782d.
   Link status: established.
   Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 Vendor ID is 00:01:f0:--:--:--, model 15 rev. 1.
   No specific information is known about this transceiver type.
 I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
   Advertising no additional info pages.
   IEEE 802.3 CSMA/CD protocol.
 Link partner capability is cde1: Flow-control 100baseTx-FD 100baseTx
10baseT-FD 10baseT.
   Negotiation  completed.

After pinging with the Generic PHY driver:

# ethtool -S eth0 | grep error
     tx_crc_errors: 0
     rx_crc_errors: 0
     rx_xdp_tx_errors: 0
     tx_xdp_xmit_errors: 0

After pinging with the SMSC PHY driver:

# ethtool -S eth0 | grep err
     tx_crc_errors: 0
     IEEE_tx_macerr: 0
     IEEE_tx_cserr: 0
     rx_crc_errors: 19
     IEEE_rx_macerr: 0
     rx_xdp_tx_errors: 0
     tx_xdp_xmit_errors: 0

Any ideas?

Thanks

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

[Heiner Kallweit]

On 11/14/2025 10:15 PM, Fabio Estevam wrote:
> Hi Andrew,
> 
> On Thu, Nov 13, 2025 at 7:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
> 
>> Maybe dump all 32 registers when genphy and smsc driver are being used
>> and compare them?
> 
> The dump of all the 32 registers are identical in both cases:
> 
> ./mii-diag -vvv
> mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
> Using the default interface 'eth0'.
>   Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x3100).
>  The autonegotiated capability is 01e0.
> The autonegotiated media type is 100baseTx-FD.
>  Basic mode control register 0x3100: Auto-negotiation enabled.
>  You have link beat, and everything is working OK.
>    This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
>    Able to perform Auto-negotiation, negotiation complete.
>  Your link partner advertised cde1: Flow-control 100baseTx-FD
> 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
>    End of basic transceiver information.
> 
> libmii.c:v2.11 2/28/2005  Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
>  MII PHY #0 transceiver registers:
>    3100 782d 0007 c0f1 05e1 cde1 0009 ffff
>    ffff ffff ffff ffff ffff ffff ffff 0000
>    0040 0002 60e0 ffff 0000 0000 0000 0000
>    ffff ffff 0000 000a 0000 00c8 0000 1058.
>  Basic mode control register 0x3100: Auto-negotiation enabled.
>  Basic mode status register 0x782d ... 782d.
>    Link status: established.
>    Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
>    Able to perform Auto-negotiation, negotiation complete.
>  Vendor ID is 00:01:f0:--:--:--, model 15 rev. 1.
>    No specific information is known about this transceiver type.
>  I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
>    Advertising no additional info pages.
>    IEEE 802.3 CSMA/CD protocol.
>  Link partner capability is cde1: Flow-control 100baseTx-FD 100baseTx
> 10baseT-FD 10baseT.
>    Negotiation  completed.
> 
> After pinging with the Generic PHY driver:
> 
> # ethtool -S eth0 | grep error
>      tx_crc_errors: 0
>      rx_crc_errors: 0
>      rx_xdp_tx_errors: 0
>      tx_xdp_xmit_errors: 0
> 
> After pinging with the SMSC PHY driver:
> 
> # ethtool -S eth0 | grep err
>      tx_crc_errors: 0
>      IEEE_tx_macerr: 0
>      IEEE_tx_cserr: 0
>      rx_crc_errors: 19
>      IEEE_rx_macerr: 0
>      rx_xdp_tx_errors: 0
>      tx_xdp_xmit_errors: 0
> 
> Any ideas?
> 
The smsc PHY driver for LAN8720 has a number of callbacks and flags.
Try commenting them out one after the other until it works.

.read_status	= lan87xx_read_status,
.config_init	= smsc_phy_config_init,
.soft_reset	= smsc_phy_reset,
.config_aneg	= lan95xx_config_aneg_ext,
.suspend	= genphy_suspend,
.resume		= genphy_resume,
.flags		= PHY_RST_AFTER_CLK_EN,

All of them are optional. If all are commented out, you should have
the behavior of the genphy driver.

Once we know which callback is problematic, we have a starting point.

> Thanks

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

[Florian Fainelli]

On 11/14/25 13:33, Heiner Kallweit wrote:
> On 11/14/2025 10:15 PM, Fabio Estevam wrote:
>> Hi Andrew,
>>
>> On Thu, Nov 13, 2025 at 7:35 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>
>>> Maybe dump all 32 registers when genphy and smsc driver are being used
>>> and compare them?
>>
>> The dump of all the 32 registers are identical in both cases:
>>
>> ./mii-diag -vvv
>> mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
>>   http://www.scyld.com/diag/index.html
>> Using the default interface 'eth0'.
>>    Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x3100).
>>   The autonegotiated capability is 01e0.
>> The autonegotiated media type is 100baseTx-FD.
>>   Basic mode control register 0x3100: Auto-negotiation enabled.
>>   You have link beat, and everything is working OK.
>>     This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
>>     Able to perform Auto-negotiation, negotiation complete.
>>   Your link partner advertised cde1: Flow-control 100baseTx-FD
>> 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
>>     End of basic transceiver information.
>>
>> libmii.c:v2.11 2/28/2005  Donald Becker (becker@scyld.com)
>>   http://www.scyld.com/diag/index.html
>>   MII PHY #0 transceiver registers:
>>     3100 782d 0007 c0f1 05e1 cde1 0009 ffff
>>     ffff ffff ffff ffff ffff ffff ffff 0000
>>     0040 0002 60e0 ffff 0000 0000 0000 0000
>>     ffff ffff 0000 000a 0000 00c8 0000 1058.
>>   Basic mode control register 0x3100: Auto-negotiation enabled.
>>   Basic mode status register 0x782d ... 782d.
>>     Link status: established.
>>     Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
>>     Able to perform Auto-negotiation, negotiation complete.
>>   Vendor ID is 00:01:f0:--:--:--, model 15 rev. 1.
>>     No specific information is known about this transceiver type.
>>   I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
>>     Advertising no additional info pages.
>>     IEEE 802.3 CSMA/CD protocol.
>>   Link partner capability is cde1: Flow-control 100baseTx-FD 100baseTx
>> 10baseT-FD 10baseT.
>>     Negotiation  completed.
>>
>> After pinging with the Generic PHY driver:
>>
>> # ethtool -S eth0 | grep error
>>       tx_crc_errors: 0
>>       rx_crc_errors: 0
>>       rx_xdp_tx_errors: 0
>>       tx_xdp_xmit_errors: 0
>>
>> After pinging with the SMSC PHY driver:
>>
>> # ethtool -S eth0 | grep err
>>       tx_crc_errors: 0
>>       IEEE_tx_macerr: 0
>>       IEEE_tx_cserr: 0
>>       rx_crc_errors: 19

The CRC errors should be a clear sign that you have a serious electrical 
issue here as the MAC is not capable of de-framing what is coming out of 
the PHY properly.

Given that you use RMII this would indicate that your PHY's TX CLK, 
which is a RX CLK on the MAC side may not be stable, do you have a scope 
you could use to check that it looks correct? Anything on the PCB itself 
that could hinder the clock signal quality?

Given that you don't see it at 10Mbits/sec, this would suggest you have 
an issue with data sampling and rise/fall times of the clock being 
misaligned with when the data is present on the data lines.
-- 
Florian

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

[Andrew Lunn]

> The CRC errors should be a clear sign that you have a serious electrical
> issue here as the MAC is not capable of de-framing what is coming out of the
> PHY properly.
> 
> Given that you use RMII this would indicate that your PHY's TX CLK, which is
> a RX CLK on the MAC side may not be stable, do you have a scope you could
> use to check that it looks correct? Anything on the PCB itself that could
> hinder the clock signal quality?
> 
> Given that you don't see it at 10Mbits/sec, this would suggest you have an
> issue with data sampling and rise/fall times of the clock being misaligned
> with when the data is present on the data lines.

And Heiner pointed out:

.flags          = PHY_RST_AFTER_CLK_EN

So i would see if that has anything to do with it.

	Andrew

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

[Fabio Estevam]

Hi Heiner,

On Fri, Nov 14, 2025 at 6:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:

> The smsc PHY driver for LAN8720 has a number of callbacks and flags.
> Try commenting them out one after the other until it works.
>
> .read_status    = lan87xx_read_status,
> .config_init    = smsc_phy_config_init,
> .soft_reset     = smsc_phy_reset,
> .config_aneg    = lan95xx_config_aneg_ext,
> .suspend        = genphy_suspend,
> .resume         = genphy_resume,
> .flags          = PHY_RST_AFTER_CLK_EN,
>
> All of them are optional. If all are commented out, you should have
> the behavior of the genphy driver.
>
> Once we know which callback is problematic, we have a starting point.

Thanks for the suggestion.

After removing the '.soft_reset = smsc_phy_reset,' line, there is no
packet loss anymore.

If you have any other suggestions regarding smsc_phy_reset(), please
let me know.

Thanks

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

[Heiner Kallweit]

On 11/15/2025 10:01 PM, Fabio Estevam wrote:
> Hi Heiner,
> 
> On Fri, Nov 14, 2025 at 6:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> 
>> The smsc PHY driver for LAN8720 has a number of callbacks and flags.
>> Try commenting them out one after the other until it works.
>>
>> .read_status    = lan87xx_read_status,
>> .config_init    = smsc_phy_config_init,
>> .soft_reset     = smsc_phy_reset,
>> .config_aneg    = lan95xx_config_aneg_ext,
>> .suspend        = genphy_suspend,
>> .resume         = genphy_resume,
>> .flags          = PHY_RST_AFTER_CLK_EN,
>>
>> All of them are optional. If all are commented out, you should have
>> the behavior of the genphy driver.
>>
>> Once we know which callback is problematic, we have a starting point.
> 
> Thanks for the suggestion.
> 
> After removing the '.soft_reset = smsc_phy_reset,' line, there is no
> packet loss anymore.
> 
> If you have any other suggestions regarding smsc_phy_reset(), please
> let me know.
> 
smsc_phy_reset() does two things:
1. set PHY to "all capable" mode if in power-down
2. genphy_soft_reset()

Again, as the genphy driver works fine for you, both parts should be optional.
Check with part is causing the packet loss.

> Thanks

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

[Russell King (Oracle)]

On Sat, Nov 15, 2025 at 06:01:38PM -0300, Fabio Estevam wrote:
> Hi Heiner,
> 
> On Fri, Nov 14, 2025 at 6:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> 
> > The smsc PHY driver for LAN8720 has a number of callbacks and flags.
> > Try commenting them out one after the other until it works.
> >
> > .read_status    = lan87xx_read_status,
> > .config_init    = smsc_phy_config_init,
> > .soft_reset     = smsc_phy_reset,
> > .config_aneg    = lan95xx_config_aneg_ext,
> > .suspend        = genphy_suspend,
> > .resume         = genphy_resume,
> > .flags          = PHY_RST_AFTER_CLK_EN,
> >
> > All of them are optional. If all are commented out, you should have
> > the behavior of the genphy driver.
> >
> > Once we know which callback is problematic, we have a starting point.
> 
> Thanks for the suggestion.
> 
> After removing the '.soft_reset = smsc_phy_reset,' line, there is no
> packet loss anymore.
> 
> If you have any other suggestions regarding smsc_phy_reset(), please
> let me know.

What happens if you replace this with genphy_soft_reset() ?

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

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.

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.

This is from https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8720A-LAN8720Ai-Data-Sheet-DS00002165.pdf

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Fabio Estevam]

On Sat, Nov 15, 2025 at 6:26 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:

> smsc_phy_reset() does two things:
> 1. set PHY to "all capable" mode if in power-down
> 2. genphy_soft_reset()
>
> Again, as the genphy driver works fine for you, both parts should be optional.
> Check with part is causing the packet loss.

It is the genphy_soft_reset() that causes the packet loss.

If I comment it out like this, there is no packet loss:

--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -149,8 +149,7 @@ static int smsc_phy_reset(struct phy_device *phydev)
                phy_write(phydev, MII_LAN83C185_SPECIAL_MODES, rc);
        }

-       /* reset the phy */
-       return genphy_soft_reset(phydev);
+       return 0
 }

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

[Russell King (Oracle)]

On Sat, Nov 15, 2025 at 06:54:08PM -0300, Fabio Estevam wrote:
> On Sat, Nov 15, 2025 at 6:26 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> 
> > smsc_phy_reset() does two things:
> > 1. set PHY to "all capable" mode if in power-down
> > 2. genphy_soft_reset()
> >
> > Again, as the genphy driver works fine for you, both parts should be optional.
> > Check with part is causing the packet loss.
> 
> It is the genphy_soft_reset() that causes the packet loss.
> 
> If I comment it out like this, there is no packet loss:
> 
> --- a/drivers/net/phy/smsc.c
> +++ b/drivers/net/phy/smsc.c
> @@ -149,8 +149,7 @@ static int smsc_phy_reset(struct phy_device *phydev)
>                 phy_write(phydev, MII_LAN83C185_SPECIAL_MODES, rc);
>         }
> 
> -       /* reset the phy */
> -       return genphy_soft_reset(phydev);
> +       return 0
>  }
> 

This is no proof. The two are not independent. See 3.7.2 of the LAN8720
datasheet. A change to the MODE[2:0] field requires a soft reset to
take effect.

Avoiding the soft reset just means effectively you've disabled the
effect of the write to MII_LAN83C185_SPECIAL_MODES. I don't see
anywhere else that the driver would set the RESET bit in BMCR, so
this write will never take effect.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Fabio Estevam]

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

> This is no proof. The two are not independent. See 3.7.2 of the LAN8720
> datasheet. A change to the MODE[2:0] field requires a soft reset to
> take effect.
>
> Avoiding the soft reset just means effectively you've disabled the
> effect of the write to MII_LAN83C185_SPECIAL_MODES. I don't see
> anywhere else that the driver would set the RESET bit in BMCR, so
> this write will never take effect.

On this board, MODE[2:0] is 111 , which comes from the strap MODE pins.

This means that the "If the SMSC PHY is in power down mode" path is
never executed on this board.

In the section you pointed out:

"Power Down mode. In this mode the transceiver will
wake-up in Power-Down mode. The transceiver
cannot be used when the MODE[2:0] bits are set to
this mode. To exit this mode, the MODE bits in Reg-
ister 18.7:5(see Section 4.2.9, "Special Modes Reg-
ister," on page 50) must be configured to some
other value and a soft reset must be issued."

I am wondering if the genphy_soft_reset() should happen only when if
the write to MII_LAN83C185_SPECIAL_MODES is done:

--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -147,10 +147,10 @@ static int smsc_phy_reset(struct phy_device *phydev)
                /* set "all capable" mode */
                rc |= MII_LAN83C185_MODE_ALL;
                phy_write(phydev, MII_LAN83C185_SPECIAL_MODES, rc);
+               return genphy_soft_reset(phydev);
        }

-       /* reset the phy */
-       return genphy_soft_reset(phydev);
+       return 0;
 }

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

[Fabio Estevam]

On Sat, Nov 15, 2025 at 6:37 PM Russell King (Oracle)
<linux@armlinux.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

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

[Fabio Estevam]

On Sat, Nov 15, 2025 at 9:57 PM Fabio Estevam <festevam@gmail.com> wrote:

> 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.

Ok, what do you think about the change below?

It will work when reset-gpios is described inside the ethernet-phy node.

It will not work when the reset GPIO is specified within the FEC node
via the phy-reset-gpios property.

This is OK as 'phy-reset-gpios' is marked as deprecated in
Documentation/devicetree/bindings/net/fsl, fec.yaml.

--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -147,9 +147,19 @@ static int smsc_phy_reset(struct phy_device *phydev)
                /* set "all capable" mode */
                rc |= MII_LAN83C185_MODE_ALL;
                phy_write(phydev, MII_LAN83C185_SPECIAL_MODES, rc);
+               /* reset the phy */
+               return genphy_soft_reset(phydev);
        }

-       /* reset the phy */
+       /*
+        * If the reset-gpios property exists, a hardware reset will be
+        * performed by the PHY core, so do NOT issue a soft reset here.
+        */
+       if (phydev->mdio.dev.of_node &&
+           of_property_present(phydev->mdio.dev.of_node, "reset-gpios"))
+               return 0;
+
+       /* No reset GPIO: fall back to soft reset */
        return genphy_soft_reset(phydev);
 }

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

[Andrew Lunn]

On Sat, Nov 15, 2025 at 11:14:33PM -0300, Fabio Estevam wrote:
> On Sat, Nov 15, 2025 at 9:57 PM Fabio Estevam <festevam@gmail.com> wrote:
> 
> > 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.
> 
> Ok, what do you think about the change below?
> 
> It will work when reset-gpios is described inside the ethernet-phy node.
> 
> It will not work when the reset GPIO is specified within the FEC node
> via the phy-reset-gpios property.
> 
> This is OK as 'phy-reset-gpios' is marked as deprecated in
> Documentation/devicetree/bindings/net/fsl, fec.yaml.
> 
> --- a/drivers/net/phy/smsc.c
> +++ b/drivers/net/phy/smsc.c
> @@ -147,9 +147,19 @@ static int smsc_phy_reset(struct phy_device *phydev)
>                 /* set "all capable" mode */
>                 rc |= MII_LAN83C185_MODE_ALL;
>                 phy_write(phydev, MII_LAN83C185_SPECIAL_MODES, rc);
> +               /* reset the phy */
> +               return genphy_soft_reset(phydev);
>         }
> 
> -       /* reset the phy */
> +       /*
> +        * If the reset-gpios property exists, a hardware reset will be
> +        * performed by the PHY core, so do NOT issue a soft reset here.
> +        */
> +       if (phydev->mdio.dev.of_node &&
> +           of_property_present(phydev->mdio.dev.of_node, "reset-gpios"))
> +               return 0;
> +
> +       /* No reset GPIO: fall back to soft reset */
>         return genphy_soft_reset(phydev);

We are still missing the "Why?". Why does a combination of a hard and
soft reset mess up the PHY?

It would be good to understand this before accepting the patch. Or
extend the patch and the commit message to say that we have no idea
why this works, but testing suggests it does. That will help anybody
who comes later and has problems here to know this is a magical
workaround, not a fix.

	Andrew