Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dario Alcocer <dalcocer@helixd.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org
Subject: Re: Marvell switch port shows LOWERLAYERDOWN, ping fails
Date: Fri, 23 Jul 2021 11:21:47 -0700	[thread overview]
Message-ID: <0188e53d-1535-658a-4134-a5f05f214bef@helixd.com> (raw)
In-Reply-To: <YPrHJe+zJGJ7oezW@lunn.ch>

On 7/23/21 6:41 AM, Andrew Lunn wrote:
> On Thu, Jul 22, 2021 at 03:55:04PM -0700, Dario Alcocer wrote:
>> root@dali:~# ip link
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
>>      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
>>      link/can
>> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1000
>>      link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>      link/sit 0.0.0.0 brd 0.0.0.0
>> 5: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
>>      link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
> 
> NO-CARRIER suggests a PHY problem. You should see it report link up if
> it really is up.
> 
> When then switch probes the PHYs should also probe. What PHY driver is
> being used? You want the Marvell PHY driver, not genphy.

Looks like the Marvell PHY driver is being used:

root@dali:~# grep -i phy /var/log/messages
Jan  1 00:00:10 (none) user.info kernel: [    4.126862] libphy: 
mv88e6xxx SMI: probed
Jan  1 00:00:10 (none) user.info kernel: [    5.620909] mv88e6085 
stmmac-0:1a lan1 (uninitialized): PHY [mv88e6xxx-0:00] driver [Marvell 
88E1540]
Jan  1 00:00:10 (none) user.info kernel: [    5.669606] mv88e6085 
stmmac-0:1a lan2 (uninitialized): PHY [mv88e6xxx-0:01] driver [Marvell 
88E1540]
Jan  1 00:00:10 (none) user.info kernel: [    5.719458] mv88e6085 
stmmac-0:1a lan3 (uninitialized): PHY [mv88e6xxx-0:02] driver [Marvell 
88E1540]
Jan  1 00:00:10 (none) user.info kernel: [    7.103178] mv88e6085 
stmmac-0:1e lan4 (uninitialized): PHY [mv88e6xxx-2:00] driver [Marvell 
88E1540]
Jan  1 00:00:10 (none) user.info kernel: [    7.151820] mv88e6085 
stmmac-0:1e dmz (uninitialized): PHY [mv88e6xxx-2:01] driver [Marvell 
88E1540]
Nov  1 12:01:37 (none) user.info kernel: [  107.993670] mv88e6085 
stmmac-0:1a lan1: configuring for phy/gmii link mode


>> 6: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>      link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 7: lan3@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>      link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 8: lan4@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>      link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> 9: dmz@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>>      link/ether aa:10:22:58:38:77 brd ff:ff:ff:ff:ff:ff
>> root@dali:~# ip route
>> default via 192.168.0.1 dev eth0
> 
> That is not correct. eth0 just acts as a pipe towards the switch. It
> does not have an IP address, and there should not be any routes using
> it. It needs to be configured up, but that is all.
> 

I've been fighting with Busybox init to just bring up eth0 with no IPv4 
configuration, without success. I'll go back and review the Busybox docs 
to see how to bring up eth0 without any IPv4 configuration.

