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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 12 Apr 2014 18:31:12 +0200 From: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com> To: arno@...isbad.org (Arnaud Ebalard) Cc: netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Willy Tarreau <w@....eu>, David Miller <davem@...emloft.net> Subject: Re: [REGRESSION,BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7 Dear Arnaud Ebalard, On Sat, 12 Apr 2014 18:28:57 +0200, Arnaud Ebalard wrote: > Network is broken w/ 3.14 kernel on Netgear ReadyNAS 102 (the SoC is > an Armada 370 using mvneta driver and rgmii phy): nothing sent, nothing > received from the interface. This came as a surprise (it was reported by > two users) as 3.14-rc8 was ok on my side. > > I also checked on a ReadyNAS 104 (Armada 370 using mvneta driver and > rgmii phy for both interfaces) and a ReadyNAS 2120 (Armada XP using > mvneta driver and rgmii phy for both interfaces). They are both > affected too. > > A short bisect session pointed e3a8786c10e7 (net: mvneta: fix usage as a > module on RGMII configurations). Reverting it put things back in order > on those three devices. > > I took a quick look at e3a8786c10e7 commit and did some tests to narrow > the root cause (I do not have A370 functional specification doc at hand > today so I was not able to check mvneta details): > > -} > - > /* Start the Ethernet port RX and TX activity */ > static void mvneta_port_up(struct mvneta_port *pp) > { > @@ -2756,12 +2728,15 @@ static void mvneta_port_power_up(struct mvneta_port *pp, int phy_mode) > mvreg_write(pp, MVNETA_UNIT_INTR_CAUSE, 0); > > if (phy_mode == PHY_INTERFACE_MODE_SGMII) > - mvneta_port_sgmii_config(pp); > + mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_SGMII_SERDES_PROTO); > + else > + mvreg_write(pp, MVNETA_SERDES_CFG, MVNETA_RGMII_SERDES_PROTO); > > > I built a first kernel with the 'else' branch above removed (rationale: > SERDES config was not set for RGMII prior to the patch). The issue > remained. > > - mvneta_gmac_rgmii_set(pp, 1); > + val = mvreg_read(pp, MVNETA_GMAC_CTRL_2); > + > + val |= MVNETA_GMAC2_PCS_ENABLE | MVNETA_GMAC2_PORT_RGMII; > > I removed MVNETA_GMAC2_PCS_ENABLE flag setting (rationale: it was only > done for SGMII prior to the patch and all my platforms have RGMII > connected PHY). *The issue disappeared on all 3 NAS with that simple > change*. Yes, issue known. See https://bugzilla.kernel.org/show_bug.cgi?id=73401. Unfortunately, at this point I don't have enough informations to fix both issues: the issue you're having, and the issue of using mvneta as a module. Since the issue you're having is much more problematic, I'll send a patch to revert my patch, until I have enough informations to fix the problem in a proper way. Thanks for your report! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists