[PATCH net-next 0/3] net: dsa: mxl-gsw1xx: setup polarities and validate chip

[PATCH net-next 0/3] net: dsa: mxl-gsw1xx: setup polarities and validate chip

[Daniel Golle]

Now that common PHY properties make it easy to configure the SerDes RX and TX
polarities, use that for the SGMII/1000Base-X/2500Base-X PCS of the MaxLinear
GSW1xx switches.

Also, validate hardware in probe() function to make sure the switch is
actually present and MDIO communication works properly.

Daniel Golle (3):
  dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties
  net: dsa: mxl-gsw1xx: configure PCS polarities
  net: dsa: mxl-gsw1xx: validate chip ID

 .../bindings/net/dsa/lantiq,gswip.yaml        |  1 +
 drivers/net/dsa/lantiq/Kconfig                |  1 +
 drivers/net/dsa/lantiq/mxl-gsw1xx.c           | 65 +++++++++++++++----
 drivers/net/dsa/lantiq/mxl-gsw1xx.h           |  9 +++
 4 files changed, 65 insertions(+), 11 deletions(-)

-- 
2.52.0

[PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Daniel Golle]

Reference the common PHY properties so RX and TX SerDes lane polarity
of the SGMII/1000Base-X/2500Base-X PCS can be configured.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
index f601e5f9fa6a..bf199b096dc5 100644
--- a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
@@ -105,6 +105,7 @@ patternProperties:
     patternProperties:
       "^(ethernet-)?port@[0-6]$":
         $ref: dsa-port.yaml#
+        $ref: /schemas/phy/phy-common-props.yaml#
         unevaluatedProperties: false
 
         properties:
-- 
2.52.0

[PATCH net-next 2/3] net: dsa: mxl-gsw1xx: configure PCS polarities

[Daniel Golle]

Configure SerDes PCS RX and TX polarities using the newly
introduced generic properties.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 drivers/net/dsa/lantiq/Kconfig      |  1 +
 drivers/net/dsa/lantiq/mxl-gsw1xx.c | 38 +++++++++++++++++++++--------
 2 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/net/dsa/lantiq/Kconfig b/drivers/net/dsa/lantiq/Kconfig
index bad13817af25..98efeef2661b 100644
--- a/drivers/net/dsa/lantiq/Kconfig
+++ b/drivers/net/dsa/lantiq/Kconfig
@@ -15,6 +15,7 @@ config NET_DSA_MXL_GSW1XX
 	tristate "MaxLinear GSW1xx Ethernet switch support"
 	select NET_DSA_TAG_MXL_GSW1XX
 	select NET_DSA_LANTIQ_COMMON
+	select PHY_COMMON_PROPS
 	help
 	  This enables support for the Intel/MaxLinear GSW1xx family of 1GE
 	  switches.
diff --git a/drivers/net/dsa/lantiq/mxl-gsw1xx.c b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
index 79cf72cc77be..6284b9afdbbb 100644
--- a/drivers/net/dsa/lantiq/mxl-gsw1xx.c
+++ b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
@@ -15,6 +15,8 @@
 #include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/of_mdio.h>
+#include <linux/phy/phy-common-props.h>
+#include <linux/property.h>
 #include <linux/regmap.h>
 #include <linux/workqueue.h>
 #include <net/dsa.h>
@@ -229,11 +231,17 @@ static int gsw1xx_pcs_phy_xaui_write(struct gsw1xx_priv *priv, u16 addr,
 					1000, 100000);
 }
 
-static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv)
+static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv, phy_interface_t interface)
 {
+	struct dsa_port *pcs_port;
+	unsigned int pol;
 	int ret;
 	u16 val;
 
+	pcs_port = dsa_to_port(priv->gswip.ds, GSW1XX_SGMII_PORT);
+	if (!pcs_port)
+		return -EINVAL;
+
 	/* Assert and deassert SGMII shell reset */
 	ret = regmap_set_bits(priv->shell, GSW1XX_SHELL_RST_REQ,
 			      GSW1XX_RST_REQ_SGMII_SHELL);
@@ -260,15 +268,19 @@ static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv)
 	      FIELD_PREP(GSW1XX_SGMII_PHY_RX0_CFG2_FILT_CNT,
 			 GSW1XX_SGMII_PHY_RX0_CFG2_FILT_CNT_DEF);
 
