Message-ID:
 <IA1PR15MB600846DAB00BD9651A0276F3B588A@IA1PR15MB6008.namprd15.prod.outlook.com>
Date: Wed, 7 May 2025 19:29:15 +0000
From: Steve Broshar <steve@...merwirelessmedtech.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Edward J Palmer <ed@...merwirelessmedtech.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>
Subject: RE: request for help using mv88e6xxx switch driver

Thanks a million. I have an appt at 3 today so I may not get very far with trying your suggestions before then but I will get to it.

This is the most useful info we've gotten about the driver.

-steve

-----Original Message-----
From: Andrew Lunn <andrew@...n.ch> 
Sent: Wednesday, May 7, 2025 2:18 PM
To: Steve Broshar <steve@...merwirelessmedtech.com>
Cc: Edward J Palmer <ed@...merwirelessmedtech.com>; 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