[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86c1f4b8-8902-42ea-a3ae-9b0633f516ed@lunn.ch>
Date: Wed, 7 May 2025 21:17:57 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Steve Broshar <steve@...merwirelessmedtech.com>
Cc: Edward J Palmer <ed@...merwirelessmedtech.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: request for help using mv88e6xxx switch driver
On Wed, May 07, 2025 at 06:29:18PM +0000, Steve Broshar wrote:
> +Ed (hardware expert)
>
> Ed, Do we have a direct MAC to MAC connection between the FEC and the Switch?
>
> Following is the DT configuration which has a fixed-length node in the host port node. TBO some of these settings have been verified, but many are mysterious.
>
> &fec1 {
> // [what is this? Does this tell the driver how to use the pins of pinctrl_fec1?]
> pinctrl-names = "default";
>
> // ethernet pins
> pinctrl-0 = <&pinctrl_fec1>;
>
> // internal delay (id) required (in switch/phy not SOC MAC) [huh?]
> phy-mode = "rgmii-id";
You don't want both the FEC and the Switch MAC to insert the
delays. So one needs to be rgmii-id, and the other rgmii. I would
suggest the FEC does rgmii-id, but it does not really matter.
> // tried for for Compton, but didn't help with ethernet setup
> //phy-mode = "rgmii";
>
> // link to "phy" <=> cpu attached port of switch [huh?]
> // [is this needed? port 5 is linked to fec1. is this link also needed?]
> phy-handle = <&swp5>;
This is wrong, and the cause of your problems.
Copy/paste from the example i gave:
fixed-link {
speed = <1000>;
full-duplex;
};
The FEC driver expects there to be a PHY there to tell it what speed
to run the MAC at, once autoneg has completed. But since you don't
have a PHY, the simplest option is to emulate it. This creates an
emulated PHY which reports the link is running at 1G.
>
> // try this here; probably not needed as is covered with reset-gpios for switch;
> // Seems like the wrong approach since get this msg at startup:
> // "Remove /soc@...us@...00000/ethernet@...e0000:phy-reset-gpios"
> //phy-reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
No PHY, so you have nothing to reset.
>
> // enable Wake-on-LAN (WoL); aka/via magic packets
> fsl,magic-packet;
WoL probably does not work. The frames from the switch have an extra
header on the beginning, so i doubt the FEC is able decode them to
detect a WoL magic packet. If you need WoL, you need to do it in the
switch.
> // node enable
> status = "okay";
>
> // MDIO (aka SMI) bus
> mdio1: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> // Marvell switch -- on Compton's base board
> // node doc: Documentation/devicetree/bindings/net/dsa/marvell.txt
> switch0: switch@0 {
> // used to find ID register, 6320 uses same position as 6085 [huh?]
> compatible = "marvell,mv88e6085";
Correct, but you know that already, the probe function detected the switch.
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> // device address (0..31);
> // any value addresses the device on the base board since it's configured for single-chip mode;
> // and that is achieved by not connecting the ADDR[4:0] lines;
> // even though any value should work at the hardware level, the driver seems to want value 0 for single chip mode
> reg = <0>;
>
> // reset line: GPIO2_IO10
> reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
>
> // don't specify member since no cluster [huh?]
> // from dsa.yaml: "A switch not part of [a] cluster (single device hanging off a CPU port) must not specify this property"
> // dsa,member = <0 0>;
This is all about the D in DSA. You can connect a number of switches
together into a cluster, and each needs its own unique ID.
>
> // note: only list the ports that are physically connected; to be used
> // note: # for "port@#" and "reg=<#>" must match the physical port #
> // node doc: Documentation/devicetree/bindings/net/dsa/dsa.yaml
> // node doc: Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> // primary external port (PHY)
> port@3 {
> reg = <3>;
> label = "lan3";
> };
>
> // secondary external port (PHY)
> port@4 {
> reg = <4>;
> label = "lan4";
> };
>
> // connection to the SoC
> // note: must be in RGMII mode (which requires pins [what pins?] to be high on switch reset)
> swp5: port@5 {
> reg = <5>;
>
> // driver uses label="cpu" to identify the internal/SoC connection;
> // note: this label isn't visible in userland;
> // note: ifconfig reports a connection "eth0" which is the overall network connection; not this port per se
> label = "cpu";
>
> // link back to parent ethernet driver [why?]
> ethernet = <&fec1>;
>
> // media interface mode;
> // internal delay (id) is specified [why?]
> // Note: early driver versions didn't set [support?] id
> phy-mode = "rgmii-id";
> // tried for for Compton, but didn't help with ethernet setup
> //phy-mode = "rgmii";
>
> // tried this; no "link is up" msg but otherwise the same result
> // managed = "in-band-status";
Managed is used for SGMII, 1000BaseX and other similar links which
have inband signalling. RGMII does not need it.
>
> // ensure a fixed link to the switch [huh?]
> fixed-link {
> speed = <1000>; // 1Gbps
> full-duplex;
> };
> };
> };
> };
> };
> };
The rest looks reasonable.
Andrew
Powered by blists - more mailing lists