| 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID:
<IA1PR15MB600866E9A68ACEBABA6F1D7BB588A@IA1PR15MB6008.namprd15.prod.outlook.com>
Date: Wed, 7 May 2025 21:23:38 +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
I implemented the changes as I think you suggested.
Networking is still not working. There is no noticeable difference in the boot log messages ... although it's very long so hard to know if it's somewhat different. But, in the end, still get "No such device".
I was a bit unclear what you meant by "this is wrong". It appears after the line "phy-handle = <&swp5>", but I think that instead of that being wrong maybe you mean that a fixed-link node is missing. There was (and still is) a fixed-link node in port5, but maybe there needs to be one in both the switch node and the port5 node.
Here's the updated DT:
&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";
// 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>;
// 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>;
// enable Wake-on-LAN (WoL); aka/via magic packets
// Note: commented out since WoL is not needed and probably wouldn't work anyway
// fsl,magic-packet;
// 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 {
// Note: even though mv88e6085 is not the right part number, this selects the driver
// for the Compton switch (6320) as well as many other Marvell switches
compatible = "marvell,mv88e6085";
#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>;
// Note: Andrew Lunn, module maintainer, says fixed-link is needed here
fixed-link {
speed = <1000>;
full-duplex;
};
// cluster setup; not needed since no cluster;
// 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>;
// 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
// note: I wonder if this is not needed; maybe an obsolete setting; replaced by prop 'ethernet'
label = "cpu";
// link back to parent ethernet driver [why?]
ethernet = <&fec1>;
// media interface mode;
// Note: Andrew Lunn, module maintainer, says host port and fec should not
// both specify internal delay (rgmii-id); and further suggests using
// rgmii-id in fec and rgmii here
phy-mode = "rgmii";
// ensure a fixed link to the switch [why?]
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
};
-----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