From patchwork Fri Nov 27 09:30:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michael Heimpold X-Patchwork-Id: 549357 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 654BA140319 for ; Fri, 27 Nov 2015 20:32:07 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754499AbbK0JcC (ORCPT ); Fri, 27 Nov 2015 04:32:02 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:52499 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754467AbbK0Jb6 (ORCPT ); Fri, 27 Nov 2015 04:31:58 -0500 Received: from [192.168.178.58] ([109.104.54.55]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MHY8C-1a19xS0p9I-003QPw; Fri, 27 Nov 2015 10:30:22 +0100 From: Michael Heimpold Subject: Problem with "swinging" ethernet link on i.MX28 based device Organization: I2SE GmbH Cc: lw@karo-electronics.de, fabio.estevam@freescale.com, marek.vasut@gmail.com To: NETDEV Message-ID: <565822B2.30007@i2se.com> Date: Fri, 27 Nov 2015 10:30:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 X-Provags-ID: V03:K0:1CtnLcpa7B0idHz9yMrdaVx96y6oCnQlrbU1NvJetuDvdq7ixAx 4JRFsP7/j10j09tY1YbyCU0tLzNALi/ebvRJ86JBJav/XUv9R/dMkhOYC7GnLlYsDChYSJ8 /HgwsdQTBvCvCgp9Gp0wiKmDVRScBaYDNQiKvxahbeWYL4fU/r40CToXrJNEEL7UFAf5aSD oRsgegU9Zqv2rQAh7mb5Q== X-UI-Out-Filterresults: notjunk:1; V01:K0:D+lxhvfJc/g=:YeHcB8E8TyJBxl7DBChktX myPS8iU0Gb68O11QNbE6cl2w6diVnQQ1o7jj3etK4+9u55vOQPYPL5tU4/ukg63dyLth3b5cR 8vNeR2yeZLTa5Db65tq4MN6keFHpk+/a9Zqhu5juaB0LvwvFO/ZlHa5xuzZt3Euv/79lzsyEO I9+qjYxwxGDhf+exjv7y0AVSFcXYEpPi41KkfAHYq+ZzvdAKzrq4oDSxlsFSAUEPZna1kp7TK 2XiOUSU3cN98aPe1gRHDmALDcrdxvRIPz1AqeE3Aaoytw9/GkxluHTEkwhw6L20Q1VQf/lRtN Re/lexlGpwjlgybxt+IwFGC/ow6s4IPfwIU6X7P5K3hQ8Ns4gw9ViPZJe+5y2eJnSB5x2bGwn 2interSAUEzS3P8Kti87GySxvHHIjr1szZCnhJBQZ4F9GzfllCsWMPmlVDhegD4pTihuRiVnW qIgGQHDAME0hoSNUodJHvi59nxMDbP4+w/EGV5C9AIamKX5EwXTVwQI3eVNAjXWc8CcVIctEW aW9h5QmsDgOWrcLXCcElE7S6l2uOWfAWFyxXeG/CyXAnNn9JX0Ri7xfNIQYr8oEf5qpuzUHa9 uvpLCnoWNoTObU7j5n2xv6Qt9obob7xGNM5aL9VPrm3PQXJPxpRZJbu0zpA6ztIkI2RhQT51G N1eG6RYqLAZ4WNaJgmyui1SY3Rg1CsnogK4t9fSRLjbvL1c5djwv9VA2qSzoZ7c65xTlQ5j58 UtNvQjFq75LzDqwV Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, we at I2SE have developed an i.MX28 based embedded device, called Duckbill. Regarding ethernet, it is very similar to the FSL mx28evk, i.e. we use the same phy (SMSC LAN8720), we use RMII mode, clock is provided by iMX (not via external crystal), we have a GPIO to reset the phy and an interrupt GPIO. At the moment, we are using vanilla kernel 4.2.5 with only a fetch patches - mainly patches to add the device tree stuff needed and some cherry-picked upstream patches. Nothing special IMO. You can find it here: https://github.com/I2SE/linux/tree/v4.2.5-duckbill After booting the device, we observe on a few devices the ethernet "swinging" or toggling: [ 15.830759] fec 800f0000.ethernet eth0: Freescale FEC PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=800f0000.etherne:00, irq=35) [ 15.843361] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 17.112867] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 17.121746] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 17.894416] fec 800f0000.ethernet eth0: Link is Down [ 19.506960] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 20.294398] fec 800f0000.ethernet eth0: Link is Down [ 21.932365] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 22.714410] fec 800f0000.ethernet eth0: Link is Down [ 24.357890] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 25.144400] fec 800f0000.ethernet eth0: Link is Down [ 26.783367] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 27.564357] fec 800f0000.ethernet eth0: Link is Down [ 29.208846] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx However, in U-Boot I can transfer several hundreds of MB without any problem, I can attach the cable/reattach etc. as usual - no obvious problems. This is the reason, we think that the hardware is ok (and of course, we double-checked especially the soldering of the affected devices). This is what I tried so far: - changed the device tree to not use the interrupt line -> phy is polled periodically - reverted latest phy changes for LAN8720, i.e. d88ecb373bd1877acc43e13311a8e0e6daffc3d2 - "net: phy: smsc: disable energy detect mode" ff94c742dfeea3110f1e1d27399d728f8494d29e - "net: phy: fix semicolon.cocci warnings" 776829de90c5972895db398993ddfa9417ff8b01 - "net: phy: workaround for buggy cable detection by LAN8700 after cable plugging" - then I tried the following patch -snip- and thus FEC is configured for MII. When using ENET_CLK_OUT this results in 25 MHz clock to phy instead of 50 MHz as required by RMII. At least for a short time, there might be a "glitch". The concern was, that the phy might become stuck by this. However, nothing of the above improved anything. So, at the moment, I'm running out of ideas - any help/hint to debug this issue further is really appreciated. Please let me know if I missed some important information. Mit freundlichen Grüßen / Kind regards Michael Heimpold --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -936,7 +936,7 @@ fec_restart(struct net_device *ndev) if (fep->quirks & FEC_QUIRK_HAS_AVB) { writel(0, fep->hwp + FEC_ECNTRL); } else { - writel(1, fep->hwp + FEC_ECNTRL); + //writel(1, fep->hwp + FEC_ECNTRL); udelay(10); } -snap- The idea behind this patch is: when FEC is resetted, then registers are reset to initial values