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.0On 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
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?
> > 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
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.
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.
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?
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?
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.
© 2016 - 2026 Red Hat, Inc.