[RFC PATCH v3 net-next 00/10] Validate OF nodes for DSA shared ports

[RFC PATCH v3 net-next 00/10] Validate OF nodes for DSA shared ports

[Vladimir Oltean]

This is the first set of measures taken so that more drivers can be
transitioned towards phylink on shared (CPU and DSA) ports some time in
the future. It consists of:

- expanding the DT schema for DSA and related drivers to clarify the new
  requirements.

- introducing warnings for drivers that currently skip phylink due to
  incomplete DT descriptions.

- introducing warning for drivers that currently skip phylink due to
  using platform data (search for struct dsa_chip_data).

- closing the possibility for new(ish) drivers to skip phylink, by
  validating their DT descriptions.

- making the code paths used by shared ports more evident.

- preparing the code paths used by shared ports for further work to fake
  a link description where that is possible.

More details in patch 10/10.

DT binding (patches 1-6) and kernel (7-10) are in principle separable,
but are submitted together since they're part of the same story.

Patches 8 and 9 are DSA cleanups, and patch 7 is a dependency for patch
10.

Submitting as RFC because it's RFC season, but I'd like to resend this
for proper inclusion as soon as possible once the merge window closes,
so ACKs/NACKs are welcome.

Change log in patches.

v1 at
https://patchwork.kernel.org/project/netdevbpf/patch/20220723164635.1621911-1-vladimir.oltean@nxp.com/

v2 at
https://patchwork.kernel.org/project/netdevbpf/patch/20220729132119.1191227-5-vladimir.oltean@nxp.com/

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>

Vladimir Oltean (10):
  dt-bindings: net: dsa: xrs700x: add missing CPU port phy-mode to
    example
  dt-bindings: net: dsa: hellcreek: add missing CPU port
    phy-mode/fixed-link to example
  dt-bindings: net: dsa: b53: add missing CPU port phy-mode to example
  dt-bindings: net: dsa: microchip: add missing CPU port phy-mode to
    example
  dt-bindings: net: dsa: rzn1-a5psw: add missing CPU port phy-mode to
    example
  dt-bindings: net: dsa: make phylink bindings required for CPU/DSA
    ports
  of: base: export of_device_compatible_match() for use in modules
  net: dsa: avoid dsa_port_link_{,un}register_of() calls with platform
    data
  net: dsa: rename dsa_port_link_{,un}register_of
  net: dsa: make phylink-related OF properties mandatory on DSA and CPU
    ports

 .../bindings/net/dsa/arrow,xrs700x.yaml       |   2 +
 .../devicetree/bindings/net/dsa/brcm,b53.yaml |   2 +
 .../devicetree/bindings/net/dsa/dsa-port.yaml |  17 ++
 .../net/dsa/hirschmann,hellcreek.yaml         |   6 +
 .../bindings/net/dsa/microchip,ksz.yaml       |   4 +
 .../bindings/net/dsa/renesas,rzn1-a5psw.yaml  |   2 +
 drivers/of/base.c                             |   1 +
 net/dsa/dsa2.c                                |  36 +++-
 net/dsa/dsa_priv.h                            |   4 +-
 net/dsa/port.c                                | 193 ++++++++++++++++--
 10 files changed, 240 insertions(+), 27 deletions(-)

-- 
2.34.1

[RFC PATCH v3 net-next 01/10] dt-bindings: net: dsa: xrs700x: add missing CPU port phy-mode to example

[Vladimir Oltean]

Judging by xrs700x_phylink_get_caps(), I deduce that this switch
supports the RGMII modes on port 3, so state this phy-mode in the
example, such that users are encouraged to not rely on avoiding phylink
for this port.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: patch is new

 Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
index 3f01b65f3b22..eb01a8f37ce4 100644
--- a/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
@@ -63,6 +63,8 @@ examples:
                     reg = <3>;
                     label = "cpu";
                     ethernet = <&fec1>;
