realtek: rtl93xx: support SFPs with phys

This driver use "phy-handle" as a placeholder for mac configuration
data.  Such handles are therefore required for all ports - even those
connected directly to SFP slots and having a managed property set to
"in-band-status".

The DSA core will register these nodes as if they are real phys. This
prevents later attachment of pluggable phys with errors like

   sfp sfp-p8: sfp_add_phy failed: -EBUSY

Replace the virtual SFP slot handles with "pseudo-phy-handle" to keep
the driver logic as-is but hide the node from the DSA core.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Link: https://github.com/openwrt/openwrt/pull/17950
Signed-off-by: Sander Vanheule <sander@svanheule.net>

diff --git a/target/linux/realtek/dts/rtl9302_zyxel_xgs1250-12.dts b/target/linux/realtek/dts/rtl9302_zyxel_xgs1250-12.dts
index d7252c9984a692a84aafe7eaddc90b520bd90466..aa485113725fa2c8b5383313ef9ae1c77b135df1 100644 (file)
--- a/target/linux/realtek/dts/rtl9302_zyxel_xgs1250-12.dts
+++ b/target/linux/realtek/dts/rtl9302_zyxel_xgs1250-12.dts
@@ -404,7 +404,7 @@
                        reg = <27>;
                        label = "lan12";
                        phy-mode = "1000base-x";
-                       phy-handle = <&phy27>;
+                       pseudo-phy-handle = <&phy27>;
                        sfp = <&sfp0>;
                        led-set = <2>;
                        managed = "in-band-status";

diff --git a/target/linux/realtek/dts/rtl9303_xikestor_sks8300-8x.dts b/target/linux/realtek/dts/rtl9303_xikestor_sks8300-8x.dts
index b143844ddd1f5860f0ecc58a1161130d29470b4e..963215936839b0438d82c13912a75ca57b97e578 100644 (file)
--- a/target/linux/realtek/dts/rtl9303_xikestor_sks8300-8x.dts
+++ b/target/linux/realtek/dts/rtl9303_xikestor_sks8300-8x.dts
@@ -343,7 +343,7 @@
                port@0 {
                        reg = <0>;
                        label = "lan1";
-                       phy-handle = <&phy0>;
+                       pseudo-phy-handle = <&phy0>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp0>;
                        managed = "in-band-status";
@@ -353,7 +353,7 @@
                port@8 {
                        reg = <8>;
                        label = "lan2";
-                       phy-handle = <&phy8>;
+                       pseudo-phy-handle = <&phy8>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp1>;
                        managed = "in-band-status";
@@ -363,7 +363,7 @@
                port@10 {
                        reg = <16>;
                        label = "lan3";
-                       phy-handle = <&phy16>;
+                       pseudo-phy-handle = <&phy16>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp2>;
                        managed = "in-band-status";
@@ -373,7 +373,7 @@
                port@14 {
                        reg = <20>;
                        label = "lan4";
-                       phy-handle = <&phy20>;
+                       pseudo-phy-handle = <&phy20>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp3>;
                        managed = "in-band-status";
@@ -383,7 +383,7 @@
                port@18 {
                        reg = <24>;
                        label = "lan5";
-                       phy-handle = <&phy24>;
+                       pseudo-phy-handle = <&phy24>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp4>;
                        managed = "in-band-status";
@@ -393,7 +393,7 @@
                port@19 {
                        reg = <25>;
                        label = "lan6";
-                       phy-handle = <&phy25>;
+                       pseudo-phy-handle = <&phy25>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp5>;
                        managed = "in-band-status";
@@ -403,7 +403,7 @@
                port@1a {
                        reg = <26>;
                        label = "lan7";
-                       phy-handle = <&phy26>;
+                       pseudo-phy-handle = <&phy26>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp6>;
                        managed = "in-band-status";
@@ -413,7 +413,7 @@
                port@1b {
                        reg = <27>;
                        label = "lan8";
-                       phy-handle = <&phy27>;
+                       pseudo-phy-handle = <&phy27>;
                        phy-mode = "10gbase-r";
                        sfp = <&sfp7>;
                        managed = "in-band-status";

diff --git a/target/linux/realtek/files-6.6/drivers/net/dsa/rtl83xx/common.c b/target/linux/realtek/files-6.6/drivers/net/dsa/rtl83xx/common.c
index 28b836f6b2fa856aee4810880038fe872448d03d..cd532a7d3d25e339264a363ebfa887b252231e3d 100644 (file)
--- a/target/linux/realtek/files-6.6/drivers/net/dsa/rtl83xx/common.c
+++ b/target/linux/realtek/files-6.6/drivers/net/dsa/rtl83xx/common.c
@@ -339,6 +339,22 @@ static int __init rtl83xx_mdio_probe(struct rtl838x_switch_priv *priv)
                        continue;
 
                phy_node = of_parse_phandle(dn, "phy-handle", 0);
+
+               /* Major cleanup is needed...
+                *
+                * We use virtual "phys" as containers for mac
+                * properties like the SERDES channel, even for simple
+                * SFP slots.  "pseudo-phy-handle" is a hack to
+                * support this construct and still allow pluggable
+                * phys.
+                *
+                * The SERDES map is most likely static by port number
+                * for each SoC.  No need to put that into the device
+                * tree in the first place.
+                */
+               if (!phy_node)
+                       phy_node = of_parse_phandle(dn, "pseudo-phy-handle", 0);
+
                if (!phy_node) {
                        if (pn != priv->cpu_port)
                                dev_err(priv->dev, "Port node %d misses phy-handle\n", pn);