>> The DSA switch tree is configured using this device tree fragment:
>>
>> gmac0 {
>>      status = "okay";
>>      phy-mode = "gmii";
> 
> gmii? That is a bit unusual. You normally see rgmii.
> 

I reviewed the schematic again and confirmed that gmii is being used. 
The schematic shows RXD[7:0] and TXD[7:0] connected to port 6. However, 
I just noticed no skew values are specified for RXD[7:4] and TXD[7:4]. I 
  should fix that.

>>      txc-skew-ps = <0xbb8>;
>>      rxc-skew-ps = <0xbb8>;
>>      txen-skew-ps = <0>;
>>      rxdv-skew-ps = <0>;
>>      rxd0-skew-ps = <0>;
>>      rxd1-skew-ps = <0>;
>>      rxd2-skew-ps = <0>;
>>      rxd3-skew-ps = <0>;
>>      txd0-skew-ps = <0>;
>>      txd1-skew-ps = <0>;
>>      txd2-skew-ps = <0>;
>>      txd3-skew-ps = <0>;
>>      max-frame-size = <3800>;
>>
>>      fixed-link {
>>      speed = <0x3e8>;
> 
> decimal would be much more readable. Or is this not the source .dts
> file, but you have decompiled the DTB back to DTS?
> 

The original .dts was auto-generated using Altera tools, which emit 
hexadecimal. I've been converting to decimal as I make changes to the 
.dts. The speed value 0x3e8 is 1000 decimal.

>>          full-duplex;
>>          pause;
>>      };
>>
>>      mdio {
>>          compatible = "snps,dwmac-mdio";
>>          #address-cells = <0x1>;
>>          #size-cells = <0x0>;
>>
>>          switch0: switch0@1a {
>>              compatible = "marvell,mv88e6085";
>>              reg = <0x1a>;
>>              dsa,member = <0 0>;
>>              ports {
>>                  #address-cells = <1>;
>>                  #size-cells = <0>;
>>                  port@0 {
>>                      reg = <0>;
>>                      label = "lan1";
>>                  };
>>                  port@1 {
>>                      reg = <1>;
>>                      label = "lan2";
>>                  };
>>                  port@2 {
>>                      reg = <2>;
>>                      label = "lan3";
>>                  };
>>                  switch0port4: port@4 {
>>                      reg = <4>;
>>                      phy-mode = "rgmii-id";
>>                      link = <&switch1port4>;
>>                      fixed-link {
>>                          speed = <1000>;
>>                          full-duplex;
>>                      };
>>                  };
>>                  port@6 {
>>                      reg = <6>;
>>                      ethernet = <&gmac0>;
>>                      label = "cpu";
>>                  };
>>              };
>>          };
>>          switch1: switch1@1e {
>>              compatible = "marvell,mv88e6085";
>>              reg = <0x1e>;
>>              dsa,member = <0 1>;
>>              ports {
>>                  #address-cells = <1>;
>>                  #size-cells = <0>;
>>                  port@0 {
>>                      reg = <0>;
>>                      label = "lan4";
>>                  };
>>                  port@1 {
>>                      reg = <1>;
>>                      label = "dmz";
>>                  };
>>                  switch1port4: port@4 {
>>                      reg = <4>;
>>                      link = <&switch0port4>;
>>                      phy-mode = "rgmii-id";
> 
> You probably don't want both ends of the link in rgmii-id mode. That
> will give you twice the delay.

Ok, I'll change phy-mode to "rgmii" for both ends. It's a little 
confusing that there's a reference to phy-mode at all, though, given the 
actual connection is SERDES. My understanding is SERDES is a digital, 
PHY-less connection.

I'll update the .dts to include the missing skew settings and the 
phy-mode setting for the dsa ports, then post my results. (I've already 
fixed the .dts to specify the correct switch for the cpu port, an error 
I caught after posting.)

Thanks for the input!

  reply	other threads:[~2021-07-23 18:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22 22:55 Dario Alcocer
2021-07-23 13:41 ` Andrew Lunn
2021-07-23 18:21   ` Dario Alcocer [this message]
2021-07-23 18:25     ` Andrew Lunn
2021-07-23 18:36       ` Dario Alcocer
2021-07-23 21:58         ` Dario Alcocer
2021-07-24 17:34           ` Andrew Lunn
2021-07-25  2:26             ` Dario Alcocer
2021-07-25  2:36               ` Dario Alcocer
2021-07-27  1:39                 ` Dario Alcocer
2021-07-28 18:07                   ` Dario Alcocer
2021-07-28 18:23                     ` Andrew Lunn
2021-07-28 18:33                       ` Dario Alcocer
2021-07-28 19:24                         ` Andrew Lunn
2021-07-28 19:37                           ` Dario Alcocer
2021-07-28 20:47                             ` Andrew Lunn
2021-07-28 20:54                               ` Dario Alcocer
2021-07-28 21:09                             ` Andrew Lunn
2021-08-05 21:44                             ` Dario Alcocer
2021-08-06 16:03                               ` Dario Alcocer
2021-08-06 23:46                                 ` Dario Alcocer
2021-08-07 18:57                                   ` Andrew Lunn
2021-08-09 16:28                                     ` Dario Alcocer
2021-08-10 20:58                                       ` Dario Alcocer
2021-08-10 22:13                                         ` Andrew Lunn
2021-08-11 13:16                                           ` Dario Alcocer
2021-08-07 17:44                               ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0188e53d-1535-658a-4134-a5f05f214bef@helixd.com \
    --to=dalcocer@helixd.com \
    --cc=andrew@lunn.ch \
    --cc=netdev@vger.kernel.org \
    --subject='Re: Marvell switch port shows LOWERLAYERDOWN, ping fails' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).