+                    phy-mode = "rgmii-id";
+
                     fixed-link {
                         speed = <1000>;
                         full-duplex;
-- 
2.34.1

[RFC PATCH v3 net-next 02/10] dt-bindings: net: dsa: hellcreek: add missing CPU port phy-mode/fixed-link to example

[Vladimir Oltean]

Looking at hellcreek_phylink_get_caps(), I see that depending on whether
is_100_mbits is set, speeds of 1G or of 100M will be advertised. The
de1soc_r1_pdata sets is_100_mbits to true.

The PHY modes declared in the capabilities are MII, RGMII and GMII. GMII
doesn't support 100Mbps, and as for RGMII, it would be a bit implausible
to me to support this PHY mode but limit it to only 25 MHz. So I've
settled on MII as a phy-mode in the example, and a fixed-link of
100Mbps.

As a side note, there exists such a thing as "rev-mii", because the MII
protocol is asymmetric, and "mii" is the designation for the MAC side
(expected to be connected to a PHY), and "rev-mii" is the designation
for the PHY side (expected to be connected to a MAC). I wonder whether
"mii" or "rev-mii" should actually be used here, since this is a CPU
port and presumably connected to another MAC.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: patch is new

 .../devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml   | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
index 228683773151..1ff44dd68a61 100644
--- a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
@@ -93,6 +93,12 @@ examples:
                     reg = <0>;
                     label = "cpu";
                     ethernet = <&gmac0>;
+                    phy-mode = "mii";
+
+                    fixed-link {
+                        speed = <100>;
+                        full-duplex;
+                    };
                 };
 
                 port@2 {
-- 
2.34.1

[RFC PATCH v3 net-next 03/10] dt-bindings: net: dsa: b53: add missing CPU port phy-mode to example

[Vladimir Oltean]

Looking at b53_srab_phylink_get_caps() I get no indication of what PHY
modes does port 8 support, since it is implemented circularly based on
the p->mode retrieved from the device tree (and in PHY_INTERFACE_MODE_NA
it reports nothing to supported_interfaces).

However if I look at the b53_switch_chips[] element for BCM58XX_DEVICE_ID,
I see that port 8 is the IMP port, and SRAB means the IMP port is
internal to the SoC. So use phy-mode = "internal" in the example.

Note that this will make b53_srab_phylink_get_caps() go through the
"default" case and report PHY_INTERFACE_MODE_INTERNAL to
supported_interfaces, which is probably a good thing.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: patch is new

 Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
index 23114d691d2a..2e01371b8288 100644
--- a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
@@ -254,6 +254,8 @@ examples:
                     ethernet = <&amac2>;
                     label = "cpu";
                     reg = <8>;
+                    phy-mode = "internal";
+
                     fixed-link {
                         speed = <1000>;
                         full-duplex;
-- 
2.34.1

[RFC PATCH v3 net-next 04/10] dt-bindings: net: dsa: microchip: add missing CPU port phy-mode to example

[Vladimir Oltean]

The ksz_switch_chips[] element for KSZ9477 says that port 5 is an xMII
port and it supports speeds of 10/100/1000. The device tree example does
declare a fixed-link at 1000, and RGMII is the only one of those modes
that supports this speed, so use this phy-mode.

The microchip,ksz8565 compatible string is not supported by the
microchip driver, however on Microchip's product page it says that there
are 5 ports, 4 of which have internal PHYs and the 5th is an
MII/RMII/RGMII port. It's a bit strange that this is port@6, but it is
probably just the way it is. Select an RGMII phy-mode for this one as
well.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: patch is new

 Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
index 6bbd8145b6c1..456802affc9d 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@@ -109,6 +109,8 @@ examples:
                     reg = <5>;
                     label = "cpu";
                     ethernet = <&eth0>;
+                    phy-mode = "rgmii";
+
                     fixed-link {
                         speed = <1000>;
                         full-duplex;
@@ -146,6 +148,8 @@ examples:
                     reg = <6>;
                     label = "cpu";
                     ethernet = <&eth0>;
+                    phy-mode = "rgmii";
+
                     fixed-link {
                         speed = <1000>;
                         full-duplex;
-- 
2.34.1

[RFC PATCH v3 net-next 05/10] dt-bindings: net: dsa: rzn1-a5psw: add missing CPU port phy-mode to example

[Vladimir Oltean]

To prevent warnings during "make dt_bindings_check" after dsa-port.yaml
will make phylink properties mandatory, add phy-mode = "internal" to the
example.

This new property is taken straight out of the SoC dtsi at
arch/arm/boot/dts/r9a06g032.dtsi, so it seems likely that only the
example needs to be fixed, rather than DT blobs in circulation.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: patch is new

 .../devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml         | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
index 4d428f5ad044..14a1f0b4c32b 100644
--- a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
@@ -131,6 +131,8 @@ examples:
                 reg = <4>;
                 ethernet = <&gmac2>;
                 label = "cpu";
+                phy-mode = "internal";
+
                 fixed-link {
                   speed = <1000>;
                   full-duplex;
-- 
2.34.1

[RFC PATCH v3 net-next 06/10] dt-bindings: net: dsa: make phylink bindings required for CPU/DSA ports

[Vladimir Oltean]

It is desirable that new DSA drivers are written to expect that all
their ports register with phylink, and not rely on the DSA core's
workarounds to skip this process.

To that end, DSA is being changed to warn existing drivers when such DT
blobs are in use, and to opt new drivers out of the workarounds.

Introduce another layer of validation in the DSA DT schema, and assert
that CPU and DSA ports must have phylink-related properties present.

Suggested-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: patch is new

 .../devicetree/bindings/net/dsa/dsa-port.yaml   | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
index 09317e16cb5d..10ad7e71097b 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
@@ -76,6 +76,23 @@ properties:
 required:
   - reg
 
+# CPU and DSA ports must have phylink-compatible link descriptions
+if:
+  oneOf:
+    - required: [ ethernet ]
+    - required: [ link ]
+then:
+  allOf:
+    - required:
+        - phy-mode
+    - oneOf:
+        - required:
+            - fixed-link
+        - required:
+            - phy-handle
+        - required:
+            - managed
+
 additionalProperties: true
 
 ...
-- 
2.34.1

[RFC PATCH v3 net-next 07/10] of: base: export of_device_compatible_match() for use in modules

[Vladimir Oltean]

Modules such as net/dsa/dsa_core.ko might want to iterate through an
array of compatible strings for things such as validation (or rather,
skipping it for some potentially broken drivers).

of_device_is_compatible() is exported, by of_device_compatible_match()
isn't. Export the latter as well, so we don't have to open-code the
iteration.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: patch is new
v2->v3: none

 drivers/of/base.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4f98c8469ed..5abd8fecaba2 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -578,6 +578,7 @@ int of_device_compatible_match(struct device_node *device,
 
 	return score;
 }
+EXPORT_SYMBOL_GPL(of_device_compatible_match);
 
 /**
  * of_machine_is_compatible - Test root of device tree for a given compatible value
-- 
2.34.1

[RFC PATCH v3 net-next 08/10] net: dsa: avoid dsa_port_link_{,un}register_of() calls with platform data

[Vladimir Oltean]

dsa_port_link_register_of() and dsa_port_link_unregister_of() are not
written with the fact in mind that they can be called with a dp->dn that
is NULL (as evidenced even by the _of suffix in their name), but this is
exactly what happens.

How this behaves will differ depending on whether the backing driver
implements ->adjust_link() or not.

If it doesn't, the "if (of_phy_is_fixed_link(dp->dn) || phy_np)"
condition will return false, and dsa_port_link_register_of() will do
nothing and return 0.

If the driver does implement ->adjust_link(), the
"if (of_phy_is_fixed_link(dp->dn))" condition will return false
(dp->dn is NULL) and we will call dsa_port_setup_phy_of(). This will
call dsa_port_get_phy_device(), which will also return NULL, and we will
also do nothing and return 0.

It is hard to maintain this code and make future changes to it in this
state, so just suppress calls to these 2 functions if dp->dn is NULL.
The only functional effect is that if the driver does implement
->adjust_link(), we'll stop printing this to the console:

Using legacy PHYLIB callbacks. Please migrate to PHYLINK!

but instead we'll always print:

[    8.539848] dsa-loop fixed-0:1f: skipping link registration for CPU port 5

This is for the better anyway, since "using legacy phylib callbacks"
was misleading information - we weren't issuing _any_ callbacks due to
dsa_port_get_phy_device() returning NULL.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: patch is new
v2->v3: none

 net/dsa/dsa2.c | 34 ++++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index cac48a741f27..12479707bf96 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -469,10 +469,16 @@ static int dsa_port_setup(struct dsa_port *dp)
 		dsa_port_disable(dp);
 		break;
 	case DSA_PORT_TYPE_CPU:
-		err = dsa_port_link_register_of(dp);
-		if (err)
-			break;
-		dsa_port_link_registered = true;
+		if (dp->dn) {
+			err = dsa_port_link_register_of(dp);
+			if (err)
+				break;
+			dsa_port_link_registered = true;
+		} else {
+			dev_warn(ds->dev,
+				 "skipping link registration for CPU port %d\n",
+				 dp->index);
+		}
 
 		err = dsa_port_enable(dp, NULL);
 		if (err)
@@ -481,10 +487,16 @@ static int dsa_port_setup(struct dsa_port *dp)
 
 		break;
 	case DSA_PORT_TYPE_DSA:
-		err = dsa_port_link_register_of(dp);
-		if (err)
-			break;
-		dsa_port_link_registered = true;
+		if (dp->dn) {
+			err = dsa_port_link_register_of(dp);
+			if (err)
+				break;
+			dsa_port_link_registered = true;
+		} else {
+			dev_warn(ds->dev,
+				 "skipping link registration for DSA port %d\n",
+				 dp->index);
+		}
 
 		err = dsa_port_enable(dp, NULL);
 		if (err)
@@ -577,11 +589,13 @@ static void dsa_port_teardown(struct dsa_port *dp)
 		break;
 	case DSA_PORT_TYPE_CPU:
 		dsa_port_disable(dp);
-		dsa_port_link_unregister_of(dp);
+		if (dp->dn)
+			dsa_port_link_unregister_of(dp);
 		break;
 	case DSA_PORT_TYPE_DSA:
 		dsa_port_disable(dp);
-		dsa_port_link_unregister_of(dp);
+		if (dp->dn)
+			dsa_port_link_unregister_of(dp);
 		break;
 	case DSA_PORT_TYPE_USER:
 		if (dp->slave) {
-- 
2.34.1

[RFC PATCH v3 net-next 09/10] net: dsa: rename dsa_port_link_{,un}register_of

[Vladimir Oltean]

There is a subset of functions that applies only to shared (DSA and CPU)
ports, yet this is difficult to comprehend by looking at their code alone.
These are dsa_port_link_register_of(), dsa_port_link_unregister_of(),
and the functions that only these 2 call.

Rename this class of functions to dsa_shared_port_* to make this fact
more evident, even if this goes against the apparent convention that
function names in port.c must start with dsa_port_.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: patch is new
v2->v3: none

 net/dsa/dsa2.c     | 10 +++++-----
 net/dsa/dsa_priv.h |  4 ++--
 net/dsa/port.c     | 18 +++++++++---------
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 12479707bf96..055a6d1d4372 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -470,7 +470,7 @@ static int dsa_port_setup(struct dsa_port *dp)
 		break;
 	case DSA_PORT_TYPE_CPU:
 		if (dp->dn) {
-			err = dsa_port_link_register_of(dp);
+			err = dsa_shared_port_link_register_of(dp);
 			if (err)
 				break;
 			dsa_port_link_registered = true;
@@ -488,7 +488,7 @@ static int dsa_port_setup(struct dsa_port *dp)
 		break;
 	case DSA_PORT_TYPE_DSA:
 		if (dp->dn) {
-			err = dsa_port_link_register_of(dp);
+			err = dsa_shared_port_link_register_of(dp);
 			if (err)
 				break;
 			dsa_port_link_registered = true;
@@ -517,7 +517,7 @@ static int dsa_port_setup(struct dsa_port *dp)
 	if (err && dsa_port_enabled)
 		dsa_port_disable(dp);
 	if (err && dsa_port_link_registered)
-		dsa_port_link_unregister_of(dp);
+		dsa_shared_port_link_unregister_of(dp);
 	if (err) {
 		if (ds->ops->port_teardown)
 			ds->ops->port_teardown(ds, dp->index);
@@ -590,12 +590,12 @@ static void dsa_port_teardown(struct dsa_port *dp)
 	case DSA_PORT_TYPE_CPU:
 		dsa_port_disable(dp);
 		if (dp->dn)
-			dsa_port_link_unregister_of(dp);
+			dsa_shared_port_link_unregister_of(dp);
 		break;
 	case DSA_PORT_TYPE_DSA:
 		dsa_port_disable(dp);
 		if (dp->dn)
-			dsa_port_link_unregister_of(dp);
+			dsa_shared_port_link_unregister_of(dp);
 		break;
 	case DSA_PORT_TYPE_USER:
 		if (dp->slave) {
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index d9722e49864b..8924366467e0 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -285,8 +285,8 @@ int dsa_port_mrp_add_ring_role(const struct dsa_port *dp,
 int dsa_port_mrp_del_ring_role(const struct dsa_port *dp,
 			       const struct switchdev_obj_ring_role_mrp *mrp);
 int dsa_port_phylink_create(struct dsa_port *dp);
-int dsa_port_link_register_of(struct dsa_port *dp);
-void dsa_port_link_unregister_of(struct dsa_port *dp);
+int dsa_shared_port_link_register_of(struct dsa_port *dp);
+void dsa_shared_port_link_unregister_of(struct dsa_port *dp);
 int dsa_port_hsr_join(struct dsa_port *dp, struct net_device *hsr);
 void dsa_port_hsr_leave(struct dsa_port *dp, struct net_device *hsr);
 int dsa_port_tag_8021q_vlan_add(struct dsa_port *dp, u16 vid, bool broadcast);
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2dd76eb1621c..4b6139bff217 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -1552,7 +1552,7 @@ int dsa_port_phylink_create(struct dsa_port *dp)
 	return 0;
 }
 
-static int dsa_port_setup_phy_of(struct dsa_port *dp, bool enable)
+static int dsa_shared_port_setup_phy_of(struct dsa_port *dp, bool enable)
 {
 	struct dsa_switch *ds = dp->ds;
 	struct phy_device *phydev;
@@ -1590,7 +1590,7 @@ static int dsa_port_setup_phy_of(struct dsa_port *dp, bool enable)
 	return err;
 }
 
-static int dsa_port_fixed_link_register_of(struct dsa_port *dp)
+static int dsa_shared_port_fixed_link_register_of(struct dsa_port *dp)
 {
 	struct device_node *dn = dp->dn;
 	struct dsa_switch *ds = dp->ds;
@@ -1624,7 +1624,7 @@ static int dsa_port_fixed_link_register_of(struct dsa_port *dp)
 	return 0;
 }
 
-static int dsa_port_phylink_register(struct dsa_port *dp)
+static int dsa_shared_port_phylink_register(struct dsa_port *dp)
 {
 	struct dsa_switch *ds = dp->ds;
 	struct device_node *port_dn = dp->dn;
@@ -1650,7 +1650,7 @@ static int dsa_port_phylink_register(struct dsa_port *dp)
 	return err;
 }
 
-int dsa_port_link_register_of(struct dsa_port *dp)
+int dsa_shared_port_link_register_of(struct dsa_port *dp)
 {
 	struct dsa_switch *ds = dp->ds;
 	struct device_node *phy_np;
@@ -1663,7 +1663,7 @@ int dsa_port_link_register_of(struct dsa_port *dp)
 				ds->ops->phylink_mac_link_down(ds, port,
 					MLO_AN_FIXED, PHY_INTERFACE_MODE_NA);
 			of_node_put(phy_np);
-			return dsa_port_phylink_register(dp);
+			return dsa_shared_port_phylink_register(dp);
 		}
 		of_node_put(phy_np);
 		return 0;
@@ -1673,12 +1673,12 @@ int dsa_port_link_register_of(struct dsa_port *dp)
 		 "Using legacy PHYLIB callbacks. Please migrate to PHYLINK!\n");
 
 	if (of_phy_is_fixed_link(dp->dn))
-		return dsa_port_fixed_link_register_of(dp);
+		return dsa_shared_port_fixed_link_register_of(dp);
 	else
-		return dsa_port_setup_phy_of(dp, true);
+		return dsa_shared_port_setup_phy_of(dp, true);
 }
 
-void dsa_port_link_unregister_of(struct dsa_port *dp)
+void dsa_shared_port_link_unregister_of(struct dsa_port *dp)
 {
 	struct dsa_switch *ds = dp->ds;
 
@@ -1694,7 +1694,7 @@ void dsa_port_link_unregister_of(struct dsa_port *dp)
 	if (of_phy_is_fixed_link(dp->dn))
 		of_phy_deregister_fixed_link(dp->dn);
 	else
-		dsa_port_setup_phy_of(dp, false);
+		dsa_shared_port_setup_phy_of(dp, false);
 }
 
 int dsa_port_hsr_join(struct dsa_port *dp, struct net_device *hsr)
-- 
2.34.1

[RFC PATCH v3 net-next 10/10] net: dsa: make phylink-related OF properties mandatory on DSA and CPU ports

[Vladimir Oltean]

Early DSA drivers were kind of simplistic in that they assumed a fairly
narrow hardware layout. User ports would have integrated PHYs at an
internal MDIO address that is derivable from the port number, and shared
(DSA and CPU) ports would have an MII-style (serial or parallel)
connection to another MAC. Phylib and then phylink were used to drive
the internal PHYs, and this needed little to no description through the
platform data structures. Bringing up the shared ports at the maximum
supported link speed was the responsibility of the drivers.

As a result of this, when these early drivers were converted from
platform data to the new DSA OF bindings, there was no link information
translated into the first DT bindings.

https://lore.kernel.org/all/YtXFtTsf++AeDm1l@lunn.ch/

Later, phylink was adopted for shared ports as well, and today we have a
workaround in place, introduced by commit a20f997010c4 ("net: dsa: Don't
instantiate phylink for CPU/DSA ports unless needed"). There, DSA checks
for the presence of phy-handle/fixed-link/managed OF properties, and if
missing, phylink registration would be skipped. This is because phylink
is optional for some drivers (the shared ports already work without it),
but the process of starting to register a port with phylink is
irreversible: if phylink_create() fails to find the fwnode properties it
needs, it bails out and it leaves the ports inoperational (because
phylink expects ports to be initially down, so DSA necessarily takes
them down, and doesn't know how to put them back up again).

DSA being a common framework, new drivers opt into this workaround
willy-nilly, but the ideal behavior from the DSA core's side would have
been to not interfere with phylink's process of failing at all. This
isn't possible because of regression concerns with pre-phylink DT blobs,
but at least DSA should put a stop to the proliferation of more of such
cases that rely on the workaround to skip phylink registration, and
sanitize the environment that new drivers work in.

To that end, create a list of compatible strings for which the
workaround is preserved, and don't apply the workaround for any drivers
outside that list (this includes new drivers).

In some cases, we make the assumption that even existing drivers don't
rely on DSA's workaround, and we do this by looking at the device trees
in which they appear. We can't fully know what is the situation with
downstream DT blobs, but we can guess the overall trend by studying the
DT blobs that were submitted upstream. If there are upstream blobs that
have lacking descriptions, we take it as very likely that there are many
more downstream blobs that do so too. If all upstream blobs have
complete descriptions, we take that as a hint that the driver is a
candidate for strict validation (considering that most bindings are
copy-pasted). If there are no upstream DT blobs, we take the
conservative route of skipping validation, unless the driver maintainer
instructs us otherwise.

The driver situation is as follows:

ar9331
~~~~~~

    compatible strings:
    - qca,ar9331-switch

    1 occurrence in mainline device trees, part of SoC dtsi
    (arch/mips/boot/dts/qca/ar9331.dtsi), description is not problematic.

    Verdict: opt into validation.

b53
~~~

    compatible strings:
    - brcm,bcm5325
    - brcm,bcm53115
    - brcm,bcm53125
    - brcm,bcm53128
    - brcm,bcm5365
    - brcm,bcm5389
    - brcm,bcm5395
    - brcm,bcm5397
    - brcm,bcm5398

    - brcm,bcm53010-srab
    - brcm,bcm53011-srab
    - brcm,bcm53012-srab
    - brcm,bcm53018-srab
    - brcm,bcm53019-srab
    - brcm,bcm5301x-srab
    - brcm,bcm11360-srab
    - brcm,bcm58522-srab
    - brcm,bcm58525-srab
    - brcm,bcm58535-srab
    - brcm,bcm58622-srab
    - brcm,bcm58623-srab
    - brcm,bcm58625-srab
    - brcm,bcm88312-srab
    - brcm,cygnus-srab
    - brcm,nsp-srab
    - brcm,omega-srab

    - brcm,bcm3384-switch
    - brcm,bcm6328-switch
    - brcm,bcm6368-switch
    - brcm,bcm63xx-switch

    I've found at least these mainline DT blobs with problems:

    arch/arm/boot/dts/bcm47094-linksys-panamera.dts
    - lacks phy-mode
    arch/arm/boot/dts/bcm47189-tenda-ac9.dts
    - lacks phy-mode and fixed-link
    arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts
    arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts
    arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
    - lacks phy-mode and fixed-link
    arch/arm/boot/dts/bcm47094-luxul-xbr-4500.dts
    arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
    arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
    arch/arm/boot/dts/bcm953012er.dts
    arch/arm/boot/dts/bcm4708-netgear-r6250.dts
    arch/arm/boot/dts/bcm4708-buffalo-wzr-1166dhp-common.dtsi
    arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
    arch/arm/boot/dts/bcm47094-luxul-abr-4500.dts
    - lacks phy-mode and fixed-link
    arch/arm/boot/dts/bcm53016-meraki-mr32.dts
    - lacks phy-mode

    Verdict: opt all switches out of strict validation.

bcm_sf2
~~~~~~~

    compatible strings:
    - brcm,bcm4908-switch
    - brcm,bcm7445-switch-v4.0
    - brcm,bcm7278-switch-v4.0
    - brcm,bcm7278-switch-v4.8

    A single occurrence in mainline
    (arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi), part of a SoC
    dtsi, valid description. Florian Fainelli explains that most of the
    bcm_sf2 device trees lack a full description for the internal IMP
    ports.

    Verdict: opt the BCM4908 into strict validation, and opt out the
    rest. Note that even though BCM4908 has strict DT bindings, it still
    does not register with phylink on the IMP port due to it implementing
    ->adjust_link().

hellcreek
~~~~~~~~~

    compatible strings:
    - hirschmann,hellcreek-de1soc-r1

    No occurrence in mainline device trees. Kurt Kanzenbach confirms
    that the downstream device tree lacks phy-mode and fixed link, and
    needs work.

    Verdict: opt out of validation.

lan9303
~~~~~~~

    compatible strings:
    - smsc,lan9303-mdio
    - smsc,lan9303-i2c

    1 occurrence in mainline device trees:
    arch/arm/boot/dts/imx53-kp-hsc.dts
    - no phy-mode, no fixed-link

    Verdict: opt out of validation.

lantiq_gswip
~~~~~~~~~~~~

    compatible strings:
    - lantiq,xrx200-gswip
    - lantiq,xrx300-gswip
    - lantiq,xrx330-gswip

    No occurrences in mainline device trees. Martin Blumenstingl
    confirms that the downstream OpenWrt device trees lack a proper
    fixed-link and need work, and that the incomplete description can
    even be seen in the example from
    Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt.

    Verdict: opt out of validation.

microchip ksz
~~~~~~~~~~~~~

    compatible strings:
    - microchip,ksz8765
    - microchip,ksz8794
    - microchip,ksz8795
    - microchip,ksz8863
    - microchip,ksz8873
    - microchip,ksz9477
    - microchip,ksz9897
    - microchip,ksz9893
    - microchip,ksz9563
    - microchip,ksz8563
    - microchip,ksz9567
    - microchip,lan9370
    - microchip,lan9371
    - microchip,lan9372
    - microchip,lan9373
    - microchip,lan9374

    5 occurrences in mainline device trees, all descriptions are valid.
    But we had a snafu for the ksz8795 and ksz9477 drivers where the
    phy-mode property would be expected to be located directly under the
    'switch' node rather than under a port OF node. It was fixed by
    commit edecfa98f602 ("net: dsa: microchip: look for phy-mode in port
    nodes"). The driver still has compatibility with the old DT blobs.
    The lan937x support was added later than the above snafu was fixed,
    and even though it has support for the broken DT blobs by virtue of
    sharing a common probing function, I'll take it that its DT blobs
    are correct.

    Verdict: opt lan937x into validation, and the others out.

mt7530
~~~~~~

    compatible strings
    - mediatek,mt7621
    - mediatek,mt7530
    - mediatek,mt7531

    Multiple occurrences in mainline device trees, one is part of an SoC
    dtsi (arch/mips/boot/dts/ralink/mt7621.dtsi), all descriptions are fine.

    Verdict: opt into strict validation.

mv88e6060
~~~~~~~~~

    compatible string:
    - marvell,mv88e6060

    no occurrences in mainline, nobody knows anybody who uses it.

    Verdict: opt out of strict validation.

mv88e6xxx
~~~~~~~~~

    compatible strings:
    - marvell,mv88e6085
    - marvell,mv88e6190
    - marvell,mv88e6250

    Device trees that have incomplete descriptions of CPU or DSA ports:
    arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
    - lacks phy-mode
    arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
    - lacks phy-mode and fixed-link
    arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
    - lacks phy-mode
    arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
    - lacks phy-mode
    arch/arm/boot/dts/vf610-zii-spb4.dts
    - lacks phy-mode
    arch/arm/boot/dts/vf610-zii-cfu1.dts
    - lacks phy-mode
    arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
    - lacks phy-mode on CPU port, fixed-link on DSA ports
    arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
    - lacks phy-mode on CPU port
    arch/arm/boot/dts/armada-381-netgear-gs110emx.dts
    - lacks phy-mode
    arch/arm/boot/dts/vf610-zii-scu4-aib.dts
    - lacks fixed-link on xgmii DSA ports and/or in-band-status on
      2500base-x DSA ports, and phy-mode on CPU port
    arch/arm/boot/dts/imx6qdl-gw5904.dtsi
    - lacks phy-mode and fixed-link
    arch/arm/boot/dts/armada-385-clearfog-gtr-l8.dts
    - lacks phy-mode and fixed-link
    arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
    - lacks phy-mode
    arch/arm/boot/dts/kirkwood-dir665.dts
    - lacks phy-mode
    arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
    - lacks phy-mode
    arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
    - lacks phy-mode and fixed-link
    arch/arm/boot/dts/armada-388-clearfog.dts
    - lacks phy-mode
    arch/arm/boot/dts/armada-xp-linksys-mamba.dts
    - lacks phy-mode
    arch/arm/boot/dts/armada-385-linksys.dtsi
    - lacks phy-mode
    arch/arm/boot/dts/imx6q-b450v3.dts
    arch/arm/boot/dts/imx6q-b850v3.dts
    - has a phy-handle but not a phy-mode?
    arch/arm/boot/dts/armada-370-rd.dts
    - lacks phy-mode
    arch/arm/boot/dts/kirkwood-linksys-viper.dts
    - lacks phy-mode
    arch/arm/boot/dts/imx51-zii-rdu1.dts
    - lacks phy-mode
    arch/arm/boot/dts/imx51-zii-scu2-mezz.dts
    - lacks phy-mode
    arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
    - lacks phy-mode
    arch/arm/boot/dts/armada-385-clearfog-gtr-s4.dts
    - lacks phy-mode and fixed-link

    Verdict: opt out of validation.

ocelot
~~~~~~

    compatible strings:
    - mscc,vsc9953-switch
    - felix (arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi) is a PCI
      device, has no compatible string

    2 occurrences in mainline, both are part of SoC dtsi and complete.

    Verdict: opt into strict validation.

qca8k
~~~~~

    compatible strings:
    - qca,qca8327
    - qca,qca8328
    - qca,qca8334
    - qca,qca8337

    5 occurrences in mainline device trees, none of the descriptions are
    problematic.

    Verdict: opt into validation.

realtek
~~~~~~~

    compatible strings:
    - realtek,rtl8366rb
    - realtek,rtl8365mb

    2 occurrences in mainline, both descriptions are fine, additionally
    rtl8365mb.c has a comment "The device tree firmware should also
    specify the link partner of the extension port - either via a
    fixed-link or other phy-handle."

    Verdict: opt into validation.

rzn1_a5psw
~~~~~~~~~~

    compatible strings:
    - renesas,rzn1-a5psw

    One single occurrence, part of SoC dtsi
    (arch/arm/boot/dts/r9a06g032.dtsi), description is fine.

    Verdict: opt into validation.

sja1105
~~~~~~~

    Driver already validates its port OF nodes in
    sja1105_parse_ports_node().

    Verdict: opt into validation.

vsc73xx
~~~~~~~

    compatible strings:
    - vitesse,vsc7385
    - vitesse,vsc7388
    - vitesse,vsc7395
    - vitesse,vsc7398

    2 occurrences in mainline device trees, both descriptions are fine.

    Verdict: opt into validation.

xrs700x
~~~~~~~

    compatible strings:
    - arrow,xrs7003e
    - arrow,xrs7003f
    - arrow,xrs7004e
    - arrow,xrs7004f

    no occurrences in mainline, we don't know.

    Verdict: opt out of strict validation.

Because there is a pattern where newly added switches reuse existing
drivers more often than introducing new ones, I've opted for deciding
who gets to opt into the workaround based on an OF compatible match
table in the DSA core. The alternative would have been to add another
boolean property to struct dsa_switch, like configure_vlan_while_not_filtering.
But this avoids situations where sometimes driver maintainers obfuscate
what goes on by sharing a common probing function, and therefore making
new switches inherit old quirks.

Side note, we also warn about missing properties for drivers that rely
on the workaround. This isn't an indication that we'll break
compatibility with those DT blobs any time soon, but is rather done to
raise awareness about the change, for future DT blob authors.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Acked-by: Alvin Šipraga <alsi@bang-olufsen.dk> # realtek
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: print warnings even for drivers skipping phylink registration,
        move code placement
v2->v3: reword commit message

 net/dsa/port.c | 175 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 170 insertions(+), 5 deletions(-)

diff --git a/net/dsa/port.c b/net/dsa/port.c
index 4b6139bff217..c07a7c69d5e0 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -1650,22 +1650,187 @@ static int dsa_shared_port_phylink_register(struct dsa_port *dp)
 	return err;
 }
 
+/* During the initial DSA driver migration to OF, port nodes were sometimes
+ * added to device trees with no indication of how they should operate from a
+ * link management perspective (phy-handle, fixed-link, etc). Additionally, the
+ * phy-mode may be absent. The interpretation of these port OF nodes depends on
+ * their type.
+ *
+ * User ports with no phy-handle or fixed-link are expected to connect to an
+ * internal PHY located on the ds->slave_mii_bus at an MDIO address equal to
+ * the port number. This description is still actively supported.
+ *
+ * Shared (CPU and DSA) ports with no phy-handle or fixed-link are expected to
+ * operate at the maximum speed that their phy-mode is capable of. If the
+ * phy-mode is absent, they are expected to operate using the phy-mode
+ * supported by the port that gives the highest link speed. It is unspecified
+ * if the port should use flow control or not, half duplex or full duplex, or
+ * if the phy-mode is a SERDES link, whether in-band autoneg is expected to be
+ * enabled or not.
+ *
+ * In the latter case of shared ports, omitting the link management description
+ * from the firmware node is deprecated and strongly discouraged. DSA uses
+ * phylink, which rejects the firmware nodes of these ports for lacking
+ * required properties.
+ *
+ * For switches in this table, DSA will skip enforcing validation and will
+ * later omit registering a phylink instance for the shared ports, if they lack
+ * a fixed-link, a phy-handle, or a managed = "in-band-status" property.
+ * It becomes the responsibility of the driver to ensure that these ports
+ * operate at the maximum speed (whatever this means) and will interoperate
+ * with the DSA master or other cascade port, since phylink methods will not be
+ * invoked for them.
+ *
+ * If you are considering expanding this table for newly introduced switches,
+ * think again. It is OK to remove switches from this table if there aren't DT
+ * blobs in circulation which rely on defaulting the shared ports.
+ */
+static const char * const dsa_switches_dont_enforce_validation[] = {
+#if IS_ENABLED(CONFIG_NET_DSA_XRS700X)
+	"arrow,xrs7003e",
+	"arrow,xrs7003f",
+	"arrow,xrs7004e",
+	"arrow,xrs7004f",
+#endif
+#if IS_ENABLED(CONFIG_B53)
+	"brcm,bcm5325",
+	"brcm,bcm53115",
+	"brcm,bcm53125",
+	"brcm,bcm53128",
+	"brcm,bcm5365",
+	"brcm,bcm5389",
+	"brcm,bcm5395",
+	"brcm,bcm5397",
+	"brcm,bcm5398",
+	"brcm,bcm53010-srab",
+	"brcm,bcm53011-srab",
+	"brcm,bcm53012-srab",
+	"brcm,bcm53018-srab",
+	"brcm,bcm53019-srab",
+	"brcm,bcm5301x-srab",
+	"brcm,bcm11360-srab",
+	"brcm,bcm58522-srab",
+	"brcm,bcm58525-srab",
+	"brcm,bcm58535-srab",
+	"brcm,bcm58622-srab",
+	"brcm,bcm58623-srab",
+	"brcm,bcm58625-srab",
+	"brcm,bcm88312-srab",
+	"brcm,cygnus-srab",
+	"brcm,nsp-srab",
+	"brcm,omega-srab",
+	"brcm,bcm3384-switch",
+	"brcm,bcm6328-switch",
+	"brcm,bcm6368-switch",
+	"brcm,bcm63xx-switch",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_BCM_SF2)
+	"brcm,bcm7445-switch-v4.0",
+	"brcm,bcm7278-switch-v4.0",
+	"brcm,bcm7278-switch-v4.8",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_HIRSCHMANN_HELLCREEK)
+	"hirschmann,hellcreek-de1soc-r1",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_LANTIQ_GSWIP)
+	"lantiq,xrx200-gswip",
+	"lantiq,xrx300-gswip",
+	"lantiq,xrx330-gswip",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_MV88E6060)
+	"marvell,mv88e6060",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_MV88E6XXX)
+	"marvell,mv88e6085",
+	"marvell,mv88e6190",
+	"marvell,mv88e6250",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON)
+	"microchip,ksz8765",
+	"microchip,ksz8794",
+	"microchip,ksz8795",
+	"microchip,ksz8863",
+	"microchip,ksz8873",
+	"microchip,ksz9477",
+	"microchip,ksz9897",
+	"microchip,ksz9893",
+	"microchip,ksz9563",
+	"microchip,ksz8563",
+	"microchip,ksz9567",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_SMSC_LAN9303_MDIO)
+	"smsc,lan9303-mdio",
+#endif
+#if IS_ENABLED(CONFIG_NET_DSA_SMSC_LAN9303_I2C)
+	"smsc,lan9303-i2c",
+#endif
+	NULL,
+};
+
+static void dsa_shared_port_validate_of(struct dsa_port *dp,
+					bool *missing_phy_mode,
+					bool *missing_link_description)
+{
+	struct device_node *dn = dp->dn, *phy_np;
+	struct dsa_switch *ds = dp->ds;
+	phy_interface_t mode;
+
+	*missing_phy_mode = false;
+	*missing_link_description = false;
+
+	if (of_get_phy_mode(dn, &mode)) {
+		*missing_phy_mode = true;
+		dev_err(ds->dev,
+			"OF node %pOF of %s port %d lacks the required \"phy-mode\" property\n",
+			dn, dsa_port_is_cpu(dp) ? "CPU" : "DSA", dp->index);
+	}
+
+	/* Note: of_phy_is_fixed_link() also returns true for
+	 * managed = "in-band-status"
+	 */
+	if (of_phy_is_fixed_link(dn))
+		return;
+
+	phy_np = of_parse_phandle(dn, "phy-handle", 0);
+	if (phy_np) {
+		of_node_put(phy_np);
+		return;
+	}
+
+	*missing_link_description = true;
+
+	dev_err(ds->dev,
+		"OF node %pOF of %s port %d lacks the required \"phy-handle\", \"fixed-link\" or \"managed\" properties\n",
+		dn, dsa_port_is_cpu(dp) ? "CPU" : "DSA", dp->index);
+}
+
 int dsa_shared_port_link_register_of(struct dsa_port *dp)
 {
 	struct dsa_switch *ds = dp->ds;
-	struct device_node *phy_np;
+	bool missing_link_description;
+	bool missing_phy_mode;
 	int port = dp->index;
 
+	dsa_shared_port_validate_of(dp, &missing_phy_mode,
+				    &missing_link_description);
+
+	if ((missing_phy_mode || missing_link_description) &&
+	    !of_device_compatible_match(ds->dev->of_node,
+					dsa_switches_dont_enforce_validation))
+		return -EINVAL;
+
 	if (!ds->ops->adjust_link) {
-		phy_np = of_parse_phandle(dp->dn, "phy-handle", 0);
-		if (of_phy_is_fixed_link(dp->dn) || phy_np) {
+		if (missing_link_description) {
+			dev_warn(ds->dev,
+				 "Skipping phylink registration for %s port %d\n",
+				 dsa_port_is_cpu(dp) ? "CPU" : "DSA", dp->index);
+		} else {
 			if (ds->ops->phylink_mac_link_down)
 				ds->ops->phylink_mac_link_down(ds, port,
 					MLO_AN_FIXED, PHY_INTERFACE_MODE_NA);
-			of_node_put(phy_np);
+
 			return dsa_shared_port_phylink_register(dp);
 		}
-		of_node_put(phy_np);
 		return 0;
 	}
 
-- 
2.34.1

Re: [RFC PATCH v3 net-next 10/10] net: dsa: make phylink-related OF properties mandatory on DSA and CPU ports

[Christian Marangi]

On Sat, Aug 06, 2022 at 05:10:59PM +0300, Vladimir Oltean wrote:
> Early DSA drivers were kind of simplistic in that they assumed a fairly
> narrow hardware layout. User ports would have integrated PHYs at an
> internal MDIO address that is derivable from the port number, and shared
> (DSA and CPU) ports would have an MII-style (serial or parallel)
> connection to another MAC. Phylib and then phylink were used to drive
> the internal PHYs, and this needed little to no description through the
> platform data structures. Bringing up the shared ports at the maximum
> supported link speed was the responsibility of the drivers.
> 
> As a result of this, when these early drivers were converted from
> platform data to the new DSA OF bindings, there was no link information
> translated into the first DT bindings.
> 
> https://lore.kernel.org/all/YtXFtTsf++AeDm1l@lunn.ch/
> 
> Later, phylink was adopted for shared ports as well, and today we have a
> workaround in place, introduced by commit a20f997010c4 ("net: dsa: Don't
> instantiate phylink for CPU/DSA ports unless needed"). There, DSA checks
> for the presence of phy-handle/fixed-link/managed OF properties, and if
> missing, phylink registration would be skipped. This is because phylink
> is optional for some drivers (the shared ports already work without it),
> but the process of starting to register a port with phylink is
> irreversible: if phylink_create() fails to find the fwnode properties it
> needs, it bails out and it leaves the ports inoperational (because
> phylink expects ports to be initially down, so DSA necessarily takes
> them down, and doesn't know how to put them back up again).
> 
> DSA being a common framework, new drivers opt into this workaround
> willy-nilly, but the ideal behavior from the DSA core's side would have
> been to not interfere with phylink's process of failing at all. This
> isn't possible because of regression concerns with pre-phylink DT blobs,
> but at least DSA should put a stop to the proliferation of more of such
> cases that rely on the workaround to skip phylink registration, and
> sanitize the environment that new drivers work in.
> 
> To that end, create a list of compatible strings for which the
> workaround is preserved, and don't apply the workaround for any drivers
> outside that list (this includes new drivers).
> 
> In some cases, we make the assumption that even existing drivers don't
> rely on DSA's workaround, and we do this by looking at the device trees
> in which they appear. We can't fully know what is the situation with
> downstream DT blobs, but we can guess the overall trend by studying the
> DT blobs that were submitted upstream. If there are upstream blobs that
> have lacking descriptions, we take it as very likely that there are many
> more downstream blobs that do so too. If all upstream blobs have
> complete descriptions, we take that as a hint that the driver is a
> candidate for strict validation (considering that most bindings are
> copy-pasted). If there are no upstream DT blobs, we take the
> conservative route of skipping validation, unless the driver maintainer
> instructs us otherwise.
> 
> The driver situation is as follows:
> 
> ar9331
> ~~~~~~
> 
>     compatible strings:
>     - qca,ar9331-switch
> 
>     1 occurrence in mainline device trees, part of SoC dtsi
>     (arch/mips/boot/dts/qca/ar9331.dtsi), description is not problematic.
> 
>     Verdict: opt into validation.
> 
> b53
> ~~~
> 
>     compatible strings:
>     - brcm,bcm5325
>     - brcm,bcm53115
>     - brcm,bcm53125
>     - brcm,bcm53128
>     - brcm,bcm5365
>     - brcm,bcm5389
>     - brcm,bcm5395
>     - brcm,bcm5397
>     - brcm,bcm5398
> 
>     - brcm,bcm53010-srab
>     - brcm,bcm53011-srab
>     - brcm,bcm53012-srab
>     - brcm,bcm53018-srab
>     - brcm,bcm53019-srab
>     - brcm,bcm5301x-srab
>     - brcm,bcm11360-srab
>     - brcm,bcm58522-srab
>     - brcm,bcm58525-srab
>     - brcm,bcm58535-srab
>     - brcm,bcm58622-srab
>     - brcm,bcm58623-srab
>     - brcm,bcm58625-srab
>     - brcm,bcm88312-srab
>     - brcm,cygnus-srab
>     - brcm,nsp-srab
>     - brcm,omega-srab
> 
>     - brcm,bcm3384-switch
>     - brcm,bcm6328-switch
>     - brcm,bcm6368-switch
>     - brcm,bcm63xx-switch
> 
>     I've found at least these mainline DT blobs with problems:
> 
>     arch/arm/boot/dts/bcm47094-linksys-panamera.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/bcm47189-tenda-ac9.dts
>     - lacks phy-mode and fixed-link
>     arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts
>     arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts
>     arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
>     - lacks phy-mode and fixed-link
>     arch/arm/boot/dts/bcm47094-luxul-xbr-4500.dts
>     arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
>     arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
>     arch/arm/boot/dts/bcm953012er.dts
>     arch/arm/boot/dts/bcm4708-netgear-r6250.dts
>     arch/arm/boot/dts/bcm4708-buffalo-wzr-1166dhp-common.dtsi
>     arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
>     arch/arm/boot/dts/bcm47094-luxul-abr-4500.dts
>     - lacks phy-mode and fixed-link
>     arch/arm/boot/dts/bcm53016-meraki-mr32.dts
>     - lacks phy-mode
> 
>     Verdict: opt all switches out of strict validation.
> 
> bcm_sf2
> ~~~~~~~
> 
>     compatible strings:
>     - brcm,bcm4908-switch
>     - brcm,bcm7445-switch-v4.0
>     - brcm,bcm7278-switch-v4.0
>     - brcm,bcm7278-switch-v4.8
> 
>     A single occurrence in mainline
>     (arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi), part of a SoC
>     dtsi, valid description. Florian Fainelli explains that most of the
>     bcm_sf2 device trees lack a full description for the internal IMP
>     ports.
> 
>     Verdict: opt the BCM4908 into strict validation, and opt out the
>     rest. Note that even though BCM4908 has strict DT bindings, it still
>     does not register with phylink on the IMP port due to it implementing
>     ->adjust_link().
> 
> hellcreek
> ~~~~~~~~~
> 
>     compatible strings:
>     - hirschmann,hellcreek-de1soc-r1
> 
>     No occurrence in mainline device trees. Kurt Kanzenbach confirms
>     that the downstream device tree lacks phy-mode and fixed link, and
>     needs work.
> 
>     Verdict: opt out of validation.
> 
> lan9303
> ~~~~~~~
> 
>     compatible strings:
>     - smsc,lan9303-mdio
>     - smsc,lan9303-i2c
> 
>     1 occurrence in mainline device trees:
>     arch/arm/boot/dts/imx53-kp-hsc.dts
>     - no phy-mode, no fixed-link
> 
>     Verdict: opt out of validation.
> 
> lantiq_gswip
> ~~~~~~~~~~~~
> 
>     compatible strings:
>     - lantiq,xrx200-gswip
>     - lantiq,xrx300-gswip
>     - lantiq,xrx330-gswip
> 
>     No occurrences in mainline device trees. Martin Blumenstingl
>     confirms that the downstream OpenWrt device trees lack a proper
>     fixed-link and need work, and that the incomplete description can
>     even be seen in the example from
>     Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt.
> 
>     Verdict: opt out of validation.
> 
> microchip ksz
> ~~~~~~~~~~~~~
> 
>     compatible strings:
>     - microchip,ksz8765
>     - microchip,ksz8794
>     - microchip,ksz8795
>     - microchip,ksz8863
>     - microchip,ksz8873
>     - microchip,ksz9477
>     - microchip,ksz9897
>     - microchip,ksz9893
>     - microchip,ksz9563
>     - microchip,ksz8563
>     - microchip,ksz9567
>     - microchip,lan9370
>     - microchip,lan9371
>     - microchip,lan9372
>     - microchip,lan9373
>     - microchip,lan9374
> 
>     5 occurrences in mainline device trees, all descriptions are valid.
>     But we had a snafu for the ksz8795 and ksz9477 drivers where the
>     phy-mode property would be expected to be located directly under the
>     'switch' node rather than under a port OF node. It was fixed by
>     commit edecfa98f602 ("net: dsa: microchip: look for phy-mode in port
>     nodes"). The driver still has compatibility with the old DT blobs.
>     The lan937x support was added later than the above snafu was fixed,
>     and even though it has support for the broken DT blobs by virtue of
>     sharing a common probing function, I'll take it that its DT blobs
>     are correct.
> 
>     Verdict: opt lan937x into validation, and the others out.
> 
> mt7530
> ~~~~~~
> 
>     compatible strings
>     - mediatek,mt7621
>     - mediatek,mt7530
>     - mediatek,mt7531
> 
>     Multiple occurrences in mainline device trees, one is part of an SoC
>     dtsi (arch/mips/boot/dts/ralink/mt7621.dtsi), all descriptions are fine.
> 
>     Verdict: opt into strict validation.
> 
> mv88e6060
> ~~~~~~~~~
> 
>     compatible string:
>     - marvell,mv88e6060
> 
>     no occurrences in mainline, nobody knows anybody who uses it.
> 
>     Verdict: opt out of strict validation.
> 
> mv88e6xxx
> ~~~~~~~~~
> 
>     compatible strings:
>     - marvell,mv88e6085
>     - marvell,mv88e6190
>     - marvell,mv88e6250
> 
>     Device trees that have incomplete descriptions of CPU or DSA ports:
>     arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
>     - lacks phy-mode
>     arch/arm64/boot/dts/marvell/cn9130-crb.dtsi
>     - lacks phy-mode and fixed-link
>     arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/vf610-zii-spb4.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/vf610-zii-cfu1.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
>     - lacks phy-mode on CPU port, fixed-link on DSA ports
>     arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
>     - lacks phy-mode on CPU port
>     arch/arm/boot/dts/armada-381-netgear-gs110emx.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/vf610-zii-scu4-aib.dts
>     - lacks fixed-link on xgmii DSA ports and/or in-band-status on
>       2500base-x DSA ports, and phy-mode on CPU port
>     arch/arm/boot/dts/imx6qdl-gw5904.dtsi
>     - lacks phy-mode and fixed-link
>     arch/arm/boot/dts/armada-385-clearfog-gtr-l8.dts
>     - lacks phy-mode and fixed-link
>     arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/kirkwood-dir665.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
>     - lacks phy-mode
>     arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
>     - lacks phy-mode and fixed-link
>     arch/arm/boot/dts/armada-388-clearfog.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/armada-xp-linksys-mamba.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/armada-385-linksys.dtsi
>     - lacks phy-mode
>     arch/arm/boot/dts/imx6q-b450v3.dts
>     arch/arm/boot/dts/imx6q-b850v3.dts
>     - has a phy-handle but not a phy-mode?
>     arch/arm/boot/dts/armada-370-rd.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/kirkwood-linksys-viper.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/imx51-zii-rdu1.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/imx51-zii-scu2-mezz.dts
>     - lacks phy-mode
>     arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>     - lacks phy-mode
>     arch/arm/boot/dts/armada-385-clearfog-gtr-s4.dts
>     - lacks phy-mode and fixed-link
> 
>     Verdict: opt out of validation.
> 
> ocelot
> ~~~~~~
> 
>     compatible strings:
>     - mscc,vsc9953-switch
>     - felix (arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi) is a PCI
>       device, has no compatible string
> 
>     2 occurrences in mainline, both are part of SoC dtsi and complete.
> 
>     Verdict: opt into strict validation.
> 
> qca8k
> ~~~~~
> 
>     compatible strings:
>     - qca,qca8327
>     - qca,qca8328
>     - qca,qca8334
>     - qca,qca8337
> 
>     5 occurrences in mainline device trees, none of the descriptions are
>     problematic.
> 
>     Verdict: opt into validation.

I notice some have strict validation and other simple validation. I
didn't understand from the commit description where strict is used
instead of simple one.

I'm asking this for qca8k as from what we notice with device that use
qca8k the master ports always needs to have info in dt as we reset the
switch and always need to correctly setup the port.

> 
> realtek
> ~~~~~~~
> 
>     compatible strings:
>     - realtek,rtl8366rb
>     - realtek,rtl8365mb
> 
>     2 occurrences in mainline, both descriptions are fine, additionally
>     rtl8365mb.c has a comment "The device tree firmware should also
>     specify the link partner of the extension port - either via a
>     fixed-link or other phy-handle."
> 
>     Verdict: opt into validation.
> 
> rzn1_a5psw
> ~~~~~~~~~~
> 
>     compatible strings:
>     - renesas,rzn1-a5psw
> 
>     One single occurrence, part of SoC dtsi
>     (arch/arm/boot/dts/r9a06g032.dtsi), description is fine.
> 
>     Verdict: opt into validation.
> 
> sja1105
> ~~~~~~~
> 
>     Driver already validates its port OF nodes in
>     sja1105_parse_ports_node().
> 
>     Verdict: opt into validation.
> 
> vsc73xx
> ~~~~~~~
> 
>     compatible strings:
>     - vitesse,vsc7385
>     - vitesse,vsc7388
>     - vitesse,vsc7395
>     - vitesse,vsc7398
> 
>     2 occurrences in mainline device trees, both descriptions are fine.
> 
>     Verdict: opt into validation.
> 
> xrs700x
> ~~~~~~~
> 
>     compatible strings:
>     - arrow,xrs7003e
>     - arrow,xrs7003f
>     - arrow,xrs7004e
>     - arrow,xrs7004f
> 
>     no occurrences in mainline, we don't know.
> 
>     Verdict: opt out of strict validation.
> 
> Because there is a pattern where newly added switches reuse existing
> drivers more often than introducing new ones, I've opted for deciding
> who gets to opt into the workaround based on an OF compatible match
> table in the DSA core. The alternative would have been to add another
> boolean property to struct dsa_switch, like configure_vlan_while_not_filtering.
> But this avoids situations where sometimes driver maintainers obfuscate
> what goes on by sharing a common probing function, and therefore making
> new switches inherit old quirks.
> 
> Side note, we also warn about missing properties for drivers that rely
> on the workaround. This isn't an indication that we'll break
> compatibility with those DT blobs any time soon, but is rather done to
> raise awareness about the change, for future DT blob authors.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Acked-by: Alvin Šipraga <alsi@bang-olufsen.dk> # realtek
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v1->v2: print warnings even for drivers skipping phylink registration,
>         move code placement
> v2->v3: reword commit message
> 
>  net/dsa/port.c | 175 +++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 170 insertions(+), 5 deletions(-)
> 
> diff --git a/net/dsa/port.c b/net/dsa/port.c
> index 4b6139bff217..c07a7c69d5e0 100644
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@ -1650,22 +1650,187 @@ static int dsa_shared_port_phylink_register(struct dsa_port *dp)
>  	return err;
>  }
>  
> +/* During the initial DSA driver migration to OF, port nodes were sometimes
> + * added to device trees with no indication of how they should operate from a
> + * link management perspective (phy-handle, fixed-link, etc). Additionally, the
> + * phy-mode may be absent. The interpretation of these port OF nodes depends on
> + * their type.
> + *
> + * User ports with no phy-handle or fixed-link are expected to connect to an
> + * internal PHY located on the ds->slave_mii_bus at an MDIO address equal to
> + * the port number. This description is still actively supported.
> + *
> + * Shared (CPU and DSA) ports with no phy-handle or fixed-link are expected to
> + * operate at the maximum speed that their phy-mode is capable of. If the
> + * phy-mode is absent, they are expected to operate using the phy-mode
> + * supported by the port that gives the highest link speed. It is unspecified
> + * if the port should use flow control or not, half duplex or full duplex, or
> + * if the phy-mode is a SERDES link, whether in-band autoneg is expected to be
> + * enabled or not.
> + *
> + * In the latter case of shared ports, omitting the link management description
> + * from the firmware node is deprecated and strongly discouraged. DSA uses
> + * phylink, which rejects the firmware nodes of these ports for lacking
> + * required properties.
> + *
> + * For switches in this table, DSA will skip enforcing validation and will
> + * later omit registering a phylink instance for the shared ports, if they lack
> + * a fixed-link, a phy-handle, or a managed = "in-band-status" property.
> + * It becomes the responsibility of the driver to ensure that these ports
> + * operate at the maximum speed (whatever this means) and will interoperate
> + * with the DSA master or other cascade port, since phylink methods will not be
> + * invoked for them.
> + *
> + * If you are considering expanding this table for newly introduced switches,
> + * think again. It is OK to remove switches from this table if there aren't DT
> + * blobs in circulation which rely on defaulting the shared ports.
> + */
> +static const char * const dsa_switches_dont_enforce_validation[] = {
> +#if IS_ENABLED(CONFIG_NET_DSA_XRS700X)
> +	"arrow,xrs7003e",
> +	"arrow,xrs7003f",
> +	"arrow,xrs7004e",
> +	"arrow,xrs7004f",
> +#endif
> +#if IS_ENABLED(CONFIG_B53)
> +	"brcm,bcm5325",
> +	"brcm,bcm53115",
> +	"brcm,bcm53125",
> +	"brcm,bcm53128",
> +	"brcm,bcm5365",
> +	"brcm,bcm5389",
> +	"brcm,bcm5395",
> +	"brcm,bcm5397",
> +	"brcm,bcm5398",
> +	"brcm,bcm53010-srab",
> +	"brcm,bcm53011-srab",
> +	"brcm,bcm53012-srab",
> +	"brcm,bcm53018-srab",
> +	"brcm,bcm53019-srab",
> +	"brcm,bcm5301x-srab",
> +	"brcm,bcm11360-srab",
> +	"brcm,bcm58522-srab",
> +	"brcm,bcm58525-srab",
> +	"brcm,bcm58535-srab",
> +	"brcm,bcm58622-srab",
> +	"brcm,bcm58623-srab",
> +	"brcm,bcm58625-srab",
> +	"brcm,bcm88312-srab",
> +	"brcm,cygnus-srab",
> +	"brcm,nsp-srab",
> +	"brcm,omega-srab",
> +	"brcm,bcm3384-switch",
> +	"brcm,bcm6328-switch",
> +	"brcm,bcm6368-switch",
> +	"brcm,bcm63xx-switch",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_BCM_SF2)
> +	"brcm,bcm7445-switch-v4.0",
> +	"brcm,bcm7278-switch-v4.0",
> +	"brcm,bcm7278-switch-v4.8",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_HIRSCHMANN_HELLCREEK)
> +	"hirschmann,hellcreek-de1soc-r1",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_LANTIQ_GSWIP)
> +	"lantiq,xrx200-gswip",
> +	"lantiq,xrx300-gswip",
> +	"lantiq,xrx330-gswip",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_MV88E6060)
> +	"marvell,mv88e6060",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_MV88E6XXX)
> +	"marvell,mv88e6085",
> +	"marvell,mv88e6190",
> +	"marvell,mv88e6250",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON)
> +	"microchip,ksz8765",
> +	"microchip,ksz8794",
> +	"microchip,ksz8795",
> +	"microchip,ksz8863",
> +	"microchip,ksz8873",
> +	"microchip,ksz9477",
> +	"microchip,ksz9897",
> +	"microchip,ksz9893",
> +	"microchip,ksz9563",
> +	"microchip,ksz8563",
> +	"microchip,ksz9567",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_SMSC_LAN9303_MDIO)
> +	"smsc,lan9303-mdio",
> +#endif
> +#if IS_ENABLED(CONFIG_NET_DSA_SMSC_LAN9303_I2C)
> +	"smsc,lan9303-i2c",
> +#endif
> +	NULL,
> +};
> +
> +static void dsa_shared_port_validate_of(struct dsa_port *dp,
> +					bool *missing_phy_mode,
> +					bool *missing_link_description)
> +{
> +	struct device_node *dn = dp->dn, *phy_np;
> +	struct dsa_switch *ds = dp->ds;
> +	phy_interface_t mode;
> +
> +	*missing_phy_mode = false;
> +	*missing_link_description = false;
> +
> +	if (of_get_phy_mode(dn, &mode)) {
> +		*missing_phy_mode = true;
> +		dev_err(ds->dev,
> +			"OF node %pOF of %s port %d lacks the required \"phy-mode\" property\n",
> +			dn, dsa_port_is_cpu(dp) ? "CPU" : "DSA", dp->index);
> +	}
> +
> +	/* Note: of_phy_is_fixed_link() also returns true for
> +	 * managed = "in-band-status"
> +	 */
> +	if (of_phy_is_fixed_link(dn))
> +		return;
> +
> +	phy_np = of_parse_phandle(dn, "phy-handle", 0);
> +	if (phy_np) {
> +		of_node_put(phy_np);
> +		return;
> +	}
> +
> +	*missing_link_description = true;
> +
> +	dev_err(ds->dev,
> +		"OF node %pOF of %s port %d lacks the required \"phy-handle\", \"fixed-link\" or \"managed\" properties\n",
> +		dn, dsa_port_is_cpu(dp) ? "CPU" : "DSA", dp->index);
> +}
> +
>  int dsa_shared_port_link_register_of(struct dsa_port *dp)
>  {
>  	struct dsa_switch *ds = dp->ds;
> -	struct device_node *phy_np;
> +	bool missing_link_description;
> +	bool missing_phy_mode;
>  	int port = dp->index;
>  
> +	dsa_shared_port_validate_of(dp, &missing_phy_mode,
> +				    &missing_link_description);
> +
> +	if ((missing_phy_mode || missing_link_description) &&
> +	    !of_device_compatible_match(ds->dev->of_node,
> +					dsa_switches_dont_enforce_validation))
> +		return -EINVAL;
> +
>  	if (!ds->ops->adjust_link) {
> -		phy_np = of_parse_phandle(dp->dn, "phy-handle", 0);
> -		if (of_phy_is_fixed_link(dp->dn) || phy_np) {
> +		if (missing_link_description) {
> +			dev_warn(ds->dev,
> +				 "Skipping phylink registration for %s port %d\n",
> +				 dsa_port_is_cpu(dp) ? "CPU" : "DSA", dp->index);
> +		} else {
>  			if (ds->ops->phylink_mac_link_down)
>  				ds->ops->phylink_mac_link_down(ds, port,
>  					MLO_AN_FIXED, PHY_INTERFACE_MODE_NA);
> -			of_node_put(phy_np);
> +
>  			return dsa_shared_port_phylink_register(dp);
>  		}
> -		of_node_put(phy_np);
>  		return 0;
>  	}
>  
> -- 
> 2.34.1
> 

-- 
	Ansuel

Re: [RFC PATCH v3 net-next 02/10] dt-bindings: net: dsa: hellcreek: add missing CPU port phy-mode/fixed-link to example

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Sat Aug 06 2022, Vladimir Oltean wrote:
> Looking at hellcreek_phylink_get_caps(), I see that depending on whether
> is_100_mbits is set, speeds of 1G or of 100M will be advertised. The
> de1soc_r1_pdata sets is_100_mbits to true.
>
> The PHY modes declared in the capabilities are MII, RGMII and GMII. GMII
> doesn't support 100Mbps, and as for RGMII, it would be a bit implausible
> to me to support this PHY mode but limit it to only 25 MHz. So I've
> settled on MII as a phy-mode in the example, and a fixed-link of
> 100Mbps.
>
> As a side note, there exists such a thing as "rev-mii", because the MII
> protocol is asymmetric, and "mii" is the designation for the MAC side
> (expected to be connected to a PHY), and "rev-mii" is the designation
> for the PHY side (expected to be connected to a MAC). I wonder whether
> "mii" or "rev-mii" should actually be used here, since this is a CPU
> port and presumably connected to another MAC.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [RFC PATCH v3 net-next 10/10] net: dsa: make phylink-related OF properties mandatory on DSA and CPU ports

[Vladimir Oltean]

On Sat, Aug 06, 2022 at 09:58:16PM +0200, Christian Marangi wrote:
> > qca8k
> > ~~~~~
> > 
> >     compatible strings:
> >     - qca,qca8327
> >     - qca,qca8328
> >     - qca,qca8334
> >     - qca,qca8337
> > 
> >     5 occurrences in mainline device trees, none of the descriptions are
> >     problematic.
> > 
> >     Verdict: opt into validation.
> 
> I notice some have strict validation and other simple validation. I
> didn't understand from the commit description where strict is used
> instead of simple one.

There is no difference between "opt into validation" and "opt into
strict validation" in the verdicts for each driver. It all means the
same thing, which is that we won't apply DSA's workaround to skip
phylink registration for them (and implicitly fail the probing, if they
have lacking device trees, but the assumption is that they don't).
I suppose I could improve the wording.

> I'm asking this for qca8k as from what we notice with device that use
> qca8k the master ports always needs to have info in dt as we reset the
> switch and always need to correctly setup the port.

How sure are you about this? I am noticing the following commits:
79a4ed4f0f93 ("net: dsa: qca8k: Force CPU port to its highest bandwidth")
9bb2289f90e6 ("net: dsa: qca8k: Allow overwriting CPU port setting")

which suggests at at least at some point, the qca8k driver didn't rely
on device tree information for the CPU port. Now if that information was
available in the device tree in the first place, I don't know.
The phy-mode seems to have been; I'm looking at the initial commit
6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family") and
there is an of_get_phy_mode() with a hard error on missing property for
the CPU port.

Re: [RFC PATCH v3 net-next 10/10] net: dsa: make phylink-related OF properties mandatory on DSA and CPU ports

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Sat Aug 06 2022, Vladimir Oltean wrote:
[...]
> +static const char * const dsa_switches_dont_enforce_validation[] = {
> +#if IS_ENABLED(CONFIG_NET_DSA_HIRSCHMANN_HELLCREEK)
> +	"hirschmann,hellcreek-de1soc-r1",
> +#endif

You can safely remove that one. I've updated all downstream DTS files accordingly. 

Thanks,
Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [RFC PATCH v3 net-next 01/10] dt-bindings: net: dsa: xrs700x: add missing CPU port phy-mode to example

[Rob Herring]

On Sat, 06 Aug 2022 17:10:50 +0300, Vladimir Oltean wrote:
> Judging by xrs700x_phylink_get_caps(), I deduce that this switch
> supports the RGMII modes on port 3, so state this phy-mode in the
> example, such that users are encouraged to not rely on avoiding phylink
> for this port.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v2->v3: patch is new
> 
>  Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [RFC PATCH v3 net-next 02/10] dt-bindings: net: dsa: hellcreek: add missing CPU port phy-mode/fixed-link to example

[Rob Herring]

On Sat, 06 Aug 2022 17:10:51 +0300, Vladimir Oltean wrote:
> Looking at hellcreek_phylink_get_caps(), I see that depending on whether
> is_100_mbits is set, speeds of 1G or of 100M will be advertised. The
> de1soc_r1_pdata sets is_100_mbits to true.
> 
> The PHY modes declared in the capabilities are MII, RGMII and GMII. GMII
> doesn't support 100Mbps, and as for RGMII, it would be a bit implausible
> to me to support this PHY mode but limit it to only 25 MHz. So I've
> settled on MII as a phy-mode in the example, and a fixed-link of
> 100Mbps.
> 
> As a side note, there exists such a thing as "rev-mii", because the MII
> protocol is asymmetric, and "mii" is the designation for the MAC side
> (expected to be connected to a PHY), and "rev-mii" is the designation
> for the PHY side (expected to be connected to a MAC). I wonder whether
> "mii" or "rev-mii" should actually be used here, since this is a CPU
> port and presumably connected to another MAC.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v2->v3: patch is new
> 
>  .../devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml   | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [RFC PATCH v3 net-next 03/10] dt-bindings: net: dsa: b53: add missing CPU port phy-mode to example

[Rob Herring]

On Sat, 06 Aug 2022 17:10:52 +0300, Vladimir Oltean wrote:
> Looking at b53_srab_phylink_get_caps() I get no indication of what PHY
> modes does port 8 support, since it is implemented circularly based on
> the p->mode retrieved from the device tree (and in PHY_INTERFACE_MODE_NA
> it reports nothing to supported_interfaces).
> 
> However if I look at the b53_switch_chips[] element for BCM58XX_DEVICE_ID,
> I see that port 8 is the IMP port, and SRAB means the IMP port is
> internal to the SoC. So use phy-mode = "internal" in the example.
> 
> Note that this will make b53_srab_phylink_get_caps() go through the
> "default" case and report PHY_INTERFACE_MODE_INTERNAL to
> supported_interfaces, which is probably a good thing.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v2->v3: patch is new
> 
>  Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [RFC PATCH v3 net-next 04/10] dt-bindings: net: dsa: microchip: add missing CPU port phy-mode to example

[Rob Herring]

On Sat, 06 Aug 2022 17:10:53 +0300, Vladimir Oltean wrote:
> The ksz_switch_chips[] element for KSZ9477 says that port 5 is an xMII
> port and it supports speeds of 10/100/1000. The device tree example does
> declare a fixed-link at 1000, and RGMII is the only one of those modes
> that supports this speed, so use this phy-mode.
> 
> The microchip,ksz8565 compatible string is not supported by the
> microchip driver, however on Microchip's product page it says that there
> are 5 ports, 4 of which have internal PHYs and the 5th is an
> MII/RMII/RGMII port. It's a bit strange that this is port@6, but it is
> probably just the way it is. Select an RGMII phy-mode for this one as
> well.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v2->v3: patch is new
> 
>  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [RFC PATCH v3 net-next 05/10] dt-bindings: net: dsa: rzn1-a5psw: add missing CPU port phy-mode to example

[Rob Herring]

On Sat, 06 Aug 2022 17:10:54 +0300, Vladimir Oltean wrote:
> To prevent warnings during "make dt_bindings_check" after dsa-port.yaml
> will make phylink properties mandatory, add phy-mode = "internal" to the
> example.
> 
> This new property is taken straight out of the SoC dtsi at
> arch/arm/boot/dts/r9a06g032.dtsi, so it seems likely that only the
> example needs to be fixed, rather than DT blobs in circulation.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v2->v3: patch is new
> 
>  .../devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml         | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [RFC PATCH v3 net-next 06/10] dt-bindings: net: dsa: make phylink bindings required for CPU/DSA ports

[Rob Herring]

On Sat, 06 Aug 2022 17:10:55 +0300, Vladimir Oltean wrote:
> It is desirable that new DSA drivers are written to expect that all
> their ports register with phylink, and not rely on the DSA core's
> workarounds to skip this process.
> 
> To that end, DSA is being changed to warn existing drivers when such DT
> blobs are in use, and to opt new drivers out of the workarounds.
> 
> Introduce another layer of validation in the DSA DT schema, and assert
> that CPU and DSA ports must have phylink-related properties present.
> 
> Suggested-by: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v2->v3: patch is new
> 
>  .../devicetree/bindings/net/dsa/dsa-port.yaml   | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [RFC PATCH v3 net-next 07/10] of: base: export of_device_compatible_match() for use in modules

[Rob Herring]

On Sat, 06 Aug 2022 17:10:56 +0300, Vladimir Oltean wrote:
> Modules such as net/dsa/dsa_core.ko might want to iterate through an
> array of compatible strings for things such as validation (or rather,
> skipping it for some potentially broken drivers).
> 
> of_device_is_compatible() is exported, by of_device_compatible_match()
> isn't. Export the latter as well, so we don't have to open-code the
> iteration.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v1->v2: patch is new
> v2->v3: none
> 
>  drivers/of/base.c | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [RFC PATCH v3 net-next 10/10] net: dsa: make phylink-related OF properties mandatory on DSA and CPU ports

[Vladimir Oltean]

On Tue, Aug 09, 2022 at 10:24:43AM +0200, Kurt Kanzenbach wrote:
> On Sat Aug 06 2022, Vladimir Oltean wrote:
> [...]
> > +static const char * const dsa_switches_dont_enforce_validation[] = {
> > +#if IS_ENABLED(CONFIG_NET_DSA_HIRSCHMANN_HELLCREEK)
> > +	"hirschmann,hellcreek-de1soc-r1",
> > +#endif
> 
> You can safely remove that one. I've updated all downstream DTS files accordingly.

Nice, thanks. I've removed hellcreek from the list of drivers relying on
workarounds, and probing will now fail if properties required by phylink
are found to be missing.