+	ret = phy_get_rx_polarity(of_fwnode_handle(pcs_port->dn),
+				  phy_modes(interface),
+				  BIT(PHY_POL_NORMAL) | BIT(PHY_POL_INVERT),
+				  PHY_POL_NORMAL, &pol);
+	if (ret)
+		return ret;
+
 	/* RX lane seems to be inverted internally, so bit
 	 * GSW1XX_SGMII_PHY_RX0_CFG2_INVERT needs to be set for normal
 	 * (ie. non-inverted) operation.
-	 *
-	 * TODO: Take care of inverted RX pair once generic property is
-	 *       available
 	 */
-
-	val |= GSW1XX_SGMII_PHY_RX0_CFG2_INVERT;
+	if (pol == PHY_POL_NORMAL)
+		val |= GSW1XX_SGMII_PHY_RX0_CFG2_INVERT;
 
 	ret = regmap_write(priv->sgmii, GSW1XX_SGMII_PHY_RX0_CFG2, val);
 	if (ret < 0)
@@ -277,9 +289,15 @@ static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv)
 	val = FIELD_PREP(GSW1XX_SGMII_PHY_TX0_CFG3_VBOOST_LEVEL,
 			 GSW1XX_SGMII_PHY_TX0_CFG3_VBOOST_LEVEL_DEF);
 
-	/* TODO: Take care of inverted TX pair once generic property is
-	 *       available
-	 */
+	ret = phy_get_tx_polarity(of_fwnode_handle(pcs_port->dn),
+				  phy_modes(interface),
+				  BIT(PHY_POL_NORMAL) | BIT(PHY_POL_INVERT),
+				  PHY_POL_NORMAL, &pol);
+	if (ret)
+		return ret;
+
+	if (pol == PHY_POL_INVERT)
+		val |= GSW1XX_SGMII_PHY_TX0_CFG3_INVERT;
 
 	ret = regmap_write(priv->sgmii, GSW1XX_SGMII_PHY_TX0_CFG3, val);
 	if (ret < 0)
@@ -336,7 +354,7 @@ static int gsw1xx_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
 	priv->tbi_interface = PHY_INTERFACE_MODE_NA;
 
 	if (!reconf)
-		ret = gsw1xx_pcs_reset(priv);
+		ret = gsw1xx_pcs_reset(priv, interface);
 
 	if (ret)
 		return ret;
-- 
2.52.0

[PATCH net-next 3/3] net: dsa: mxl-gsw1xx: validate chip ID

[Daniel Golle]

No check for actually present hardware is being performed in the probe
function of the mxl-gsw1xx switch driver. So even if the switch isn't
present at the configured MDIO bus address the driver wrongly tells the
user that a "GSWIP version 0 mod 0" was found, outputting errors about
PHY capabilities not matching.

