Toggling up/down ethernet link IMX6UL LAN8720

[AndyLewis]

Hi

I am developing a custom board using a Digi international connect core module.

On some boards ethernet is working well on both ethernet ports.

On others eth0 continuously alternates up/down 100M.

On one switch a faulty board drops to 10M and works after several attempts at 100M.

On some boards it has the problem sometimes.

If I reset the PHY IC by grounding its reset input it then works properly.

I have scoped the pin and it is getting driven at startup

eth1 always seems OK

It sounds a bit similar to this 2017 patch (but the changes seem to be in place)

https://lore.kernel.org/patchwork/patch/861449/

Any advice on debugging, I am a newbie to kernel debugging.

mii-tool shows only one register bit change from before to after a physical reset; MII_ADVERTISE Pause operation is "Symmetric" before reset and "No Pause" after.

Regards

   Andy

[max_merchel]

Hi Andy,

I had the same problem with an imx6ul after updating to the 5.4 kernel.

I had deprecated fec properties in the devicetree. The reset properties must now be set in the phy node.

After I set the reset settings in the phy node, the problem no longer occurred.

https://elixir.bootlin.com/linux/v5.4.108/source/Documentation/devicetree/bindings/net/fsl-fec.txt

https://elixir.bootlin.com/linux/v5.4.87/source/Documentation/devicetree/bindings/net/ethernet-phy.y...

If you have the same cause, I am glad to have helped you.

Regards

Max

[AndyLewis]

Hi,

A quick update.

Re-configuring the Digi version of u-boot to use the other ethernet port worked reliably so there is not too much wrong with the hardware.

I have had some success with a workaround:-

==========================================

drivers/net/ethernet/freescale/fec_main.c

static void fec_enet_adjust_link(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
struct phy_device *phy_dev = ndev->phydev;
int status_change = 0;

/*
* If the netdev is down, or is going down, we're not interested
* in link state events, so just mark our idea of the link as down
* and ignore the event.
*/
if (!netif_running(ndev) || !netif_device_present(ndev)) {
fep->link = 0;
} else if (phy_dev->link) {
.
.
.
} else {
if (fep->link) {
napi_disable(&fep->napi);
netif_tx_lock_bh(ndev);
fec_stop(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
fep->link = phy_dev->link;
status_change = 1;
// Multitone Hack for an endless loop of link up/down
// Which resetting the PHY IC seems to stop
// This occurs on some boards and not always
// TODO the is a work around not a proper fix
netdev_err(fep->netdev, "fec_enet_ajust_link down - resetting\n");
fec_reset_phy(fep->pdev);

}
}

if (status_change)
phy_print_status(phy_dev);
}

========================================

This has got the boards working but on some I am dropping a few packets (1 in 2000 ish)

Regards

   Andy

[AndyLewis · Accepted solution]

Hi,

Thanks for the suggestions.

Digi International have now updated their version of the drivers, fixing the problem.

Regards

  Andy

[sinanakman]

Hi Andy

Is this only a kernel problem, do both ports work well in u-boot ?

Can you just load and test latest official u-boot (not the vendor tree). This might hep to identify the problem and solve it a bit faster.

Hope this helps.

Regards

Sinan Akman

[AndyLewis]

Hi Sinan,

Porting u-boot sounds like a fairly big exercise, Digi is now running with the 2020.04 version.

Unfortunately this uses the other Ethernet port (without the issue).

What is it that you would hope to get from the vanilla version of u-boot?

Regards

   Andy

[sinanakman]

Hi Andy

I understand porting to mainline might be an unnecessary step for you at this point. For me the biggest advantage of working only with mainline is the level of testing the code gets and the vast amount of community support.

If vendor tree is based on 2020.04 and if you ever decide to pursue this avenue, I would recommend to briefly see what patches were added by the vendor to mainline version. Alternatively you can take a look at the patches related to LAN8720 in mainline after 2020.04 and see if there is anything relevant (I believe you did this already for your kernel). 

Hope someone else can help you better.

All the best

Sinan Akman

[jamesbone]

Have you contact already Digi? to review if they have detected this failure of their board and/or software?

[AndyLewis]

Hi James,

I have mentioned it to Digi before but as one of several questions, I have asked again about this specific issue today.

Regards

    Andy