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

[Daniel Golle <daniel@makrotopia.org>]

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?