Read and validate the chip MANU_ID and PNUM_ID registers and output
information while probing, but return an error and abort probing in case
the hardware is not actually present.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 drivers/net/dsa/lantiq/mxl-gsw1xx.c | 27 ++++++++++++++++++++++++++-
 drivers/net/dsa/lantiq/mxl-gsw1xx.h |  9 +++++++++
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/lantiq/mxl-gsw1xx.c b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
index 6284b9afdbbb..68034ce25e5a 100644
--- a/drivers/net/dsa/lantiq/mxl-gsw1xx.c
+++ b/drivers/net/dsa/lantiq/mxl-gsw1xx.c
@@ -689,7 +689,9 @@ static int gsw1xx_probe(struct mdio_device *mdiodev)
 {
 	struct device *dev = &mdiodev->dev;
 	struct gsw1xx_priv *priv;
-	u32 version;
+	u32 version, val;
+	u8 shellver;
+	u16 pnum;
 	int ret;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -737,6 +739,27 @@ static int gsw1xx_probe(struct mdio_device *mdiodev)
 	if (IS_ERR(priv->shell))
 		return PTR_ERR(priv->shell);
 
+	ret = regmap_read(priv->shell, GSW1XX_SHELL_MANU_ID, &val);
+	if (ret < 0)
+		return ret;
+
+	/* validate chip ID */
+	if (FIELD_GET(GSW1XX_SHELL_MANU_ID_FIX1, val) != 1)
+		return -ENODEV;
+
+	if (FIELD_GET(GSW1XX_SHELL_MANU_ID_MANID, val) !=
+	    GSW1XX_SHELL_MANU_ID_MANID_VAL)
+		return -ENODEV;
+
+	pnum = FIELD_GET(GSW1XX_SHELL_MANU_ID_PNUML, val);
+
+	ret = regmap_read(priv->shell, GSW1XX_SHELL_PNUM_ID, &val);
+	if (ret < 0)
+		return ret;
+
+	pnum |= FIELD_GET(GSW1XX_SHELL_PNUM_ID_PNUMM, val) << 4;
+	shellver = FIELD_GET(GSW1XX_SHELL_PNUM_ID_VER, val);
+
 	ret = gsw1xx_serdes_pcs_init(priv);
 	if (ret < 0)
 		return ret;
@@ -757,6 +780,8 @@ static int gsw1xx_probe(struct mdio_device *mdiodev)
 	if (ret)
 		return ret;
 
+	dev_info(dev, "standalone switch part number 0x%x v1.%u\n", pnum, shellver);
+
 	dev_set_drvdata(dev, &priv->gswip);
 
 	return 0;
diff --git a/drivers/net/dsa/lantiq/mxl-gsw1xx.h b/drivers/net/dsa/lantiq/mxl-gsw1xx.h
index d1fded56e967..caa8f1008587 100644
--- a/drivers/net/dsa/lantiq/mxl-gsw1xx.h
+++ b/drivers/net/dsa/lantiq/mxl-gsw1xx.h
@@ -110,6 +110,15 @@
 #define GSW1XX_SHELL_BASE			0xfa00
 #define  GSW1XX_SHELL_RST_REQ			0x01
 #define   GSW1XX_RST_REQ_SGMII_SHELL		BIT(5)
+#define  GSW1XX_SHELL_MANU_ID			0x10
+#define   GSW1XX_SHELL_MANU_ID_PNUML		GENMASK(15, 12)
+#define   GSW1XX_SHELL_MANU_ID_MANID		GENMASK(11, 1)
+#define    GSW1XX_SHELL_MANU_ID_MANID_VAL	0x389
+#define   GSW1XX_SHELL_MANU_ID_FIX1		BIT(0)
+#define  GSW1XX_SHELL_PNUM_ID			0x11
+#define   GSW1XX_SHELL_PNUM_ID_VER		GENMASK(15, 12)
+#define   GSW1XX_SHELL_PNUM_ID_PNUMM		GENMASK(11, 0)
+
 /* RGMII PAD Slew Control Register */
 #define  GSW1XX_SHELL_RGMII_SLEW_CFG		0x78
 #define   RGMII_SLEW_CFG_DRV_TXC		BIT(2)
-- 
2.52.0

Re: [PATCH net-next 2/3] net: dsa: mxl-gsw1xx: configure PCS polarities

[Vladimir Oltean]

On Tue, Jan 27, 2026 at 01:18:45PM +0000, Daniel Golle wrote:
> @@ -229,11 +231,17 @@ static int gsw1xx_pcs_phy_xaui_write(struct gsw1xx_priv *priv, u16 addr,
>  					1000, 100000);
>  }
>  
> -static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv)
> +static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv, phy_interface_t interface)
>  {
> +	struct dsa_port *pcs_port;
> +	unsigned int pol;
>  	int ret;
>  	u16 val;
>  
> +	pcs_port = dsa_to_port(priv->gswip.ds, GSW1XX_SGMII_PORT);
> +	if (!pcs_port)
> +		return -EINVAL;
> +
>  	/* Assert and deassert SGMII shell reset */
>  	ret = regmap_set_bits(priv->shell, GSW1XX_SHELL_RST_REQ,
>  			      GSW1XX_RST_REQ_SGMII_SHELL);
> @@ -260,15 +268,19 @@ static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv)
>  	      FIELD_PREP(GSW1XX_SGMII_PHY_RX0_CFG2_FILT_CNT,
>  			 GSW1XX_SGMII_PHY_RX0_CFG2_FILT_CNT_DEF);
>  
> +	ret = phy_get_rx_polarity(of_fwnode_handle(pcs_port->dn),
> +				  phy_modes(interface),
> +				  BIT(PHY_POL_NORMAL) | BIT(PHY_POL_INVERT),
> +				  PHY_POL_NORMAL, &pol);

phy_get_manual_rx_polarity()

