All of lore.kernel.org
 help / color / mirror / Atom feed
* [REGRESSION,BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7
@ 2014-04-12 16:28 ` Arnaud Ebalard
  0 siblings, 0 replies; 6+ messages in thread
From: Arnaud Ebalard @ 2014-04-12 16:28 UTC (permalink / raw)
  To: Thomas Petazzoni; +Cc: netdev, linux-arm-kernel, Willy Tarreau, David Miller

Hi Thomas,

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

Some additional notes:
 - you tested w/ mvneta as a module. Did you test w/ mvneta driver
   built in the kernel? This is what I have on my side.
 - e3a8786c10e7 is in 3.13.9 kernel and possibly previous ones: I can
   confirm 3.13.9 is also broken for me.
 - I initially thought the issue was specific to A370 (some differences
   in mvneta logic?) as all your tests had been done on AXP. This is the
   reason I also checked the RN2120 (mv78230) and it is impacted.

Any idea is welcome.

Cheers,

a+

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [REGRESSION, BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7
@ 2014-04-12 16:28 ` Arnaud Ebalard
  0 siblings, 0 replies; 6+ messages in thread
From: Arnaud Ebalard @ 2014-04-12 16:28 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Thomas,

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

Some additional notes:
 - you tested w/ mvneta as a module. Did you test w/ mvneta driver
   built in the kernel? This is what I have on my side.
 - e3a8786c10e7 is in 3.13.9 kernel and possibly previous ones: I can
   confirm 3.13.9 is also broken for me.
 - I initially thought the issue was specific to A370 (some differences
   in mvneta logic?) as all your tests had been done on AXP. This is the
   reason I also checked the RN2120 (mv78230) and it is impacted.

Any idea is welcome.

Cheers,

a+

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [REGRESSION,BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7
  2014-04-12 16:28 ` [REGRESSION, BISECTED] " Arnaud Ebalard
@ 2014-04-12 16:31   ` Thomas Petazzoni
  -1 siblings, 0 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2014-04-12 16:31 UTC (permalink / raw)
  To: Arnaud Ebalard; +Cc: netdev, linux-arm-kernel, Willy Tarreau, David Miller

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [REGRESSION,BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7
@ 2014-04-12 16:31   ` Thomas Petazzoni
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2014-04-12 16:31 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [REGRESSION,BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7
  2014-04-12 16:31   ` Thomas Petazzoni
@ 2014-04-12 16:37     ` Arnaud Ebalard
  -1 siblings, 0 replies; 6+ messages in thread
From: Arnaud Ebalard @ 2014-04-12 16:37 UTC (permalink / raw)
  To: Thomas Petazzoni; +Cc: netdev, linux-arm-kernel, Willy Tarreau, David Miller

Hi Thomas,

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

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

Thanks for your work and the fast feedback. Do not hesitate to bug me if
you want me to do some tests at some point.

Cheers,

a+

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [REGRESSION, BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7
@ 2014-04-12 16:37     ` Arnaud Ebalard
  0 siblings, 0 replies; 6+ messages in thread
From: Arnaud Ebalard @ 2014-04-12 16:37 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Thomas,

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

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

Thanks for your work and the fast feedback. Do not hesitate to bug me if
you want me to do some tests at some point.

Cheers,

a+

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-04-12 16:38 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-12 16:28 [REGRESSION,BISECTED] mvneta broken in 3.14 on RN2120, RN102 and RN104 after e3a8786c10e7 Arnaud Ebalard
2014-04-12 16:28 ` [REGRESSION, BISECTED] " Arnaud Ebalard
2014-04-12 16:31 ` [REGRESSION,BISECTED] " Thomas Petazzoni
2014-04-12 16:31   ` Thomas Petazzoni
2014-04-12 16:37   ` Arnaud Ebalard
2014-04-12 16:37     ` [REGRESSION, BISECTED] " Arnaud Ebalard

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.