Re: [PATCH net-next v3 10/12] dt-bindings: net: dsa: lantiq,gswip: add support for MaxLinear GSW1xx switches

[Daniel Golle <daniel@makrotopia.org>]

On Tue, Oct 28, 2025 at 02:09:59AM +0200, Vladimir Oltean wrote:
> On Sun, Oct 26, 2025 at 11:48:06PM +0000, Daniel Golle wrote:
> > Extend the Lantiq GSWIP device tree binding to also cover MaxLinear
> > GSW1xx switches which are based on the same hardware IP but connected
> > via MDIO instead of being memory-mapped.
> > 
> > Add compatible strings for MaxLinear GSW120, GSW125, GSW140, GSW141,
> > and GSW145 switches and adjust the schema to handle the different
> > connection methods with conditional properties.
> > 
> > Add MaxLinear GSW125 example showing MDIO-connected configuration.
> > 
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > ---
> > v3:
> >  * add maxlinear,rx-inverted and maxlinear,tx-inverted properties
> > 
> > v2:
> >  * remove git conflict left-overs which somehow creeped in
> >  * indent example with 4 spaces instead of tabs
> > 
> >  .../bindings/net/dsa/lantiq,gswip.yaml        | 275 +++++++++++++-----
> >  1 file changed, 202 insertions(+), 73 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> > index dd3858bad8ca..1148fdd0b6bc 100644
> > --- a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> > +++ b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
> > @@ -4,7 +4,12 @@
> >  $id: http://devicetree.org/schemas/net/dsa/lantiq,gswip.yaml#
> >  $schema: http://devicetree.org/meta-schemas/core.yaml#
> >  
> > -title: Lantiq GSWIP Ethernet switches
> > +title: Lantiq GSWIP and MaxLinear GSW1xx Ethernet switches
> > +
> > +description:
> > +  Lantiq GSWIP and MaxLinear GSW1xx switches share the same hardware IP.
> > +  Lantiq switches are embedded in SoCs and accessed via memory-mapped I/O,
> > +  while MaxLinear switches are standalone ICs connected via MDIO.
> >  
> >  $ref: dsa.yaml#
> >  
> > @@ -34,6 +39,108 @@ patternProperties:
> >              description:
> >                Configure the RMII reference clock to be a clock output
> >                rather than an input. Only applicable for RMII mode.
> > +          maxlinear,rx-inverted:
> > +            type: boolean
> > +            description:
> > +              Enable RX polarity inversion for SerDes port.
> > +          maxlinear,tx-inverted:
> > +            type: boolean
> > +            description:
> > +              Enable TX polarity inversion for SerDes port.
> 
> How urgently do you need these two properties? They are truly general,
> not vendor-specific, and while I wanted to add such support to the
> Synopsys XPCS, I started working on some generic variants.

Inverting the RX inversion is required for the MaxLinear GSW145 demo
board I got which got an MxL86111 PHY wired to the SGMII port of the
switch. That's why I had to implement at least that in order to be able
to test the SerDes port.

> There's some cleanup and consolidation to do. "st,pcie-tx-pol-inv" and
> "st,sata-tx-pol-inv" are defined in .txt bindings but not implemented.
> Then we have "st,px_rx_pol_inv" and "mediatek,pnswap" which would also
> need deprecating and converted to the new formats.

Sounds like a good plan, I'm all for it :)

> 
> Where I left things was that I haven't decided if there's any value in
> defining the polarity per SerDes protocol (like
> Documentation/devicetree/bindings/phy/transmit-amplitude.yaml) or if a
> global value is fine. I.e. if the polarity is inverted for SATA, it's
> normal for PCIe, or something like that. The existence of the independent
> "st,pcie-tx-pol-inv" and "st,sata-tx-pol-inv" properties would suggest
> yes, but the lack of an implementation casts some doubt on that.
> 
> Anyway, I do have some prototype patches that add something like this:
> 
>     phy: phy {
>       #phy-cells = <1>;
>       tx-p2p-microvolt = <915000>, <1100000>, <1200000>;
>       tx-p2p-microvolt-names = "2500base-x", "usb-hs", "usb-ss";
> 
>       /* RX polarity is inverted for usb-hs, normal for usb-ss */
>       rx-polarity = <PHY_POL_INVERT>, <PHY_POL_NORMAL>;
>       rx-polarity-names = "usb-hs", "usb-ss";
> 
>       /* TX polarity is normal for all modes */
>       tx-polarity = <PHY_POL_NORMAL>;
>       tx-polarity-names = "default";
>     };
> 
> and a new drivers/phy/phy-common-props.c file (yes, outside of netdev)
> with two exported API functions:
> 
> int phy_get_rx_polarity(struct fwnode_handle *fwnode, const char *mode_name);
> int phy_get_tx_polarity(struct fwnode_handle *fwnode, const char *mode_name);
> 
> If you can split this up from the rest of the MDIO discrete switch
> introduction series, I can accelerate work on these common properties in
> the following weeks.

I can break out the SGMII polarity dt-bindings and functional patch
and postpone it until generic properties to describe SerDes polarities
are introduced.

Also note that the SerDes PHY also got a bunch of other tunables which
can make sense but aren't required on the demo board:
 * RX LOS Detector Enable
 * RX LOS Filter Count
 * RX LOS Threshold Level in mV
 * RX LOS Sensitivity Level
 * TX Amplitude Control
 * TX Vboost Enable
 * TX Vboost Level (0.844 V, 1.008 V, 1.156 V)
 * TX Remote Receiver Detection Request Enable
 * TX Preemphasis
 * ...

Especially the voltage levels cry for being described in a generic
way...