> +	if (ret)
> +		return ret;
> +
>  	/* RX lane seems to be inverted internally, so bit
>  	 * GSW1XX_SGMII_PHY_RX0_CFG2_INVERT needs to be set for normal
>  	 * (ie. non-inverted) operation.
> -	 *
> -	 * TODO: Take care of inverted RX pair once generic property is
> -	 *       available
>  	 */
> -
> -	val |= GSW1XX_SGMII_PHY_RX0_CFG2_INVERT;
> +	if (pol == PHY_POL_NORMAL)
> +		val |= GSW1XX_SGMII_PHY_RX0_CFG2_INVERT;
>  
>  	ret = regmap_write(priv->sgmii, GSW1XX_SGMII_PHY_RX0_CFG2, val);
>  	if (ret < 0)
> @@ -277,9 +289,15 @@ static int gsw1xx_pcs_reset(struct gsw1xx_priv *priv)
>  	val = FIELD_PREP(GSW1XX_SGMII_PHY_TX0_CFG3_VBOOST_LEVEL,
>  			 GSW1XX_SGMII_PHY_TX0_CFG3_VBOOST_LEVEL_DEF);
>  
> -	/* TODO: Take care of inverted TX pair once generic property is
> -	 *       available
> -	 */
> +	ret = phy_get_tx_polarity(of_fwnode_handle(pcs_port->dn),
> +				  phy_modes(interface),
> +				  BIT(PHY_POL_NORMAL) | BIT(PHY_POL_INVERT),
> +				  PHY_POL_NORMAL, &pol);

phy_get_manual_tx_polarity()

> +	if (ret)
> +		return ret;
> +
> +	if (pol == PHY_POL_INVERT)
> +		val |= GSW1XX_SGMII_PHY_TX0_CFG3_INVERT;
>  
>  	ret = regmap_write(priv->sgmii, GSW1XX_SGMII_PHY_TX0_CFG3, val);
>  	if (ret < 0)
> @@ -336,7 +354,7 @@ static int gsw1xx_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
>  	priv->tbi_interface = PHY_INTERFACE_MODE_NA;
>  
>  	if (!reconf)
> -		ret = gsw1xx_pcs_reset(priv);
> +		ret = gsw1xx_pcs_reset(priv, interface);
>  
>  	if (ret)
>  		return ret;
> -- 
> 2.52.0

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Vladimir Oltean]

On Tue, Jan 27, 2026 at 01:18:37PM +0000, Daniel Golle wrote:
> Reference the common PHY properties so RX and TX SerDes lane polarity
> of the SGMII/1000Base-X/2500Base-X PCS can be configured.
> 
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
>  Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> index f601e5f9fa6a..bf199b096dc5 100644
> --- a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> @@ -105,6 +105,7 @@ patternProperties:
>      patternProperties:
>        "^(ethernet-)?port@[0-6]$":
>          $ref: dsa-port.yaml#
> +        $ref: /schemas/phy/phy-common-props.yaml#

Is the PCS integrated into the port? have you considered whether it will
ever need to have its own OF node representation?

>          unevaluatedProperties: false
>  
>          properties:
> -- 
> 2.52.0

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Daniel Golle]

On Tue, Jan 27, 2026 at 03:29:19PM +0200, Vladimir Oltean wrote:
> On Tue, Jan 27, 2026 at 01:18:37PM +0000, Daniel Golle wrote:
> > Reference the common PHY properties so RX and TX SerDes lane polarity
> > of the SGMII/1000Base-X/2500Base-X PCS can be configured.
> > 
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > ---
> >  Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> > index f601e5f9fa6a..bf199b096dc5 100644
> > --- a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> > +++ b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> > @@ -105,6 +105,7 @@ patternProperties:
> >      patternProperties:
> >        "^(ethernet-)?port@[0-6]$":
> >          $ref: dsa-port.yaml#
> > +        $ref: /schemas/phy/phy-common-props.yaml#
> 
> Is the PCS integrated into the port?

The PCS is hard-tied to port 4 of the switch. Neither can that port be
used for anything else than this PCS, nor can the PCS be used elsewhere.
It's a bit like they nuked one of the TP PHY ports and glued in that
SGMII PCS instead. The PCS is probably a ready-made IP block, visible in
places like EEE/LPI features being documented for the PCS, but known not
to work on the switch MAC (while it does work with PHY ports). So it's
not a design made for that particular switch chip, but something which
already existed and was then used there.

> have you considered whether it will ever need to have its own OF node
> representation?

Yeah, I thought about that, but it would be a lot of work to
let the driver expose and simple-bus as MFD with devices (clk controller,
reset controller, pcs, ...) sitting on register ranges. Imho not worth
the effort in this case, we discussed it.

That being said, of course, should the PCS IP ever get reused in other
hardware, that part of the driver could be turned into a helper library
working on a regmap, while the hosting driver still takes care of the
resource lifecycle, similar to other PCS helper libraries in
drivers/net/pcs/.

However, even in that case imho it's fine to let it share the OF node
with the ethernet-port. Why not?

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Vladimir Oltean]

On Tue, Jan 27, 2026 at 02:07:03PM +0000, Daniel Golle wrote:
> Yeah, I thought about that, but it would be a lot of work to
> let the driver expose and simple-bus as MFD with devices (clk controller,
> reset controller, pcs, ...) sitting on register ranges. Imho not worth
> the effort in this case, we discussed it.

Possibly so; I don't have access from this computer to my previous notes
on this topic.

> However, even in that case imho it's fine to let it share the OF node
> with the ethernet-port. Why not?

I don't have a good feeling of how reusable this PCS IP truly is.
For example the XPCS gained DT bindings before I needed to customize the
lane polarity for its SJA1105 instantiation, so now I have to work with
and somehow adapt those.

If the PCS has a fixed mapping to that port then I suppose it can use
its OF node space without any extra overengineering. There should exist
ways to keep compatibility with this scheme even if there will be
efforts to have a reusable driver later.

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Andrew Lunn]

> > Is the PCS integrated into the port?
> 
> The PCS is hard-tied to port 4 of the switch. Neither can that port be
> used for anything else than this PCS, nor can the PCS be used elsewhere.
> It's a bit like they nuked one of the TP PHY ports and glued in that
> SGMII PCS instead. The PCS is probably a ready-made IP block

Does it have IDs in register 2 and 3? Is there any clue if it is
licensed from somebody?

	 Andrew

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Daniel Golle]

On Tue, Jan 27, 2026 at 04:21:26PM +0100, Andrew Lunn wrote:
> > > Is the PCS integrated into the port?
> > 
> > The PCS is hard-tied to port 4 of the switch. Neither can that port be
> > used for anything else than this PCS, nor can the PCS be used elsewhere.
> > It's a bit like they nuked one of the TP PHY ports and glued in that
> > SGMII PCS instead. The PCS is probably a ready-made IP block
> 
> Does it have IDs in register 2 and 3?

That'd be too easy ;)

register 2 is SGMII_PHY_MPLL_CFG2
register 3 is SGMII_PHY_RX0_CFG1

register 2 and 3 of the XAUI PHY which can be indirectly accessed also doesn't
contain anything meaningful (0x000a and 0x0000)

> Is there any clue if it is licensed from somebody?

At least it's not obvious in any way.

The documentation is public, see
https://www.maxlinear.com/product/interface/ethernet/ethernet-switches/gsw145
"Ethernet Switch GSW145 Data Sheet"
Section 4.2 SGMII_Registers

My guess that it is not genuinly designed for that switch IC stems from
the fact that it has features (EEE, for example) which aren't supported
in the way it is integrated in the switch.

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Daniel Golle]

On Tue, Jan 27, 2026 at 05:07:47PM +0200, Vladimir Oltean wrote:
> On Tue, Jan 27, 2026 at 02:07:03PM +0000, Daniel Golle wrote:
> > Yeah, I thought about that, but it would be a lot of work to
> > let the driver expose and simple-bus as MFD with devices (clk controller,
> > reset controller, pcs, ...) sitting on register ranges. Imho not worth
> > the effort in this case, we discussed it.
> 
> Possibly so; I don't have access from this computer to my previous notes
> on this topic.
> 
> > However, even in that case imho it's fine to let it share the OF node
> > with the ethernet-port. Why not?
> 
> I don't have a good feeling of how reusable this PCS IP truly is.
> For example the XPCS gained DT bindings before I needed to customize the
> lane polarity for its SJA1105 instantiation, so now I have to work with
> and somehow adapt those.
> 
> If the PCS has a fixed mapping to that port then I suppose it can use
> its OF node space without any extra overengineering. There should exist
> ways to keep compatibility with this scheme even if there will be
> efforts to have a reusable driver later.

Taking a step back I noticed that we need to decide this also for
mt7530.

commit bde1ae2d52ab ("net: pcs: pcs-mtk-lynxi: pass SGMIISYS OF node to PCS")
currently doesn't pass any fwnode when creating the LynxI PCS.
> +               pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
> +                                          MT7531_PHYA_CTRL_SIGNAL3);

However, each PCS does belong to a specific switch port, and it would be
advantegous and imho consistent to also assign the ports OF node to the
PCS, this would allow to configure the polarities also on the MT7530
SerDes ports.

Ie.

diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c
index 11ea924a9f35..3da9f42cefcb 100644
--- a/drivers/net/dsa/mt7530-mdio.c
+++ b/drivers/net/dsa/mt7530-mdio.c
@@ -86,9 +86,16 @@ mt7531_create_sgmii(struct mt7530_priv *priv)
 	struct regmap_config *mt7531_pcs_config[2] = {};
 	struct phylink_pcs *pcs;
 	struct regmap *regmap;
+	struct dsa_port *dp;
 	int i, ret = 0;
 
 	for (i = priv->p5_sgmii ? 0 : 1; i < 2; i++) {
+		dp = dsa_to_port(priv->ds, i + 5);
+		if (!dp) {
+			ret = -EINVAL;
+			break;
+		}
+
 		mt7531_pcs_config[i] = devm_kzalloc(priv->dev,
 						    sizeof(struct regmap_config),
 						    GFP_KERNEL);
@@ -113,8 +120,8 @@ mt7531_create_sgmii(struct mt7530_priv *priv)
 			ret = PTR_ERR(regmap);
 			break;
 		}
-		pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
-					   MT7531_PHYA_CTRL_SIGNAL3);
+		pcs = mtk_pcs_lynxi_create(priv->dev, of_fwnode_handle(dp->dn),
+					   regmap, MT7531_PHYA_CTRL_SIGNAL3);
 		if (!pcs) {
 			ret = -ENXIO;
 			break;


What do you think?

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Vladimir Oltean]

On Tue, Jan 27, 2026 at 10:10:58PM +0000, Daniel Golle wrote:
> Taking a step back I noticed that we need to decide this also for
> mt7530.
> 
> commit bde1ae2d52ab ("net: pcs: pcs-mtk-lynxi: pass SGMIISYS OF node to PCS")
> currently doesn't pass any fwnode when creating the LynxI PCS.
> > +               pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
> > +                                          MT7531_PHYA_CTRL_SIGNAL3);
> 
> However, each PCS does belong to a specific switch port, and it would be
> advantegous and imho consistent to also assign the ports OF node to the
> PCS, this would allow to configure the polarities also on the MT7530
> SerDes ports.

mt753x_phylink_mac_select_pcs() returns either &priv->pcs[dp->index].pcs
for TRGMII or priv->ports[dp->index].sgmii_pcs for the rest.

How would one know (generally speaking) if properties placed in the
ethernet-port node are for the SGMII PCS or for the other one?

Re: [PATCH net-next 1/3] dt-bindings: net: dsa: lantiq,gswip: reference common PHY properties

[Daniel Golle]

On Wed, Jan 28, 2026 at 12:25:08AM +0200, Vladimir Oltean wrote:
> On Tue, Jan 27, 2026 at 10:10:58PM +0000, Daniel Golle wrote:
> > Taking a step back I noticed that we need to decide this also for
> > mt7530.
> > 
> > commit bde1ae2d52ab ("net: pcs: pcs-mtk-lynxi: pass SGMIISYS OF node to PCS")
> > currently doesn't pass any fwnode when creating the LynxI PCS.
> > > +               pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
> > > +                                          MT7531_PHYA_CTRL_SIGNAL3);
> > 
> > However, each PCS does belong to a specific switch port, and it would be
> > advantegous and imho consistent to also assign the ports OF node to the
> > PCS, this would allow to configure the polarities also on the MT7530
> > SerDes ports.
> 
> mt753x_phylink_mac_select_pcs() returns either &priv->pcs[dp->index].pcs
> for TRGMII or priv->ports[dp->index].sgmii_pcs for the rest.
> 
> How would one know (generally speaking) if properties placed in the
> ethernet-port node are for the SGMII PCS or for the other one?

Because of the port number and a fixed assignment of possible external
interface types to each port: On MT7531, port 6 is always connected
to the SerDes PCS. On MT7531AE port 5 is another SerDes PCS, while
on MT7531BE port 5 is (the only) (T)RGMII interface.
So, just like with the MaxLinear GSW1xx port and PCS are tightly
tied together.