[PATCH net-next 0/9] XPCS polarity inversion via generic device tree properties

[PATCH net-next 0/9] XPCS polarity inversion via generic device tree properties

[Vladimir Oltean]

Polarity inversion (described in patch 3/6) is a feature with at least 3
potential new users waiting for a generic description:
- Horatiu Vultur with the lan966x SerDes
- Daniel Golle with the MaxLinear GSW1xx switches
- Me with a custom SJA1105 board, switch which uses the DesignWare XPCS

I became interested in exploring the problem space because I was averse
to the idea of adding vendor-specific device tree properties to describe
a common need.

This set contains an implementation of a generic feature that should
cater to all known needs that were identified during my documentation
phase. I've added a new user - the XPCS - and I've converted an existing
user - the EN8811H Ethernet PHY.

I haven't converted the rest due to various reasons:
- "mediatek,pnswap" is defined bidirectionally and the underlying
  SGMII_PN_SWAP_TX_RX register field doesn't make it clear which bit is
  RX and which is TX. Needs more work and expert knowledge from maintainer.
- "st,px_rx_pol_inv" - its binding is a .txt file and I don't have time
  for such a large detour to convert it to dtschema.
- "st,pcie-tx-pol-inv" and "st,sata-tx-pol-inv" - these are defined in a
  .txt schema but are not implemented in any driver. My verdict would be
  "delete the properties" but again, I would prefer not introducing such
  dependency to this series.

Vladimir Oltean (9):
  dt-bindings: phy: rename transmit-amplitude.yaml to
    phy-common-props.yaml
  dt-bindings: phy-common-props: create a reusable "protocol-names"
    definition
  dt-bindings: phy-common-props: RX and TX lane polarity inversion
  dt-bindings: net: xpcs: allow properties from phy-common-props.yaml
  phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
  net: pcs: xpcs: promote SJA1105 TX polarity inversion to core
  net: pcs: xpcs: allow lane polarity inversion
  net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and
    "airoha,pnswap-tx"
  dt-bindings: net: airoha,en8811h: deprecate "airoha,pnswap-rx" and
    "airoha,pnswap-tx"

 .../bindings/net/airoha,en8811h.yaml          |  11 +-
 .../bindings/net/pcs/snps,dw-xpcs.yaml        |   5 +-
 .../bindings/phy/phy-common-props.yaml        | 152 ++++++++++++++++++
 .../bindings/phy/transmit-amplitude.yaml      | 103 ------------
 MAINTAINERS                                   |  21 +++
 drivers/net/pcs/Kconfig                       |   1 +
 drivers/net/pcs/pcs-xpcs-nxp.c                |  11 --
 drivers/net/pcs/pcs-xpcs.c                    |  58 ++++++-
 drivers/net/pcs/pcs-xpcs.h                    |   2 +-
 drivers/net/phy/Kconfig                       |   1 +
 drivers/net/phy/air_en8811h.c                 |  50 ++++--
 drivers/phy/Kconfig                           |   9 ++
 drivers/phy/Makefile                          |   1 +
 drivers/phy/phy-common-props.c                | 117 ++++++++++++++
 include/dt-bindings/phy/phy.h                 |   4 +
 include/linux/phy/phy-common-props.h          |  20 +++
 16 files changed, 426 insertions(+), 140 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-common-props.yaml
 delete mode 100644 Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
 create mode 100644 drivers/phy/phy-common-props.c
 create mode 100644 include/linux/phy/phy-common-props.h

-- 
2.34.1

[PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Vladimir Oltean]

I would like to add more properties similar to tx-p2p-microvolt, and I
don't think it makes sense to create one schema for each such property
(transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml
etc).

Instead, let's rename to phy-common-props.yaml, which makes it a more
adequate host schema for all the above properties.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 .../{transmit-amplitude.yaml => phy-common-props.yaml}    | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/phy/{transmit-amplitude.yaml => phy-common-props.yaml} (90%)

diff --git a/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
similarity index 90%
rename from Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
rename to Documentation/devicetree/bindings/phy/phy-common-props.yaml
index 617f3c0b3dfb..255205ac09cd 100644
--- a/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
@@ -1,14 +1,14 @@
 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
 %YAML 1.2
 ---
-$id: http://devicetree.org/schemas/phy/transmit-amplitude.yaml#
+$id: http://devicetree.org/schemas/phy/phy-common-props.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Common PHY and network PCS transmit amplitude property
+title: Common PHY and network PCS properties
 
 description:
-  Binding describing the peak-to-peak transmit amplitude for common PHYs
-  and network PCSes.
+  Common PHY and network PCS properties, such as peak-to-peak transmit
+  amplitude.
 
 maintainers:
   - Marek Behún <kabel@kernel.org>
-- 
2.34.1

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Andrew Lunn]

On Sat, Nov 22, 2025 at 09:33:33PM +0200, Vladimir Oltean wrote:
> I would like to add more properties similar to tx-p2p-microvolt, and I
> don't think it makes sense to create one schema for each such property
> (transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml
> etc).
> 
> Instead, let's rename to phy-common-props.yaml, which makes it a more
> adequate host schema for all the above properties.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  .../{transmit-amplitude.yaml => phy-common-props.yaml}    | 8 ++++----

So there is nothing currently referencing this file?

	Andrew

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Vladimir Oltean]

On Tue, Nov 25, 2025 at 10:19:11PM +0100, Andrew Lunn wrote:
> On Sat, Nov 22, 2025 at 09:33:33PM +0200, Vladimir Oltean wrote:
> > I would like to add more properties similar to tx-p2p-microvolt, and I
> > don't think it makes sense to create one schema for each such property
> > (transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml
> > etc).
> > 
> > Instead, let's rename to phy-common-props.yaml, which makes it a more
> > adequate host schema for all the above properties.
> > 
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > ---
> >  .../{transmit-amplitude.yaml => phy-common-props.yaml}    | 8 ++++----
> 
> So there is nothing currently referencing this file?

Yeah, although as things currently stand, I'd say that is the lesser of
problems. The only user (mv88e6xxx) does something strange: it says it
wants to configure the TX amplitude of SerDes ports, but instead follows
the phy-handle and applies the amplitude specified in that node.

I tried to mentally follow how things would work in 2 cases:
1. PHY referenced by phy-handle is internal, then by definition it's not
   a SerDes port.
2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
   looks at what is essentially a device tree description of the PHY's
   TX, and applies that as a mirror image to the local SerDes' TX.

I think the logic is used in mv88e6xxx through case #2, i.e. we
externalize the mv88e6xxx SerDes electrical properties to an unrelated
OF node, the connected Ethernet PHY.

I note that referencing an Ethernet PHY is done using "phy-handle", a
generic PHY using "phys", and that the two are not the same. A SerDes is
a generic PHY but not an Ethernet PHY.

I looked again through the most lengthy discussion on this patch:
https://lore.kernel.org/netdev/20211207190730.3076-2-holger.brunck@hitachienergy.com/
but did not see this aspect being pointed out.

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Andrew Lunn]

> Yeah, although as things currently stand, I'd say that is the lesser of
> problems. The only user (mv88e6xxx) does something strange: it says it
> wants to configure the TX amplitude of SerDes ports, but instead follows
> the phy-handle and applies the amplitude specified in that node.
> 
> I tried to mentally follow how things would work in 2 cases:
> 1. PHY referenced by phy-handle is internal, then by definition it's not
>    a SerDes port.
> 2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
>    looks at what is essentially a device tree description of the PHY's
>    TX, and applies that as a mirror image to the local SerDes' TX.
> 
> I think the logic is used in mv88e6xxx through case #2, i.e. we
> externalize the mv88e6xxx SerDes electrical properties to an unrelated
> OF node, the connected Ethernet PHY.

My understanding of the code is the same, #2. Although i would
probably not say it is an unrelated node. I expect the PHY is on the
other end of the SERDES link which is having the TX amplitudes
set. This clearly will not work if there is an SFP cage on the other
end, but it does for an SGMII PHY.

I guess this code is from before the time Russell converted the
mv88e6xxx SERDES code into PCS drivers. The register being set is
within the PCS register set.  The mv88e6xxx also does not make use of
generic phys to represent the SERDES part of the PCS. So there is no
phys phandle to follow since there is no phy.

	Andrew

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Vladimir Oltean]

+Maxime, Holger
thread at https://lore.kernel.org/netdev/20251122193341.332324-2-vladimir.oltean@nxp.com/

On Tue, Nov 25, 2025 at 11:33:09PM +0100, Andrew Lunn wrote:
> > Yeah, although as things currently stand, I'd say that is the lesser of
> > problems. The only user (mv88e6xxx) does something strange: it says it
> > wants to configure the TX amplitude of SerDes ports, but instead follows
> > the phy-handle and applies the amplitude specified in that node.
> > 
> > I tried to mentally follow how things would work in 2 cases:
> > 1. PHY referenced by phy-handle is internal, then by definition it's not
> >    a SerDes port.
> > 2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
> >    looks at what is essentially a device tree description of the PHY's
> >    TX, and applies that as a mirror image to the local SerDes' TX.
> > 
> > I think the logic is used in mv88e6xxx through case #2, i.e. we
> > externalize the mv88e6xxx SerDes electrical properties to an unrelated
> > OF node, the connected Ethernet PHY.
> 
> My understanding of the code is the same, #2. Although i would
> probably not say it is an unrelated node. I expect the PHY is on the
> other end of the SERDES link which is having the TX amplitudes
> set. This clearly will not work if there is an SFP cage on the other
> end, but it does for an SGMII PHY.

It is unrelated in the sense that the SGMII PHY is a different kernel
object, and the mv88e6xxx is polluting its OF node with properties which
it then interprets as its own, when the PHY driver may have wanted to
configure its SGMII TX amplitude too, via those same generic properties.

> I guess this code is from before the time Russell converted the
> mv88e6xxx SERDES code into PCS drivers. The register being set is
> within the PCS register set.  The mv88e6xxx also does not make use of
> generic phys to represent the SERDES part of the PCS. So there is no
> phys phandle to follow since there is no phy.

In my view, the phy-common-props.yaml are supposed to be applicable to either:
(1) a network PHY with SerDes host-side connection (I suppose the media
    side electrical properties would be covered by Maxime's phy_port
    work - Maxime, please confirm).
(2) a phylink_pcs with SerDes registers within the same register set
(3) a generic PHY

My patch 8/9 (net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and
"airoha,pnswap-tx") is an example of case (1) for polarities. Also, for
example, at least Aquantia Gen3 PHYs (AQR111, AQR112) have a (not very
well documented) "SerDes Lane 0 Amplitude" field in the PHY XS Receive
(XAUI TX) Reserved Vendor Provisioning 4 register (address 4.E413).

My patch 7/9 (net: pcs: xpcs: allow lane polarity inversion) is an
example of case (2).

I haven't submitted an example of case (3) yet, but the Lynx PCS and
Lynx SerDes would fall into that category. The PCS would be free of
describing electrical properties, and those would go to the generic PHY
(SerDes).

All I'm trying to say is that we're missing an OF node to describe
mv88e6xxx PCS electrical properties, because otherwise, it collides with
case (1). My note regarding "phys" was just a guess that the "phy-handle"
may have been mistaken for the port's SerDes PHY. Although there is a
chance Holger knew what he was doing. In any case, I think we need to
sort this one way or another, leaving the phy-handle logic a discouraged
fallback path.

That being said, I'm not exactly an expert in determining _how_ we could
best retrofit SerDes/PCS OF nodes on top of the mv88e6xxx bindings.
It depends on how many SerDes ports there are in these switches
architecturally, and what is their register access method, so it would
need to be handled on a case-by-case basis rather than one-size-fits-all.
PCS node in port node could be a starting point, I guess, but I don't
know if it would work.

For SJA1105 and the XPCS, I thought the best course of action would be
to create a "regs" container node in the switch, under which we'd have
"ethernet-pcs" children, but that seems to be problematic in its own
ways, due to how MFD is seemingly abused to make that work:
https://lore.kernel.org/netdev/20251118190530.580267-15-vladimir.oltean@nxp.com/

RE: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Holger Brunck]

Hi Vladimir,
 
> On Tue, Nov 25, 2025 at 11:33:09PM +0100, Andrew Lunn wrote:
> > > Yeah, although as things currently stand, I'd say that is the lesser
> > > of problems. The only user (mv88e6xxx) does something strange: it
> > > says it wants to configure the TX amplitude of SerDes ports, but
> > > instead follows the phy-handle and applies the amplitude specified in that
> node.
> > >
> > > I tried to mentally follow how things would work in 2 cases:
> > > 1. PHY referenced by phy-handle is internal, then by definition it's not
> > >    a SerDes port.
> > > 2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
> > >    looks at what is essentially a device tree description of the PHY's
> > >    TX, and applies that as a mirror image to the local SerDes' TX.
> > >
> > > I think the logic is used in mv88e6xxx through case #2, i.e. we
> > > externalize the mv88e6xxx SerDes electrical properties to an
> > > unrelated OF node, the connected Ethernet PHY.
> >
> > My understanding of the code is the same, #2. Although i would
> > probably not say it is an unrelated node. I expect the PHY is on the
> > other end of the SERDES link which is having the TX amplitudes set.
> > This clearly will not work if there is an SFP cage on the other end,
> > but it does for an SGMII PHY.
> 
> It is unrelated in the sense that the SGMII PHY is a different kernel object, and
> the mv88e6xxx is polluting its OF node with properties which it then interprets as
> its own, when the PHY driver may have wanted to configure its SGMII TX
> amplitude too, via those same generic properties.
> 
> > I guess this code is from before the time Russell converted the
> > mv88e6xxx SERDES code into PCS drivers. The register being set is
> > within the PCS register set.  The mv88e6xxx also does not make use of
> > generic phys to represent the SERDES part of the PCS. So there is no
> > phys phandle to follow since there is no phy.
> 
> In my view, the phy-common-props.yaml are supposed to be applicable to
> either:
> (1) a network PHY with SerDes host-side connection (I suppose the media
>     side electrical properties would be covered by Maxime's phy_port
>     work - Maxime, please confirm).
> (2) a phylink_pcs with SerDes registers within the same register set
> (3) a generic PHY
> 
> My patch 8/9 (net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and
> "airoha,pnswap-tx") is an example of case (1) for polarities. Also, for example,
> at least Aquantia Gen3 PHYs (AQR111, AQR112) have a (not very well
> documented) "SerDes Lane 0 Amplitude" field in the PHY XS Receive (XAUI TX)
> Reserved Vendor Provisioning 4 register (address 4.E413).
> 
> My patch 7/9 (net: pcs: xpcs: allow lane polarity inversion) is an example of case
> (2).
> 
> I haven't submitted an example of case (3) yet, but the Lynx PCS and Lynx SerDes
> would fall into that category. The PCS would be free of describing electrical
> properties, and those would go to the generic PHY (SerDes).
> 
> All I'm trying to say is that we're missing an OF node to describe mv88e6xxx PCS
> electrical properties, because otherwise, it collides with case (1). My note
> regarding "phys" was just a guess that the "phy-handle"
> may have been mistaken for the port's SerDes PHY. Although there is a chance
> Holger knew what he was doing. In any case, I think we need to sort this one
> way or another, leaving the phy-handle logic a discouraged fallback path.
> 

I was checking our use case, and it is a bit special. We have the port in question
directly connected to a FPGA which has also have a SerDes interface. We are then
configuring a fixed link to the FPGA without a phy in between so there is also no
phy handle in our case. But in general, the board in question is now in maintenance
and there will be no kernel update anymore in the future. Therefore, it is fine with
me if you remove or rework the code in question completely. Hope that helps.

Best regards
Holger

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Vladimir Oltean]

Hi Holger,

On Wed, Nov 26, 2025 at 09:32:30AM +0000, Holger Brunck wrote:
> Hi Vladimir,
>  
> > On Tue, Nov 25, 2025 at 11:33:09PM +0100, Andrew Lunn wrote:
> > > > Yeah, although as things currently stand, I'd say that is the lesser
> > > > of problems. The only user (mv88e6xxx) does something strange: it
> > > > says it wants to configure the TX amplitude of SerDes ports, but
> > > > instead follows the phy-handle and applies the amplitude specified in that
> > node.
> > > >
> > > > I tried to mentally follow how things would work in 2 cases:
> > > > 1. PHY referenced by phy-handle is internal, then by definition it's not
> > > >    a SerDes port.
> > > > 2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
> > > >    looks at what is essentially a device tree description of the PHY's
> > > >    TX, and applies that as a mirror image to the local SerDes' TX.
> > > >
> > > > I think the logic is used in mv88e6xxx through case #2, i.e. we
> > > > externalize the mv88e6xxx SerDes electrical properties to an
> > > > unrelated OF node, the connected Ethernet PHY.
> > >
> > > My understanding of the code is the same, #2. Although i would
> > > probably not say it is an unrelated node. I expect the PHY is on the
> > > other end of the SERDES link which is having the TX amplitudes set.
> > > This clearly will not work if there is an SFP cage on the other end,
> > > but it does for an SGMII PHY.
> > 
> > It is unrelated in the sense that the SGMII PHY is a different kernel object, and
> > the mv88e6xxx is polluting its OF node with properties which it then interprets as
> > its own, when the PHY driver may have wanted to configure its SGMII TX
> > amplitude too, via those same generic properties.
> > 
> > > I guess this code is from before the time Russell converted the
> > > mv88e6xxx SERDES code into PCS drivers. The register being set is
> > > within the PCS register set.  The mv88e6xxx also does not make use of
> > > generic phys to represent the SERDES part of the PCS. So there is no
> > > phys phandle to follow since there is no phy.
> > 
> > In my view, the phy-common-props.yaml are supposed to be applicable to
> > either:
> > (1) a network PHY with SerDes host-side connection (I suppose the media
> >     side electrical properties would be covered by Maxime's phy_port
> >     work - Maxime, please confirm).
> > (2) a phylink_pcs with SerDes registers within the same register set
> > (3) a generic PHY
> > 
> > My patch 8/9 (net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and
> > "airoha,pnswap-tx") is an example of case (1) for polarities. Also, for example,
> > at least Aquantia Gen3 PHYs (AQR111, AQR112) have a (not very well
> > documented) "SerDes Lane 0 Amplitude" field in the PHY XS Receive (XAUI TX)
> > Reserved Vendor Provisioning 4 register (address 4.E413).
> > 
> > My patch 7/9 (net: pcs: xpcs: allow lane polarity inversion) is an example of case
> > (2).
> > 
> > I haven't submitted an example of case (3) yet, but the Lynx PCS and Lynx SerDes
> > would fall into that category. The PCS would be free of describing electrical
> > properties, and those would go to the generic PHY (SerDes).
> > 
> > All I'm trying to say is that we're missing an OF node to describe mv88e6xxx PCS
> > electrical properties, because otherwise, it collides with case (1). My note
> > regarding "phys" was just a guess that the "phy-handle"
> > may have been mistaken for the port's SerDes PHY. Although there is a chance
> > Holger knew what he was doing. In any case, I think we need to sort this one
> > way or another, leaving the phy-handle logic a discouraged fallback path.
> > 
> 
> I was checking our use case, and it is a bit special. We have the port in question
> directly connected to a FPGA which has also have a SerDes interface. We are then
> configuring a fixed link to the FPGA without a phy in between so there is also no
> phy handle in our case. But in general, the board in question is now in maintenance
> and there will be no kernel update anymore in the future. Therefore, it is fine with
> me if you remove or rework the code in question completely. Hope that helps.
> 
> Best regards
> Holger

Thanks for the response. So given this clarification, how was commit
926eae604403 ("dsa: mv88e6xxx: make serdes SGMII/Fiber tx amplitude
configurable") useful for you?

RE: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Holger Brunck]

> On Wed, Nov 26, 2025 at 09:32:30AM +0000, Holger Brunck wrote:
> > Hi Vladimir,
> >
> > > On Tue, Nov 25, 2025 at 11:33:09PM +0100, Andrew Lunn wrote:
> > > > > Yeah, although as things currently stand, I'd say that is the
> > > > > lesser of problems. The only user (mv88e6xxx) does something
> > > > > strange: it says it wants to configure the TX amplitude of
> > > > > SerDes ports, but instead follows the phy-handle and applies the
> > > > > amplitude specified in that
> > > node.
> > > > >
> > > > > I tried to mentally follow how things would work in 2 cases:
> > > > > 1. PHY referenced by phy-handle is internal, then by definition it's not
> > > > >    a SerDes port.
> > > > > 2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
> > > > >    looks at what is essentially a device tree description of the PHY's
> > > > >    TX, and applies that as a mirror image to the local SerDes' TX.
> > > > >
> > > > > I think the logic is used in mv88e6xxx through case #2, i.e. we
> > > > > externalize the mv88e6xxx SerDes electrical properties to an
> > > > > unrelated OF node, the connected Ethernet PHY.
> > > >
> > > > My understanding of the code is the same, #2. Although i would
> > > > probably not say it is an unrelated node. I expect the PHY is on
> > > > the other end of the SERDES link which is having the TX amplitudes set.
> > > > This clearly will not work if there is an SFP cage on the other
> > > > end, but it does for an SGMII PHY.
> > >
> > > It is unrelated in the sense that the SGMII PHY is a different
> > > kernel object, and the mv88e6xxx is polluting its OF node with
> > > properties which it then interprets as its own, when the PHY driver
> > > may have wanted to configure its SGMII TX amplitude too, via those same
> generic properties.
> > >
> > > > I guess this code is from before the time Russell converted the
> > > > mv88e6xxx SERDES code into PCS drivers. The register being set is
> > > > within the PCS register set.  The mv88e6xxx also does not make use
> > > > of generic phys to represent the SERDES part of the PCS. So there
> > > > is no phys phandle to follow since there is no phy.
> > >
> > > In my view, the phy-common-props.yaml are supposed to be applicable
> > > to
> > > either:
> > > (1) a network PHY with SerDes host-side connection (I suppose the media
> > >     side electrical properties would be covered by Maxime's phy_port
> > >     work - Maxime, please confirm).
> > > (2) a phylink_pcs with SerDes registers within the same register set
> > > (3) a generic PHY
> > >
> > > My patch 8/9 (net: phy: air_en8811h: deprecate "airoha,pnswap-rx"
> > > and
> > > "airoha,pnswap-tx") is an example of case (1) for polarities. Also,
> > > for example, at least Aquantia Gen3 PHYs (AQR111, AQR112) have a
> > > (not very well
> > > documented) "SerDes Lane 0 Amplitude" field in the PHY XS Receive
> > > (XAUI TX) Reserved Vendor Provisioning 4 register (address 4.E413).
> > >
> > > My patch 7/9 (net: pcs: xpcs: allow lane polarity inversion) is an
> > > example of case (2).
> > >
> > > I haven't submitted an example of case (3) yet, but the Lynx PCS and
> > > Lynx SerDes would fall into that category. The PCS would be free of
> > > describing electrical properties, and those would go to the generic PHY
> (SerDes).
> > >
> > > All I'm trying to say is that we're missing an OF node to describe
> > > mv88e6xxx PCS electrical properties, because otherwise, it collides
> > > with case (1). My note regarding "phys" was just a guess that the "phy-
> handle"
> > > may have been mistaken for the port's SerDes PHY. Although there is
> > > a chance Holger knew what he was doing. In any case, I think we need
> > > to sort this one way or another, leaving the phy-handle logic a discouraged
> fallback path.
> > >
> >
> > I was checking our use case, and it is a bit special. We have the port
> > in question directly connected to a FPGA which has also have a SerDes
> > interface. We are then configuring a fixed link to the FPGA without a
> > phy in between so there is also no phy handle in our case. But in
> > general, the board in question is now in maintenance and there will be
> > no kernel update anymore in the future. Therefore, it is fine with me if you
> remove or rework the code in question completely. Hope that helps.
> >
> > Best regards
> > Holger
> 
> Thanks for the response. So given this clarification, how was commit
> 926eae604403 ("dsa: mv88e6xxx: make serdes SGMII/Fiber tx amplitude
> configurable") useful for you?

the Kirkwood based board in question was OOT. Due to the patch we were
able to use the mainline driver without patching it to configure the value we
wanted.

The DTS node looked like this:

&mdio {
        status = "okay";

        switch@10 {
                compatible = "marvell,mv88e6085";
                #address-cells = <1>;
                #size-cells = <0>;
                reg = <0x10>;
                ports {
                        #address-cells = <1>;
                        #size-cells = <0>;
                        port@4 {
                                reg = <4>;
                                label = "port4";
                                phy-connection-type = "sgmii";
                                tx-p2p-microvolt = <604000>;
                                fixed-link {
                                        speed = <1000>;
                                        full-duplex;
                                };
                        };
	};
};

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Vladimir Oltean]

On Wed, Nov 26, 2025 at 10:45:31AM +0000, Holger Brunck wrote:
> the Kirkwood based board in question was OOT. Due to the patch we were
> able to use the mainline driver without patching it to configure the value we
> wanted.
> 
> The DTS node looked like this:
> 
> &mdio {
>         status = "okay";
> 
>         switch@10 {
>                 compatible = "marvell,mv88e6085";
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>                 reg = <0x10>;
>                 ports {
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>                         port@4 {
>                                 reg = <4>;
>                                 label = "port4";
>                                 phy-connection-type = "sgmii";
>                                 tx-p2p-microvolt = <604000>;
>                                 fixed-link {
>                                         speed = <1000>;
>                                         full-duplex;
>                                 };
>                         };
> 	};
> };

Perhaps there is some bit I'm missing, but let me try and run the code
on your sample device tree.

mv88e6xxx_setup_port()
	if (chip->info->ops->serdes_set_tx_amplitude) {
		dp = dsa_to_port(ds, port);
		if (dp)
			phy_handle = of_parse_phandle(dp->dn, "phy-handle", 0);

		if (phy_handle && !of_property_read_u32(phy_handle,
							"tx-p2p-microvolt",
							&tx_amp))
			err = chip->info->ops->serdes_set_tx_amplitude(chip,
								port, tx_amp);
		if (phy_handle) {
			of_node_put(phy_handle);
			if (err)
				return err;
		}
	}

dp->dn is the "port@4" node.
phy_handle is NULL, because the "port@4" node has no "phy-handle" property.
of_property_read_u32(phy_handle, "tx-p2p-microvolt") does not run
so chip->info->ops->serdes_set_tx_amplitude() is never called

I'm unable to reconcile the placement of the "tx-p2p-microvolt" property
in the port OF node with the code that searches for it exclusively in
the network PHY node.

RE: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Holger Brunck]

> 
> On Wed, Nov 26, 2025 at 10:45:31AM +0000, Holger Brunck wrote:
> > the Kirkwood based board in question was OOT. Due to the patch we were
> > able to use the mainline driver without patching it to configure the
> > value we wanted.
> >
> > The DTS node looked like this:
> >
> > &mdio {
> >         status = "okay";
> >
> >         switch@10 {
> >                 compatible = "marvell,mv88e6085";
> >                 #address-cells = <1>;
> >                 #size-cells = <0>;
> >                 reg = <0x10>;
> >                 ports {
> >                         #address-cells = <1>;
> >                         #size-cells = <0>;
> >                         port@4 {
> >                                 reg = <4>;
> >                                 label = "port4";
> >                                 phy-connection-type = "sgmii";
> >                                 tx-p2p-microvolt = <604000>;
> >                                 fixed-link {
> >                                         speed = <1000>;
> >                                         full-duplex;
> >                                 };
> >                         };
> >       };
> > };
> 
> Perhaps there is some bit I'm missing, but let me try and run the code on your
> sample device tree.
> 
> mv88e6xxx_setup_port()
>         if (chip->info->ops->serdes_set_tx_amplitude) {
>                 dp = dsa_to_port(ds, port);
>                 if (dp)
>                         phy_handle = of_parse_phandle(dp->dn, "phy-handle", 0);
> 
>                 if (phy_handle && !of_property_read_u32(phy_handle,
>                                                         "tx-p2p-microvolt",
>                                                         &tx_amp))
>                         err = chip->info->ops->serdes_set_tx_amplitude(chip,
>                                                                 port, tx_amp);
>                 if (phy_handle) {
>                         of_node_put(phy_handle);
>                         if (err)
>                                 return err;
>                 }
>         }
> 
> dp->dn is the "port@4" node.
> phy_handle is NULL, because the "port@4" node has no "phy-handle" property.
> of_property_read_u32(phy_handle, "tx-p2p-microvolt") does not run so chip-
> >info->ops->serdes_set_tx_amplitude() is never called
> 
> I'm unable to reconcile the placement of the "tx-p2p-microvolt" property in the
> port OF node with the code that searches for it exclusively in the network PHY
> node.

you are right I double checked it and it cannot work without a phy-handle. Not
sure, about the history of this patch anymore, but the board did run a 5.4 kernel
at that time.

So I agree that the use case I had does not work as it is implemented here. So the code
should be either removed or reworked.

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Andrew Lunn]

> All I'm trying to say is that we're missing an OF node to describe
> mv88e6xxx PCS electrical properties, because otherwise, it collides with
> case (1). My note regarding "phys" was just a guess that the "phy-handle"
> may have been mistaken for the port's SerDes PHY. Although there is a
> chance Holger knew what he was doing. In any case, I think we need to
> sort this one way or another, leaving the phy-handle logic a discouraged
> fallback path.
> 
> That being said, I'm not exactly an expert in determining _how_ we could
> best retrofit SerDes/PCS OF nodes on top of the mv88e6xxx bindings.
> It depends on how many SerDes ports there are in these switches
> architecturally, and what is their register access method, so it would
> need to be handled on a case-by-case basis rather than one-size-fits-all.
> PCS node in port node could be a starting point, I guess, but I don't
> know if it would work.

I would more likely have a PCS container node and then list each PCS
within it, using reg as the MDIO bus address. The 6352 has one PCS,
but depending on configuration port 5 or port 6 can make use of it. (I
might have the numbers wrong, but the principle is correct). Some of
the other switches have more PCSs but with a fixed mapping to
ports. And the 6390X has 2x 10G PCS. But you can take this 10G PCS and
split it into 2x 5G. And you can take those 5G PCS and split it into
two to give a PCS which can do 1/2.5G.

Given this flexibility, putting the PCS in the port would probably be
a bad idea.

	Andrew

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Maxime Chevallier]

Hi,

On 26/11/2025 08:26, Vladimir Oltean wrote:
> +Maxime, Holger
> thread at https://lore.kernel.org/netdev/20251122193341.332324-2-vladimir.oltean@nxp.com/
> 
> On Tue, Nov 25, 2025 at 11:33:09PM +0100, Andrew Lunn wrote:
>>> Yeah, although as things currently stand, I'd say that is the lesser of
>>> problems. The only user (mv88e6xxx) does something strange: it says it
>>> wants to configure the TX amplitude of SerDes ports, but instead follows
>>> the phy-handle and applies the amplitude specified in that node.
>>>
>>> I tried to mentally follow how things would work in 2 cases:
>>> 1. PHY referenced by phy-handle is internal, then by definition it's not
>>>    a SerDes port.
>>> 2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
>>>    looks at what is essentially a device tree description of the PHY's
>>>    TX, and applies that as a mirror image to the local SerDes' TX.
>>>
>>> I think the logic is used in mv88e6xxx through case #2, i.e. we
>>> externalize the mv88e6xxx SerDes electrical properties to an unrelated
>>> OF node, the connected Ethernet PHY.
>>
>> My understanding of the code is the same, #2. Although i would
>> probably not say it is an unrelated node. I expect the PHY is on the
>> other end of the SERDES link which is having the TX amplitudes
>> set. This clearly will not work if there is an SFP cage on the other
>> end, but it does for an SGMII PHY.
> 
> It is unrelated in the sense that the SGMII PHY is a different kernel
> object, and the mv88e6xxx is polluting its OF node with properties which
> it then interprets as its own, when the PHY driver may have wanted to
> configure its SGMII TX amplitude too, via those same generic properties.
> 
>> I guess this code is from before the time Russell converted the
>> mv88e6xxx SERDES code into PCS drivers. The register being set is
>> within the PCS register set.  The mv88e6xxx also does not make use of
>> generic phys to represent the SERDES part of the PCS. So there is no
>> phys phandle to follow since there is no phy.
> 
> In my view, the phy-common-props.yaml are supposed to be applicable to either:
> (1) a network PHY with SerDes host-side connection (I suppose the media
>     side electrical properties would be covered by Maxime's phy_port
>     work - Maxime, please confirm).

True, but we could definitely conceive applying phy-common-props.yaml on
the media-side as well :) I don't have a use-case for it right now
though, and we don't yet have detailed descriptions of the electrical
properties.

Maxime

Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

[Rob Herring (Arm)]

On Sat, 22 Nov 2025 21:33:33 +0200, Vladimir Oltean wrote:
> I would like to add more properties similar to tx-p2p-microvolt, and I
> don't think it makes sense to create one schema for each such property
> (transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml
> etc).
> 
> Instead, let's rename to phy-common-props.yaml, which makes it a more
> adequate host schema for all the above properties.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  .../{transmit-amplitude.yaml => phy-common-props.yaml}    | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>  rename Documentation/devicetree/bindings/phy/{transmit-amplitude.yaml => phy-common-props.yaml} (90%)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH net-next 2/9] dt-bindings: phy-common-props: create a reusable "protocol-names" definition

[Vladimir Oltean]

Other properties also need to be defined per protocol than just
tx-p2p-microvolt-names. Create a common definition to avoid copying a 55
line property.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 .../bindings/phy/phy-common-props.yaml        | 34 +++++++++++--------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-common-props.yaml b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
index 255205ac09cd..775f4dfe3cc3 100644
--- a/Documentation/devicetree/bindings/phy/phy-common-props.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
@@ -13,22 +13,12 @@ description:
 maintainers:
   - Marek Behún <kabel@kernel.org>
 
-properties:
-  tx-p2p-microvolt:
+$defs:
+  protocol-names:
     description:
-      Transmit amplitude voltages in microvolts, peak-to-peak. If this property
-      contains multiple values for various PHY modes, the
-      'tx-p2p-microvolt-names' property must be provided and contain
-      corresponding mode names.
-
-  tx-p2p-microvolt-names:
-    description: |
-      Names of the modes corresponding to voltages in the 'tx-p2p-microvolt'
-      property. Required only if multiple voltages are provided.
-
-      If a value of 'default' is provided, the system should use it for any PHY
-      mode that is otherwise not defined here. If 'default' is not provided, the
-      system should use manufacturer default value.
+      Names of the PHY modes. If a value of 'default' is provided, the system
+      should use it for any PHY mode that is otherwise not defined here. If
+      'default' is not provided, the system should use manufacturer default value.
     minItems: 1
     maxItems: 16
     items:
@@ -89,6 +79,20 @@ properties:
         - mipi-dphy-univ
         - mipi-dphy-v2.5-univ
 
+properties:
+  tx-p2p-microvolt:
+    description:
+      Transmit amplitude voltages in microvolts, peak-to-peak. If this property
+      contains multiple values for various PHY modes, the
+      'tx-p2p-microvolt-names' property must be provided and contain
+      corresponding mode names.
+
+  tx-p2p-microvolt-names:
+    description:
+      Names of the modes corresponding to voltages in the 'tx-p2p-microvolt'
+      property. Required only if multiple voltages are provided.
+    $ref: "#/$defs/protocol-names"
+
 dependencies:
   tx-p2p-microvolt-names: [ tx-p2p-microvolt ]
 
-- 
2.34.1

Re: [PATCH net-next 2/9] dt-bindings: phy-common-props: create a reusable "protocol-names" definition

[Rob Herring]

On Sat, Nov 22, 2025 at 09:33:34PM +0200, Vladimir Oltean wrote:
> Other properties also need to be defined per protocol than just
> tx-p2p-microvolt-names. Create a common definition to avoid copying a 55
> line property.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  .../bindings/phy/phy-common-props.yaml        | 34 +++++++++++--------
>  1 file changed, 19 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-common-props.yaml b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
> index 255205ac09cd..775f4dfe3cc3 100644
> --- a/Documentation/devicetree/bindings/phy/phy-common-props.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
> @@ -13,22 +13,12 @@ description:
>  maintainers:
>    - Marek Behún <kabel@kernel.org>
>  
> -properties:
> -  tx-p2p-microvolt:
> +$defs:
> +  protocol-names:
>      description:
> -      Transmit amplitude voltages in microvolts, peak-to-peak. If this property
> -      contains multiple values for various PHY modes, the
> -      'tx-p2p-microvolt-names' property must be provided and contain
> -      corresponding mode names.
> -
> -  tx-p2p-microvolt-names:
> -    description: |
> -      Names of the modes corresponding to voltages in the 'tx-p2p-microvolt'
> -      property. Required only if multiple voltages are provided.
> -
> -      If a value of 'default' is provided, the system should use it for any PHY
> -      mode that is otherwise not defined here. If 'default' is not provided, the
> -      system should use manufacturer default value.
> +      Names of the PHY modes. If a value of 'default' is provided, the system
> +      should use it for any PHY mode that is otherwise not defined here. If
> +      'default' is not provided, the system should use manufacturer default value.
>      minItems: 1
>      maxItems: 16
>      items:
> @@ -89,6 +79,20 @@ properties:
>          - mipi-dphy-univ
>          - mipi-dphy-v2.5-univ
>  
> +properties:
> +  tx-p2p-microvolt:
> +    description:
> +      Transmit amplitude voltages in microvolts, peak-to-peak. If this property
> +      contains multiple values for various PHY modes, the
> +      'tx-p2p-microvolt-names' property must be provided and contain
> +      corresponding mode names.
> +
> +  tx-p2p-microvolt-names:
> +    description:
> +      Names of the modes corresponding to voltages in the 'tx-p2p-microvolt'
> +      property. Required only if multiple voltages are provided.
> +    $ref: "#/$defs/protocol-names"

The default for .*-names is the entries don't have to be unique. That's 
for the exception, but unfortunately everyone else has to define the 
type (type.yaml#/definitons/string).

Each user needs to define the names of the entries which will enforce 
the length. So defining the length 1-16 here doesn't do much. So I think 
you can drop that and then the $defs is not needed either.

Rob

Re: [PATCH net-next 2/9] dt-bindings: phy-common-props: create a reusable "protocol-names" definition

[Rob Herring]

On Thu, Dec 04, 2025 at 09:52:19AM -0600, Rob Herring wrote:
> On Sat, Nov 22, 2025 at 09:33:34PM +0200, Vladimir Oltean wrote:
> > Other properties also need to be defined per protocol than just
> > tx-p2p-microvolt-names. Create a common definition to avoid copying a 55
> > line property.
> > 
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > ---
> >  .../bindings/phy/phy-common-props.yaml        | 34 +++++++++++--------
> >  1 file changed, 19 insertions(+), 15 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-common-props.yaml b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
> > index 255205ac09cd..775f4dfe3cc3 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-common-props.yaml
> > +++ b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
> > @@ -13,22 +13,12 @@ description:
> >  maintainers:
> >    - Marek Behún <kabel@kernel.org>
> >  
> > -properties:
> > -  tx-p2p-microvolt:
> > +$defs:
> > +  protocol-names:
> >      description:
> > -      Transmit amplitude voltages in microvolts, peak-to-peak. If this property
> > -      contains multiple values for various PHY modes, the
> > -      'tx-p2p-microvolt-names' property must be provided and contain
> > -      corresponding mode names.
> > -
> > -  tx-p2p-microvolt-names:
> > -    description: |
> > -      Names of the modes corresponding to voltages in the 'tx-p2p-microvolt'
> > -      property. Required only if multiple voltages are provided.
> > -
> > -      If a value of 'default' is provided, the system should use it for any PHY
> > -      mode that is otherwise not defined here. If 'default' is not provided, the
> > -      system should use manufacturer default value.
> > +      Names of the PHY modes. If a value of 'default' is provided, the system
> > +      should use it for any PHY mode that is otherwise not defined here. If
> > +      'default' is not provided, the system should use manufacturer default value.
> >      minItems: 1
> >      maxItems: 16
> >      items:
> > @@ -89,6 +79,20 @@ properties:
> >          - mipi-dphy-univ
> >          - mipi-dphy-v2.5-univ
> >  
> > +properties:
> > +  tx-p2p-microvolt:
> > +    description:
> > +      Transmit amplitude voltages in microvolts, peak-to-peak. If this property
> > +      contains multiple values for various PHY modes, the
> > +      'tx-p2p-microvolt-names' property must be provided and contain
> > +      corresponding mode names.
> > +
> > +  tx-p2p-microvolt-names:
> > +    description:
> > +      Names of the modes corresponding to voltages in the 'tx-p2p-microvolt'
> > +      property. Required only if multiple voltages are provided.
> > +    $ref: "#/$defs/protocol-names"
> 
> The default for .*-names is the entries don't have to be unique. That's 
> for the exception, but unfortunately everyone else has to define the 
> type (type.yaml#/definitons/string).
> 
> Each user needs to define the names of the entries which will enforce 
> the length. So defining the length 1-16 here doesn't do much. So I think 
> you can drop that and then the $defs is not needed either.

I missed that all the names are defined here. Nevermind on the 2nd 
point. We probably still need either a $ref or 'uniqueItems: true'. 
Either way should work.

Rob

[PATCH net-next 3/9] dt-bindings: phy-common-props: RX and TX lane polarity inversion

[Vladimir Oltean]

Differential signaling is a technique for high-speed protocols to be
more resilient to noise. At the transmit side we have a positive and a
negative signal which are mirror images of each other. At the receiver,
if we subtract the negative signal (say of amplitude -A) from the
positive signal (say +A), we recover the original single-ended signal at
twice its original amplitude. But any noise, like one coming from EMI
from outside sources, is supposed to have an almost equal impact upon
the positive (A + E, E being for "error") and negative signal (-A + E).
So (A + E) - (-A + E) eliminates this noise, and this is what makes
differential signaling useful.

Except that in order to work, there must be strict requirements observed
during PCB design and layout, like the signal traces needing to have the
same length and be physically close to each other, and many others.

Sometimes it is not easy to fulfill all these requirements, a simple
case to understand is when on chip A's pins, the positive pin is on the
left and the negative is on the right, but on the chip B's pins (with
which A tries to communicate), positive is on the right and negative on
the left. The signals would need to cross, using vias and other ugly
stuff that affects signal integrity (introduces impedance
discontinuities which cause reflections, etc).

So sometimes, board designers intentionally connect differential lanes
the wrong way, and expect somebody else to invert that signal to recover
useful data. This is where RX and TX polarity inversion comes in as a
generic concept that applies to any high-speed serial protocol as long
as it uses differential signaling.

I've stopped two attempts to introduce more vendor-specific descriptions
of this only in the past month:
https://lore.kernel.org/linux-phy/20251110110536.2596490-1-horatiu.vultur@microchip.com/
https://lore.kernel.org/netdev/20251028000959.3kiac5kwo5pcl4ft@skbuf/

and in the kernel we already have merged:
- "st,px_rx_pol_inv"
- "st,pcie-tx-pol-inv"
- "st,sata-tx-pol-inv"
- "mediatek,pnswap"
- "airoha,pnswap-rx"
- "airoha,pnswap-tx"

and maybe more. So it is pretty general.

One additional element of complexity is introduced by the fact that for
some protocols, receivers can automatically detect and correct for an
inverted lane polarity (example: the PCIe LTSSM does this in the
Polling.Configuration state; the USB 3.1 Link Layer Test Specification
says that the detection and correction of the lane polarity inversion in
SuperSpeed operation shall be enabled in Polling.RxEQ.). Whereas for
other protocols (SGMII, SATA, 10GBase-R, etc etc), the polarity is all
manual and there is no detection mechanism mandated by their respective
standards.

So why would one even describe rx-polarity and tx-polarity for protocols
like PCIe, if it had to always be PHY_POL_AUTO?

Related question: why would we define the polarity as an array per
protocol? Isn't the physical PCB layout protocol-agnostic, and aren't we
describing the same physical reality from the lens of different protocols?

The answer to both questions is because multi-protocol PHYs exist
(supporting e.g. USB2 and USB3, or SATA and PCIe, or PCIe and Ethernet
over the same lane), one would need to manually set the polarity for
SATA/Ethernet, while leaving it at auto for PCIe/USB 3.0+.

I also investigated from another angle: what if polarity inversion in
the PHY is one layer, and then the PCIe/USB3 LTSSM polarity detection is
another layer on top? Then rx-polarity = <PHY_POL_AUTO> doesn't make
sense, it can still be rx-polarity = <PHY_POL_NORMAL> or <PHY_POL_INVERT>,
and the link training state machine figures things out on top of that.
This would radically simplify the design, as the elimination of
PHY_POL_AUTO inherently means that the need for a property array per
protocol also goes away.

I don't know how things are in the general case, but at least in the 10G
and 28G Lynx SerDes blocks from NXP Layerscape devices, this isn't the
case, and there's only a single level of RX polarity inversion: in the
SerDes lane. In the case of PCIe, the controller is in charge of driving
the RDAT_INV bit autonomously, and it is read-only to software.

So the existence of this kind of SerDes lane proves the need for
PHY_POL_AUTO to be a third state.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 .../bindings/phy/phy-common-props.yaml        | 45 +++++++++++++++++++
 include/dt-bindings/phy/phy.h                 |  4 ++
 2 files changed, 49 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-common-props.yaml b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
index 775f4dfe3cc3..538b85559113 100644
--- a/Documentation/devicetree/bindings/phy/phy-common-props.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-common-props.yaml
@@ -93,15 +93,60 @@ properties:
       property. Required only if multiple voltages are provided.
     $ref: "#/$defs/protocol-names"
 
+  rx-polarity:
+    description:
+      An array of values indicating whether the differential receiver's
+      polarity is inverted. Each value can be one of
+      PHY_POL_NORMAL (0) which means the negative signal is decoded from the
+      RXN pin, and the positive signal from the the RXP pin;
+      PHY_POL_INVERT (1) which means the negative signal is decoded from the
+      RXP pin, and the positive signal from the RXN pin;
+      PHY_POL_AUTO (2) which means the receiver performs automatic polarity
+      detection and correction, which is a mandatory part of link training for
+      some protocols (PCIe, USB SS).
+
+      The values are defined in <dt-bindings/phy/phy.h>.
+
+      If this property contains multiple values for various protocols, the
+      'rx-polarity-names' property must be provided.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 16
+    items:
+      enum: [0, 1, 2]
+
+  rx-polarity-names:
+    $ref: '#/$defs/protocol-names'
+
+  tx-polarity:
+    description:
+      Like 'rx-polarity', except it applies to differential transmitters,
+      and only the values of PHY_POL_NORMAL and PHY_POL_INVERT are possible.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 16
+    items:
+      enum: [0, 1]
+
+  tx-polarity-names:
+    $ref: '#/$defs/protocol-names'
+
 dependencies:
   tx-p2p-microvolt-names: [ tx-p2p-microvolt ]
+  rx-polarity-names: [ rx-polarity ]
+  tx-polarity-names: [ tx-polarity ]
 
 additionalProperties: true
 
 examples:
   - |
+    #include <dt-bindings/phy/phy.h>
+
     phy: phy {
       #phy-cells = <1>;
       tx-p2p-microvolt = <915000>, <1100000>, <1200000>;
       tx-p2p-microvolt-names = "2500base-x", "usb-hs", "usb-ss";
+      rx-polarity = <PHY_POL_AUTO>, <PHY_POL_NORMAL>;
+      rx-polarity-names = "usb-ss", "default";
+      tx-polarity = <PHY_POL_INVERT>;
     };
diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 6b901b342348..f8d4094f0880 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -24,4 +24,8 @@
 #define PHY_TYPE_CPHY		11
 #define PHY_TYPE_USXGMII	12
 
+#define PHY_POL_NORMAL		0
+#define PHY_POL_INVERT		1
+#define PHY_POL_AUTO		2
+
 #endif /* _DT_BINDINGS_PHY */
-- 
2.34.1

Re: [PATCH net-next 3/9] dt-bindings: phy-common-props: RX and TX lane polarity inversion

[Rob Herring (Arm)]

On Sat, 22 Nov 2025 21:33:35 +0200, Vladimir Oltean wrote:
> Differential signaling is a technique for high-speed protocols to be
> more resilient to noise. At the transmit side we have a positive and a
> negative signal which are mirror images of each other. At the receiver,
> if we subtract the negative signal (say of amplitude -A) from the
> positive signal (say +A), we recover the original single-ended signal at
> twice its original amplitude. But any noise, like one coming from EMI
> from outside sources, is supposed to have an almost equal impact upon
> the positive (A + E, E being for "error") and negative signal (-A + E).
> So (A + E) - (-A + E) eliminates this noise, and this is what makes
> differential signaling useful.
> 
> Except that in order to work, there must be strict requirements observed
> during PCB design and layout, like the signal traces needing to have the
> same length and be physically close to each other, and many others.
> 
> Sometimes it is not easy to fulfill all these requirements, a simple
> case to understand is when on chip A's pins, the positive pin is on the
> left and the negative is on the right, but on the chip B's pins (with
> which A tries to communicate), positive is on the right and negative on
> the left. The signals would need to cross, using vias and other ugly
> stuff that affects signal integrity (introduces impedance
> discontinuities which cause reflections, etc).
> 
> So sometimes, board designers intentionally connect differential lanes
> the wrong way, and expect somebody else to invert that signal to recover
> useful data. This is where RX and TX polarity inversion comes in as a
> generic concept that applies to any high-speed serial protocol as long
> as it uses differential signaling.
> 
> I've stopped two attempts to introduce more vendor-specific descriptions
> of this only in the past month:
> https://lore.kernel.org/linux-phy/20251110110536.2596490-1-horatiu.vultur@microchip.com/
> https://lore.kernel.org/netdev/20251028000959.3kiac5kwo5pcl4ft@skbuf/
> 
> and in the kernel we already have merged:
> - "st,px_rx_pol_inv"
> - "st,pcie-tx-pol-inv"
> - "st,sata-tx-pol-inv"
> - "mediatek,pnswap"
> - "airoha,pnswap-rx"
> - "airoha,pnswap-tx"
> 
> and maybe more. So it is pretty general.
> 
> One additional element of complexity is introduced by the fact that for
> some protocols, receivers can automatically detect and correct for an
> inverted lane polarity (example: the PCIe LTSSM does this in the
> Polling.Configuration state; the USB 3.1 Link Layer Test Specification
> says that the detection and correction of the lane polarity inversion in
> SuperSpeed operation shall be enabled in Polling.RxEQ.). Whereas for
> other protocols (SGMII, SATA, 10GBase-R, etc etc), the polarity is all
> manual and there is no detection mechanism mandated by their respective
> standards.
> 
> So why would one even describe rx-polarity and tx-polarity for protocols
> like PCIe, if it had to always be PHY_POL_AUTO?
> 
> Related question: why would we define the polarity as an array per
> protocol? Isn't the physical PCB layout protocol-agnostic, and aren't we
> describing the same physical reality from the lens of different protocols?
> 
> The answer to both questions is because multi-protocol PHYs exist
> (supporting e.g. USB2 and USB3, or SATA and PCIe, or PCIe and Ethernet
> over the same lane), one would need to manually set the polarity for
> SATA/Ethernet, while leaving it at auto for PCIe/USB 3.0+.
> 
> I also investigated from another angle: what if polarity inversion in
> the PHY is one layer, and then the PCIe/USB3 LTSSM polarity detection is
> another layer on top? Then rx-polarity = <PHY_POL_AUTO> doesn't make
> sense, it can still be rx-polarity = <PHY_POL_NORMAL> or <PHY_POL_INVERT>,
> and the link training state machine figures things out on top of that.
> This would radically simplify the design, as the elimination of
> PHY_POL_AUTO inherently means that the need for a property array per
> protocol also goes away.
> 
> I don't know how things are in the general case, but at least in the 10G
> and 28G Lynx SerDes blocks from NXP Layerscape devices, this isn't the
> case, and there's only a single level of RX polarity inversion: in the
> SerDes lane. In the case of PCIe, the controller is in charge of driving
> the RDAT_INV bit autonomously, and it is read-only to software.
> 
> So the existence of this kind of SerDes lane proves the need for
> PHY_POL_AUTO to be a third state.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  .../bindings/phy/phy-common-props.yaml        | 45 +++++++++++++++++++
>  include/dt-bindings/phy/phy.h                 |  4 ++
>  2 files changed, 49 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH net-next 4/9] dt-bindings: net: xpcs: allow properties from phy-common-props.yaml

[Vladimir Oltean]

Now XPCS device tree nodes can specify properties to configure transmit
amplitude, receiver polarity inversion, and transmitter polarity
inversion for different PHY protocols.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml b/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml
index e77eec9ac9ee..9977a3153f41 100644
--- a/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml
@@ -22,6 +22,9 @@ description:
   by means of the APB3/MCI interfaces. In the later case the XPCS can be mapped
   right to the system IO memory space.
 
+allOf:
+  - $ref: /schemas/phy/phy-common-props.yaml#
+
 properties:
   compatible:
     oneOf:
@@ -102,7 +105,7 @@ required:
   - compatible
   - reg
 
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |
-- 
2.34.1

Re: [PATCH net-next 4/9] dt-bindings: net: xpcs: allow properties from phy-common-props.yaml

[Rob Herring (Arm)]

On Sat, 22 Nov 2025 21:33:36 +0200, Vladimir Oltean wrote:
> Now XPCS device tree nodes can specify properties to configure transmit
> amplitude, receiver polarity inversion, and transmitter polarity
> inversion for different PHY protocols.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Vladimir Oltean]

Add helpers in the generic PHY folder which can be used using 'select
GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
enable GENERIC_PHY.

These helpers need to deal with the slight messiness of the fact that
the polarity properties are arrays per protocol, and with the fact that
there is no default value mandated by the standard properties, all
default values depend on driver and protocol (PHY_POL_NORMAL may be a
good default for SGMII, whereas PHY_POL_AUTO may be a good default for
PCIe).

Push the supported mask of polarities to these helpers, to simplify
drivers such that they don't need to validate what's in the device tree
(or other firmware description).

The proposed maintainership model is joint custody between netdev and
linux-phy, because of the fact that these properties can be applied to
Ethernet PCS blocks just as well as Generic PHY devices. I've added as
maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
"GENERIC PHY FRAMEWORK".

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 MAINTAINERS                          |  21 +++++
 drivers/phy/Kconfig                  |   9 +++
 drivers/phy/Makefile                 |   1 +
 drivers/phy/phy-common-props.c       | 117 +++++++++++++++++++++++++++
 include/linux/phy/phy-common-props.h |  20 +++++
 5 files changed, 168 insertions(+)
 create mode 100644 drivers/phy/phy-common-props.c
 create mode 100644 include/linux/phy/phy-common-props.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e9a8d945632b..658feb06cc29 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10445,6 +10445,27 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
 F:	include/asm-generic/
 F:	include/uapi/asm-generic/
 
+GENERIC PHY COMMON PROPERTIES
+M:	Andrew Lunn <andrew@lunn.ch>
+M:	"David S. Miller" <davem@davemloft.net>
+M:	Eric Dumazet <edumazet@google.com>
+M:	Heiner Kallweit <hkallweit1@gmail.com>
+M:	Jakub Kicinski <kuba@kernel.org>
+M:	Kishon Vijay Abraham I <kishon@kernel.org>
+M:	Paolo Abeni <pabeni@redhat.com>
+R:	Russell King <linux@armlinux.org.uk>
+M:	Vinod Koul <vkoul@kernel.org>
+L:	linux-phy@lists.infradead.org
+L:	netdev@vger.kernel.org
+S:	Maintained
+Q:	https://patchwork.kernel.org/project/linux-phy/list/
+Q:	https://patchwork.kernel.org/project/netdevbpf/list/
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git
+F:	Documentation/devicetree/bindings/phy/phy-common-props.yaml
+F:	drivers/phy/phy-common-props.c
+
 GENERIC PHY FRAMEWORK
 M:	Vinod Koul <vkoul@kernel.org>
 M:	Kishon Vijay Abraham I <kishon@kernel.org>
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 678dd0452f0a..479986434086 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -16,6 +16,15 @@ config GENERIC_PHY
 	  phy users can obtain reference to the PHY. All the users of this
 	  framework should select this config.
 
+config GENERIC_PHY_COMMON_PROPS
+	bool
+	help
+	  Generic PHY common property parsing.
+
+	  Select this from consumer drivers to gain access to helpers for
+	  parsing properties from the
+	  Documentation/devicetree/bindings/phy/phy-common-props.yaml schema.
+
 config GENERIC_PHY_MIPI_DPHY
 	bool
 	select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index bfb27fb5a494..d07accc15086 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,6 +4,7 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
+obj-$(CONFIG_GENERIC_PHY_COMMON_PROPS)	+= phy-common-props.o
 obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY)	+= phy-core-mipi-dphy.o
 obj-$(CONFIG_PHY_CAN_TRANSCEIVER)	+= phy-can-transceiver.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)	+= phy-lpc18xx-usb-otg.o
diff --git a/drivers/phy/phy-common-props.c b/drivers/phy/phy-common-props.c
new file mode 100644
index 000000000000..4c9dca98d23f
--- /dev/null
+++ b/drivers/phy/phy-common-props.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * phy-common-props.c  --  Common PHY properties
+ *
+ * Copyright 2025 NXP
+ */
+#include <linux/export.h>
+#include <linux/fwnode.h>
+#include <linux/phy/phy-common-props.h>
+#include <linux/printk.h>
+#include <linux/property.h>
+#include <linux/slab.h>
+
+static int phy_get_polarity_for_mode(struct fwnode_handle *fwnode,
+				     const char *mode_name,
+				     unsigned int supported,
+				     unsigned int default_val,
+				     const char *polarity_prop,
+				     const char *names_prop)
+{
+	int err, n_pols, n_names, idx = -1;
+	u32 val, *pols;
+
+	if (!fwnode)
+		return default_val;
+
+	n_pols = fwnode_property_count_u32(fwnode, polarity_prop);
+	if (n_pols <= 0)
+		return default_val;
+
+	n_names = fwnode_property_string_array_count(fwnode, names_prop);
+	if (n_names >= 0 && n_pols != n_names) {
+		pr_err("%pfw mismatch between \"%s\" and \"%s\" property count (%d vs %d)\n",
+		       fwnode, polarity_prop, names_prop, n_pols, n_names);
+		return -EINVAL;
+	}
+
+	if (mode_name)
+		idx = fwnode_property_match_string(fwnode, names_prop, mode_name);
+	if (idx < 0)
+		idx = fwnode_property_match_string(fwnode, names_prop, "default");
+	/*
+	 * If the mode name is missing, it can only mean the specified polarity
+	 * is the default one for all modes, so reject any other polarity count
+	 * than 1.
+	 */
+	if (idx < 0 && n_pols != 1) {
+		pr_err("%pfw \"%s \" property has %d elements, but cannot find \"%s\" in \"%s\" and there is no default value\n",
+		       fwnode, polarity_prop, n_pols, mode_name, names_prop);
+		return -EINVAL;
+	}
+
+	if (n_pols == 1) {
+		err = fwnode_property_read_u32(fwnode, polarity_prop, &val);
+		if (err)
+			return err;
+
+		return val;
+	}
+
+	/* We implicitly know idx >= 0 here */
+	pols = kcalloc(n_pols, sizeof(*pols), GFP_KERNEL);
+	if (!pols)
+		return -ENOMEM;
+
+	err = fwnode_property_read_u32_array(fwnode, polarity_prop, pols, n_pols);
+	if (err == 0) {
+		val = pols[idx];
+		if (!(supported & BIT(val))) {
+			pr_err("%pfw mismatch between '%s' and '%s' property count (%d vs %d)\n",
+			       fwnode, polarity_prop, names_prop, n_pols, n_names);
+			err = -EOPNOTSUPP;
+		}
+	}
+
+	kfree(pols);
+
+	return (err < 0) ? err : val;
+}
+
+/**
+ * phy_get_rx_polarity - Get RX polarity for PHY differential lane
+ * @fwnode: Pointer to the PHY's firmware node.
+ * @mode_name: The name of the PHY mode to look up.
+ * @supported: Bit mask of PHY_POL_NORMAL, PHY_POL_INVERT and PHY_POL_AUTO
+ * @default_val: Default polarity value if property is missing
+ *
+ * Return: One of PHY_POL_NORMAL, PHY_POL_INVERT or PHY_POL_AUTO on success, or
+ *	   negative error on failure.
+ */
+int phy_get_rx_polarity(struct fwnode_handle *fwnode, const char *mode_name,
+			unsigned int supported, unsigned int default_val)
+{
+	return phy_get_polarity_for_mode(fwnode, mode_name, supported,
+					 default_val, "rx-polarity",
+					 "rx-polarity-names");
+}
+EXPORT_SYMBOL_GPL(phy_get_rx_polarity);
+
+/**
+ * phy_get_tx_polarity - Get TX polarity for PHY differential lane
+ * @fwnode: Pointer to the PHY's firmware node.
+ * @mode_name: The name of the PHY mode to look up.
+ * @supported: Bit mask of PHY_POL_NORMAL and PHY_POL_INVERT
+ * @default_val: Default polarity value if property is missing
+ *
+ * Return: One of PHY_POL_NORMAL or PHY_POL_INVERT on success, or negative
+ *	   error on failure.
+ */
+int phy_get_tx_polarity(struct fwnode_handle *fwnode, const char *mode_name,
+			unsigned int supported, unsigned int default_val)
+{
+	return phy_get_polarity_for_mode(fwnode, mode_name, supported,
+					 default_val, "tx-polarity",
+					 "tx-polarity-names");
+}
+EXPORT_SYMBOL_GPL(phy_get_tx_polarity);
diff --git a/include/linux/phy/phy-common-props.h b/include/linux/phy/phy-common-props.h
new file mode 100644
index 000000000000..0b8ba76e2a15
--- /dev/null
+++ b/include/linux/phy/phy-common-props.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * phy-common-props.h -- Common properties for generic PHYs
+ *
+ * Copyright 2025 NXP
+ */
+
+#ifndef __PHY_COMMON_PROPS_H
+#define __PHY_COMMON_PROPS_H
+
+#include <dt-bindings/phy/phy.h>
+
+struct fwnode_handle;
+
+int phy_get_rx_polarity(struct fwnode_handle *fwnode, const char *mode_name,
+			unsigned int supported, unsigned int default_val);
+int phy_get_tx_polarity(struct fwnode_handle *fwnode, const char *mode_name,
+			unsigned int supported, unsigned int default_val);
+
+#endif /* __PHY_COMMON_PROPS_H */
-- 
2.34.1

Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Jakub Kicinski]

On Sat, 22 Nov 2025 21:33:37 +0200 Vladimir Oltean wrote:
> Add helpers in the generic PHY folder which can be used using 'select
> GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
> enable GENERIC_PHY.
> 
> These helpers need to deal with the slight messiness of the fact that
> the polarity properties are arrays per protocol, and with the fact that
> there is no default value mandated by the standard properties, all
> default values depend on driver and protocol (PHY_POL_NORMAL may be a
> good default for SGMII, whereas PHY_POL_AUTO may be a good default for
> PCIe).
> 
> Push the supported mask of polarities to these helpers, to simplify
> drivers such that they don't need to validate what's in the device tree
> (or other firmware description).
> 
> The proposed maintainership model is joint custody between netdev and
> linux-phy, because of the fact that these properties can be applied to
> Ethernet PCS blocks just as well as Generic PHY devices. I've added as
> maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
> "GENERIC PHY FRAMEWORK".

I dunno.. ain't no such thing as "joint custody" maintainership.
We have to pick one tree. Given the set of Ms here, I suspect 
the best course of action may be to bubble this up to its own tree.
Ask Konstantin for a tree in k.org, then you can "co-post" the patches
for review + PR link in the cover letter (e.g. how Tony from Intel
submits their patches). This way not networking and PHY can pull
the shared changes with stable commit IDs.

We can do out-of-sequence netdev call tomorrow if folks want to talk
this thru (8:30am Pacific)

> +GENERIC PHY COMMON PROPERTIES
> +M:	Andrew Lunn <andrew@lunn.ch>
> +M:	"David S. Miller" <davem@davemloft.net>
> +M:	Eric Dumazet <edumazet@google.com>
> +M:	Heiner Kallweit <hkallweit1@gmail.com>
> +M:	Jakub Kicinski <kuba@kernel.org>
> +M:	Kishon Vijay Abraham I <kishon@kernel.org>
> +M:	Paolo Abeni <pabeni@redhat.com>
> +R:	Russell King <linux@armlinux.org.uk>
> +M:	Vinod Koul <vkoul@kernel.org>

checkpatch nit: apparently it wants all Ms first, then all Rs.

> +L:	linux-phy@lists.infradead.org
> +L:	netdev@vger.kernel.org
> +S:	Maintained
> +Q:	https://patchwork.kernel.org/project/linux-phy/list/
> +Q:	https://patchwork.kernel.org/project/netdevbpf/list/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git
> +F:	Documentation/devicetree/bindings/phy/phy-common-props.yaml
> +F:	drivers/phy/phy-common-props.c
-- 
pw-bot: cr

Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Vladimir Oltean]

On Mon, Nov 24, 2025 at 08:01:21PM -0800, Jakub Kicinski wrote:
> > The proposed maintainership model is joint custody between netdev and
> > linux-phy, because of the fact that these properties can be applied to
> > Ethernet PCS blocks just as well as Generic PHY devices. I've added as
> > maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
> > "GENERIC PHY FRAMEWORK".
> 
> I dunno.. ain't no such thing as "joint custody" maintainership.
> We have to pick one tree. Given the set of Ms here, I suspect 
> the best course of action may be to bubble this up to its own tree.
> Ask Konstantin for a tree in k.org, then you can "co-post" the patches
> for review + PR link in the cover letter (e.g. how Tony from Intel
> submits their patches). This way not networking and PHY can pull
> the shared changes with stable commit IDs.

I can see how this makes some sense. If nobody has any objection, I'll
follow up to this by emailing Konstantin about a git tree for shared
infrastructure between generic PHY and networking.

> We can do out-of-sequence netdev call tomorrow if folks want to talk
> this thru (8:30am Pacific)

Not sure it's that big of a discussion topic.

> > +GENERIC PHY COMMON PROPERTIES
> > +M:	Andrew Lunn <andrew@lunn.ch>
> > +M:	"David S. Miller" <davem@davemloft.net>
> > +M:	Eric Dumazet <edumazet@google.com>
> > +M:	Heiner Kallweit <hkallweit1@gmail.com>
> > +M:	Jakub Kicinski <kuba@kernel.org>
> > +M:	Kishon Vijay Abraham I <kishon@kernel.org>
> > +M:	Paolo Abeni <pabeni@redhat.com>
> > +R:	Russell King <linux@armlinux.org.uk>
> > +M:	Vinod Koul <vkoul@kernel.org>
> 
> checkpatch nit: apparently it wants all Ms first, then all Rs.

Thanks for pointing this out.

This will probably have to be changed quite a bit in v2 if the "separate
git tree" idea is going to be implemented. I'll probably start with an
empty list and request volunteers to step up.

Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Vinod Koul]

On 24-11-25, 20:01, Jakub Kicinski wrote:
> On Sat, 22 Nov 2025 21:33:37 +0200 Vladimir Oltean wrote:
> > Add helpers in the generic PHY folder which can be used using 'select
> > GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
> > enable GENERIC_PHY.
> > 
> > These helpers need to deal with the slight messiness of the fact that
> > the polarity properties are arrays per protocol, and with the fact that
> > there is no default value mandated by the standard properties, all
> > default values depend on driver and protocol (PHY_POL_NORMAL may be a
> > good default for SGMII, whereas PHY_POL_AUTO may be a good default for
> > PCIe).
> > 
> > Push the supported mask of polarities to these helpers, to simplify
> > drivers such that they don't need to validate what's in the device tree
> > (or other firmware description).
> > 
> > The proposed maintainership model is joint custody between netdev and
> > linux-phy, because of the fact that these properties can be applied to
> > Ethernet PCS blocks just as well as Generic PHY devices. I've added as
> > maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
> > "GENERIC PHY FRAMEWORK".
> 
> I dunno.. ain't no such thing as "joint custody" maintainership.
> We have to pick one tree. Given the set of Ms here, I suspect 
> the best course of action may be to bubble this up to its own tree.
> Ask Konstantin for a tree in k.org, then you can "co-post" the patches
> for review + PR link in the cover letter (e.g. how Tony from Intel
> submits their patches). This way not networking and PHY can pull
> the shared changes with stable commit IDs.

How much is the volume of the changes that we are talking about, we can
always ack and pull into each other trees..?

BR
-- 
~Vinod

Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Krzysztof Kozlowski]

On 01/12/2025 09:37, Vinod Koul wrote:
> On 24-11-25, 20:01, Jakub Kicinski wrote:
>> On Sat, 22 Nov 2025 21:33:37 +0200 Vladimir Oltean wrote:
>>> Add helpers in the generic PHY folder which can be used using 'select
>>> GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
>>> enable GENERIC_PHY.
>>>
>>> These helpers need to deal with the slight messiness of the fact that
>>> the polarity properties are arrays per protocol, and with the fact that
>>> there is no default value mandated by the standard properties, all
>>> default values depend on driver and protocol (PHY_POL_NORMAL may be a
>>> good default for SGMII, whereas PHY_POL_AUTO may be a good default for
>>> PCIe).
>>>
>>> Push the supported mask of polarities to these helpers, to simplify
>>> drivers such that they don't need to validate what's in the device tree
>>> (or other firmware description).
>>>
>>> The proposed maintainership model is joint custody between netdev and
>>> linux-phy, because of the fact that these properties can be applied to
>>> Ethernet PCS blocks just as well as Generic PHY devices. I've added as
>>> maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
>>> "GENERIC PHY FRAMEWORK".
>>
>> I dunno.. ain't no such thing as "joint custody" maintainership.
>> We have to pick one tree. Given the set of Ms here, I suspect 
>> the best course of action may be to bubble this up to its own tree.
>> Ask Konstantin for a tree in k.org, then you can "co-post" the patches
>> for review + PR link in the cover letter (e.g. how Tony from Intel
>> submits their patches). This way not networking and PHY can pull
>> the shared changes with stable commit IDs.
> 
> How much is the volume of the changes that we are talking about, we can
> always ack and pull into each other trees..?

That's just one C file, isn't it? Having dedicated tree for one file
feels like huge overhead.


Best regards,
Krzysztof

Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Vladimir Oltean]

On Mon, Dec 01, 2025 at 09:41:21AM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2025 09:37, Vinod Koul wrote:
> > On 24-11-25, 20:01, Jakub Kicinski wrote:
> >> On Sat, 22 Nov 2025 21:33:37 +0200 Vladimir Oltean wrote:
> >>> Add helpers in the generic PHY folder which can be used using 'select
> >>> GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
> >>> enable GENERIC_PHY.
> >>>
> >>> These helpers need to deal with the slight messiness of the fact that
> >>> the polarity properties are arrays per protocol, and with the fact that
> >>> there is no default value mandated by the standard properties, all
> >>> default values depend on driver and protocol (PHY_POL_NORMAL may be a
> >>> good default for SGMII, whereas PHY_POL_AUTO may be a good default for
> >>> PCIe).
> >>>
> >>> Push the supported mask of polarities to these helpers, to simplify
> >>> drivers such that they don't need to validate what's in the device tree
> >>> (or other firmware description).
> >>>
> >>> The proposed maintainership model is joint custody between netdev and
> >>> linux-phy, because of the fact that these properties can be applied to
> >>> Ethernet PCS blocks just as well as Generic PHY devices. I've added as
> >>> maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
> >>> "GENERIC PHY FRAMEWORK".
> >>
> >> I dunno.. ain't no such thing as "joint custody" maintainership.
> >> We have to pick one tree. Given the set of Ms here, I suspect 
> >> the best course of action may be to bubble this up to its own tree.
> >> Ask Konstantin for a tree in k.org, then you can "co-post" the patches
> >> for review + PR link in the cover letter (e.g. how Tony from Intel
> >> submits their patches). This way not networking and PHY can pull
> >> the shared changes with stable commit IDs.
> > 
> > How much is the volume of the changes that we are talking about, we can
> > always ack and pull into each other trees..?
> 
> That's just one C file, isn't it? Having dedicated tree for one file
> feels like huge overhead.

I have to admit, no matter how we define what pertains to this presumed
new git tree, the fact is that the volume of patches will be quite low.

Since the API provider always sits in drivers/phy/ in every case that I
can think about, technically all situations can be resolved by linux-phy
providing these stable PR branches to netdev. In turn, to netdev it
makes no difference whether the branches are coming from linux-phy or a
third git tree. Whereas to linux-phy, things would even maybe a bit
simpler, due to already having the patches vs needing to pull them from
the 3rd tree.

From my perspective, if I'm perfectly honest, the idea was attractive
because of the phenomenal difference in turnaround times between netdev
and linux-phy review&merge processes (very fast in netdev, very slow and
patchy in linux-phy). If there's a set like this, where all API consumers
are in netdev for now but the API itself is in linux-phy, you'd have to
introduce 1000 NOP cycles just to wait for the PR branch.

In that sense, having more people into the mix would help just because
there's more people (i.e. fewer points of failure), even though overall
there's more overhead.

IDK, these are my 2 cents, I can resubmit this set in 2 weeks with the
maintainership of the PHY common properties exclusive to linux-phy.

Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Krzysztof Kozlowski]

On 04/12/2025 16:34, Vladimir Oltean wrote:
> On Mon, Dec 01, 2025 at 09:41:21AM +0100, Krzysztof Kozlowski wrote:
>> On 01/12/2025 09:37, Vinod Koul wrote:
>>> On 24-11-25, 20:01, Jakub Kicinski wrote:
>>>> On Sat, 22 Nov 2025 21:33:37 +0200 Vladimir Oltean wrote:
>>>>> Add helpers in the generic PHY folder which can be used using 'select
>>>>> GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
>>>>> enable GENERIC_PHY.
>>>>>
>>>>> These helpers need to deal with the slight messiness of the fact that
>>>>> the polarity properties are arrays per protocol, and with the fact that
>>>>> there is no default value mandated by the standard properties, all
>>>>> default values depend on driver and protocol (PHY_POL_NORMAL may be a
>>>>> good default for SGMII, whereas PHY_POL_AUTO may be a good default for
>>>>> PCIe).
>>>>>
>>>>> Push the supported mask of polarities to these helpers, to simplify
>>>>> drivers such that they don't need to validate what's in the device tree
>>>>> (or other firmware description).
>>>>>
>>>>> The proposed maintainership model is joint custody between netdev and
>>>>> linux-phy, because of the fact that these properties can be applied to
>>>>> Ethernet PCS blocks just as well as Generic PHY devices. I've added as
>>>>> maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
>>>>> "GENERIC PHY FRAMEWORK".
>>>>
>>>> I dunno.. ain't no such thing as "joint custody" maintainership.
>>>> We have to pick one tree. Given the set of Ms here, I suspect 
>>>> the best course of action may be to bubble this up to its own tree.
>>>> Ask Konstantin for a tree in k.org, then you can "co-post" the patches
>>>> for review + PR link in the cover letter (e.g. how Tony from Intel
>>>> submits their patches). This way not networking and PHY can pull
>>>> the shared changes with stable commit IDs.
>>>
>>> How much is the volume of the changes that we are talking about, we can
>>> always ack and pull into each other trees..?
>>
>> That's just one C file, isn't it? Having dedicated tree for one file
>> feels like huge overhead.
> 
> I have to admit, no matter how we define what pertains to this presumed
> new git tree, the fact is that the volume of patches will be quite low.
> 
> Since the API provider always sits in drivers/phy/ in every case that I
> can think about, technically all situations can be resolved by linux-phy
> providing these stable PR branches to netdev. In turn, to netdev it
> makes no difference whether the branches are coming from linux-phy or a
> third git tree. Whereas to linux-phy, things would even maybe a bit
> simpler, due to already having the patches vs needing to pull them from
> the 3rd tree.
> 
> From my perspective, if I'm perfectly honest, the idea was attractive
> because of the phenomenal difference in turnaround times between netdev
> and linux-phy review&merge processes (very fast in netdev, very slow and
> patchy in linux-phy). If there's a set like this, where all API consumers
> are in netdev for now but the API itself is in linux-phy, you'd have to
> introduce 1000 NOP cycles just to wait for the PR branch.
> 
> In that sense, having more people into the mix would help just because
> there's more people (i.e. fewer points of failure), even though overall
> there's more overhead.
> 
> IDK, these are my 2 cents, I can resubmit this set in 2 weeks with the
> maintainership of the PHY common properties exclusive to linux-phy.


Jakub supported the idea, so I also do not oppose, and if that helps you
folks, then go ahead.

Best regards,
Krzysztof

Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Jakub Kicinski]

On Mon, 1 Dec 2025 14:07:58 +0530 Vinod Koul wrote:
> > > Push the supported mask of polarities to these helpers, to simplify
> > > drivers such that they don't need to validate what's in the device tree
> > > (or other firmware description).
> > > 
> > > The proposed maintainership model is joint custody between netdev and
> > > linux-phy, because of the fact that these properties can be applied to
> > > Ethernet PCS blocks just as well as Generic PHY devices. I've added as
> > > maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
> > > "GENERIC PHY FRAMEWORK".  
> > 
> > I dunno.. ain't no such thing as "joint custody" maintainership.
> > We have to pick one tree. Given the set of Ms here, I suspect 
> > the best course of action may be to bubble this up to its own tree.
> > Ask Konstantin for a tree in k.org, then you can "co-post" the patches
> > for review + PR link in the cover letter (e.g. how Tony from Intel
> > submits their patches). This way not networking and PHY can pull
> > the shared changes with stable commit IDs.  
> 
> How much is the volume of the changes that we are talking about, we can
> always ack and pull into each other trees..?

We have such ad-hoc situations with multiple subsystems. Letting
Vladimir and co create their own tree is basically shifting the 
work of managing the stable branches from netdev maintainers
downstream. I'd strongly prefer that we lean on git in this way, 
rather than reenact the 3 spiderman meme multiple times in each
release.

[PATCH net-next 6/9] net: pcs: xpcs: promote SJA1105 TX polarity inversion to core

[Vladimir Oltean]

The SJA1105 'PMA' code is actually PCS code to adapt to a custom PMA as
present in NXP SJA1105, that wants opposite differential lane polarity
in the TX direction, to account for an internal quirk.

We should write to the DW_VR_MII_DIG_CTRL2 PCS register from PCS code,
especially since the XPCS is about to gain more freeform support to
alter the lane polarity in the RX and TX directions.

The compat->pma_config() interface is kept for SJA1110, but is now
wrapped around a xpcs_pma_config() that handles SJA1105 as a quirk
implemented in common code.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/pcs/pcs-xpcs-nxp.c | 11 ----------
 drivers/net/pcs/pcs-xpcs.c     | 37 ++++++++++++++++++++++++++--------
 drivers/net/pcs/pcs-xpcs.h     |  2 +-
 3 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/net/pcs/pcs-xpcs-nxp.c b/drivers/net/pcs/pcs-xpcs-nxp.c
index e8efe94cf4ec..37708b28a7aa 100644
--- a/drivers/net/pcs/pcs-xpcs-nxp.c
+++ b/drivers/net/pcs/pcs-xpcs-nxp.c
@@ -64,17 +64,6 @@
 /* RX_CDR_CTLE register */
 #define SJA1110_RX_CDR_CTLE		0x8042
 
-/* In NXP SJA1105, the PCS is integrated with a PMA that has the TX lane
- * polarity inverted by default (PLUS is MINUS, MINUS is PLUS). To obtain
- * normal non-inverted behavior, the TX lane polarity must be inverted in the
- * PCS, via the DIGITAL_CONTROL_2 register.
- */
-int nxp_sja1105_sgmii_pma_config(struct dw_xpcs *xpcs)
-{
-	return xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL2,
-			  DW_VR_MII_DIG_CTRL2_TX_POL_INV);
-}
-
 static int nxp_sja1110_pma_config(struct dw_xpcs *xpcs,
 				  u16 txpll_fbdiv, u16 txpll_refdiv,
 				  u16 rxpll_fbdiv, u16 rxpll_refdiv,
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 3d1bd5aac093..670441186cc6 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -808,6 +808,26 @@ static int xpcs_config_2500basex(struct dw_xpcs *xpcs)
 			   BMCR_SPEED1000);
 }
 
+static int xpcs_pma_config(struct dw_xpcs *xpcs, const struct dw_xpcs_compat *compat)
+{
+	int ret;
+
+	if (xpcs->need_opposite_tx_polarity) {
+		ret = xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL2,
+				 DW_VR_MII_DIG_CTRL2_TX_POL_INV);
+		if (ret)
+			return ret;
+	}
+
+	if (compat->pma_config) {
+		ret = compat->pma_config(xpcs);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 static int xpcs_do_config(struct dw_xpcs *xpcs, phy_interface_t interface,
 			  const unsigned long *advertising,
 			  unsigned int neg_mode)
@@ -859,13 +879,7 @@ static int xpcs_do_config(struct dw_xpcs *xpcs, phy_interface_t interface,
 		return -EINVAL;
 	}
 
-	if (compat->pma_config) {
-		ret = compat->pma_config(xpcs);
-		if (ret)
-			return ret;
-	}
-
-	return 0;
+	return xpcs_pma_config(xpcs, compat);
 }
 
 static int xpcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
@@ -1341,7 +1355,6 @@ static const struct dw_xpcs_compat nxp_sja1105_xpcs_compat[] = {
 		.interface = PHY_INTERFACE_MODE_SGMII,
 		.supported = xpcs_sgmii_features,
 		.an_mode = DW_AN_C37_SGMII,
-		.pma_config = nxp_sja1105_sgmii_pma_config,
 	}, {
 	}
 };
@@ -1500,6 +1513,14 @@ static struct dw_xpcs *xpcs_create(struct mdio_device *mdiodev)
 	else
 		xpcs->need_reset = true;
 
+	/* In NXP SJA1105, the PCS is integrated with a PMA that has the TX
+	 * lane polarity inverted by default (PLUS is MINUS, MINUS is PLUS).
+	 * To obtain normal non-inverted behavior, the TX lane polarity must be
+	 * inverted in the PCS, via the DIGITAL_CONTROL_2 register.
+	 */
+	if (xpcs->desc->compat == nxp_sja1105_xpcs_compat)
+		xpcs->need_opposite_tx_polarity = true;
+
 	return xpcs;
 
 out_clear_clks:
diff --git a/drivers/net/pcs/pcs-xpcs.h b/drivers/net/pcs/pcs-xpcs.h
index 929fa238445e..2a92e101da1b 100644
--- a/drivers/net/pcs/pcs-xpcs.h
+++ b/drivers/net/pcs/pcs-xpcs.h
@@ -113,6 +113,7 @@ struct dw_xpcs {
 	struct phylink_pcs pcs;
 	phy_interface_t interface;
 	bool need_reset;
+	bool need_opposite_tx_polarity;
 	u8 eee_mult_fact;
 };
 
@@ -121,7 +122,6 @@ int xpcs_write(struct dw_xpcs *xpcs, int dev, u32 reg, u16 val);
 int xpcs_modify(struct dw_xpcs *xpcs, int dev, u32 reg, u16 mask, u16 set);
 int xpcs_read_vpcs(struct dw_xpcs *xpcs, int reg);
 int xpcs_write_vpcs(struct dw_xpcs *xpcs, int reg, u16 val);
-int nxp_sja1105_sgmii_pma_config(struct dw_xpcs *xpcs);
 int nxp_sja1110_sgmii_pma_config(struct dw_xpcs *xpcs);
 int nxp_sja1110_2500basex_pma_config(struct dw_xpcs *xpcs);
 int txgbe_xpcs_switch_mode(struct dw_xpcs *xpcs, phy_interface_t interface);
-- 
2.34.1

[PATCH net-next 7/9] net: pcs: xpcs: allow lane polarity inversion

[Vladimir Oltean]

Using the linux/phy/phy-common-props.h helpers, get the 'rx-polarity'
and 'tx-polarity' device tree properties, and apply them to hardware in
the newly introduced xpcs_pma_config(), called from phylink_pcs_ops ::
pcs_config().

This is the right place to do it, as the generic PHY helpers require
knowing the phy_interface_t for which we want the polarity known, and
that comes from phylink.

Default to PHY_POL_NORMAL, and support normal and inverted polarities in
the RX and TX directions.

Note that for SJA1105, 'normal' in the TX direction is inverted in the
PCS, and 'inverted' is 'normal' in the PCS. This is because the device
tree property refers to the effect as visible at the device's pinout.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/pcs/Kconfig    |  1 +
 drivers/net/pcs/pcs-xpcs.c | 33 +++++++++++++++++++++++++++------
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/net/pcs/Kconfig b/drivers/net/pcs/Kconfig
index ecbc3530e780..3598747d6c53 100644
--- a/drivers/net/pcs/Kconfig
+++ b/drivers/net/pcs/Kconfig
@@ -8,6 +8,7 @@ menu "PCS device drivers"
 config PCS_XPCS
 	tristate "Synopsys DesignWare Ethernet XPCS"
 	select PHYLINK
+	select GENERIC_PHY_COMMON_PROPS
 	help
 	  This module provides a driver and helper functions for Synopsys
 	  DesignWare XPCS controllers.
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 670441186cc6..7625dc29d2ee 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -11,6 +11,7 @@
 #include <linux/pcs/pcs-xpcs.h>
 #include <linux/mdio.h>
 #include <linux/phy.h>
+#include <linux/phy/phy-common-props.h>
 #include <linux/phylink.h>
 #include <linux/property.h>
 
@@ -810,14 +811,34 @@ static int xpcs_config_2500basex(struct dw_xpcs *xpcs)
 
 static int xpcs_pma_config(struct dw_xpcs *xpcs, const struct dw_xpcs_compat *compat)
 {
+	struct fwnode_handle *fwnode = dev_fwnode(&xpcs->mdiodev->dev);
+	u32 val = 0, mask;
+	int pol;
 	int ret;
 
-	if (xpcs->need_opposite_tx_polarity) {
-		ret = xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL2,
-				 DW_VR_MII_DIG_CTRL2_TX_POL_INV);
-		if (ret)
-			return ret;
-	}
+	mask = DW_VR_MII_DIG_CTRL2_TX_POL_INV | DW_VR_MII_DIG_CTRL2_RX_POL_INV;
+
+	pol = phy_get_rx_polarity(fwnode, phy_modes(compat->interface),
+				  PHY_POL_NORMAL | PHY_POL_INVERT,
+				  PHY_POL_NORMAL);
+	if (pol < 0)
+		return pol;
+	if (pol == PHY_POL_INVERT)
+		val |= DW_VR_MII_DIG_CTRL2_RX_POL_INV;
+
+	pol = phy_get_tx_polarity(fwnode, phy_modes(compat->interface),
+				  PHY_POL_NORMAL | PHY_POL_INVERT,
+				  PHY_POL_NORMAL);
+	if (pol < 0)
+		return pol;
+	if (xpcs->need_opposite_tx_polarity)
+		pol = !pol;
+	if (pol == PHY_POL_INVERT)
+		val |= DW_VR_MII_DIG_CTRL2_TX_POL_INV;
+
+	ret = xpcs_modify(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL2, mask, val);
+	if (ret < 0)
+		return ret;
 
 	if (compat->pma_config) {
 		ret = compat->pma_config(xpcs);
-- 
2.34.1

Re: [PATCH net-next 7/9] net: pcs: xpcs: allow lane polarity inversion

[kernel test robot]

Hi Vladimir,

kernel test robot noticed the following build errors:

[auto build test ERROR on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Vladimir-Oltean/dt-bindings-phy-rename-transmit-amplitude-yaml-to-phy-common-props-yaml/20251123-033900
base:   net-next/main
patch link:    https://lore.kernel.org/r/20251122193341.332324-8-vladimir.oltean%40nxp.com
patch subject: [PATCH net-next 7/9] net: pcs: xpcs: allow lane polarity inversion
config: arm-spear6xx_defconfig (https://download.01.org/0day-ci/archive/20251126/202511262216.TzyLet3B-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9e9fe08b16ea2c4d9867fb4974edf2a3776d6ece)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251126/202511262216.TzyLet3B-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511262216.TzyLet3B-lkp@intel.com/

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: phy_get_rx_polarity
   >>> referenced by pcs-xpcs.c:821 (drivers/net/pcs/pcs-xpcs.c:821)
   >>>               drivers/net/pcs/pcs-xpcs.o:(xpcs_do_config) in archive vmlinux.a
--
>> ld.lld: error: undefined symbol: phy_get_tx_polarity
   >>> referenced by pcs-xpcs.c:829 (drivers/net/pcs/pcs-xpcs.c:829)
   >>>               drivers/net/pcs/pcs-xpcs.o:(xpcs_do_config) in archive vmlinux.a

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH net-next 8/9] net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and "airoha,pnswap-tx"

[Vladimir Oltean]

Prefer the new "rx-polarity" and "tx-polarity" properties, and use the
vendor specific ones as fallback if the standard description doesn't
exist.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/phy/Kconfig       |  1 +
 drivers/net/phy/air_en8811h.c | 50 ++++++++++++++++++++++++-----------
 2 files changed, 36 insertions(+), 15 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index a7ade7b95a2e..7b73332a13d9 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -98,6 +98,7 @@ config AS21XXX_PHY
 
 config AIR_EN8811H_PHY
 	tristate "Airoha EN8811H 2.5 Gigabit PHY"
+	select PHY_COMMON_PROPS
 	help
 	  Currently supports the Airoha EN8811H PHY.
 
diff --git a/drivers/net/phy/air_en8811h.c b/drivers/net/phy/air_en8811h.c
index badd65f0ccee..4171fecb1def 100644
--- a/drivers/net/phy/air_en8811h.c
+++ b/drivers/net/phy/air_en8811h.c
@@ -14,6 +14,7 @@
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/phy.h>
+#include <linux/phy/phy-common-props.h>
 #include <linux/firmware.h>
 #include <linux/property.h>
 #include <linux/wordpart.h>
@@ -966,11 +967,42 @@ static int en8811h_probe(struct phy_device *phydev)
 	return 0;
 }
 
+static int en8811h_config_serdes_polarity(struct phy_device *phydev)
+{
+	struct device *dev = &phydev->mdio.dev;
+	int pol, default_pol;
+	u32 pbus_value = 0;
+
+	default_pol = PHY_POL_NORMAL;
+	if (device_property_read_bool(dev, "airoha,pnswap-rx"))
+		default_pol = PHY_POL_INVERT;
+
+	pol = phy_get_rx_polarity(dev_fwnode(dev), phy_modes(phydev->interface),
+				  PHY_POL_NORMAL | PHY_POL_INVERT, default_pol);
+	if (pol < 0)
+		return pol;
+	if (pol == PHY_POL_INVERT)
+		pbus_value |= EN8811H_POLARITY_RX_REVERSE;
+
+	default_pol = PHY_POL_NORMAL;
+	if (device_property_read_bool(dev, "airoha,pnswap-tx"))
+		default_pol = PHY_POL_INVERT;
+
+	pol = phy_get_tx_polarity(dev_fwnode(dev), phy_modes(phydev->interface),
+				  PHY_POL_NORMAL | PHY_POL_INVERT, default_pol);
+	if (pol < 0)
+		return pol;
+	if (pol == PHY_POL_NORMAL)
+		pbus_value |= EN8811H_POLARITY_TX_NORMAL;
+
+	return air_buckpbus_reg_modify(phydev, EN8811H_POLARITY,
+				       EN8811H_POLARITY_RX_REVERSE |
+				       EN8811H_POLARITY_TX_NORMAL, pbus_value);
+}
+
 static int en8811h_config_init(struct phy_device *phydev)
 {
 	struct en8811h_priv *priv = phydev->priv;
-	struct device *dev = &phydev->mdio.dev;
-	u32 pbus_value;
 	int ret;
 
 	/* If restart happened in .probe(), no need to restart now */
@@ -1003,19 +1035,7 @@ static int en8811h_config_init(struct phy_device *phydev)
 	if (ret < 0)
 		return ret;
 
-	/* Serdes polarity */
-	pbus_value = 0;
-	if (device_property_read_bool(dev, "airoha,pnswap-rx"))
-		pbus_value |=  EN8811H_POLARITY_RX_REVERSE;
-	else
-		pbus_value &= ~EN8811H_POLARITY_RX_REVERSE;
-	if (device_property_read_bool(dev, "airoha,pnswap-tx"))
-		pbus_value &= ~EN8811H_POLARITY_TX_NORMAL;
-	else
-		pbus_value |=  EN8811H_POLARITY_TX_NORMAL;
-	ret = air_buckpbus_reg_modify(phydev, EN8811H_POLARITY,
-				      EN8811H_POLARITY_RX_REVERSE |
-				      EN8811H_POLARITY_TX_NORMAL, pbus_value);
+	ret = en8811h_config_serdes_polarity(phydev);
 	if (ret < 0)
 		return ret;
 
-- 
2.34.1

[PATCH net-next 9/9] dt-bindings: net: airoha,en8811h: deprecate "airoha,pnswap-rx" and "airoha,pnswap-tx"

[Vladimir Oltean]

Reference the common PHY properties, and update the example to use them.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 .../devicetree/bindings/net/airoha,en8811h.yaml       | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/airoha,en8811h.yaml b/Documentation/devicetree/bindings/net/airoha,en8811h.yaml
index ecb5149ec6b0..0de6e9284fbc 100644
--- a/Documentation/devicetree/bindings/net/airoha,en8811h.yaml
+++ b/Documentation/devicetree/bindings/net/airoha,en8811h.yaml
@@ -16,6 +16,7 @@ description:
 
 allOf:
   - $ref: ethernet-phy.yaml#
+  - $ref: /schemas/phy/phy-common-props.yaml#
 
 properties:
   compatible:
@@ -30,12 +31,18 @@ properties:
     description:
       Reverse rx polarity of the SERDES. This is the receiving
       side of the lines from the MAC towards the EN881H.
+      This property is deprecated, for details please refer to
+      Documentation/devicetree/bindings/phy/phy-common-props.yaml
+    deprecated: true
 
   airoha,pnswap-tx:
     type: boolean
     description:
       Reverse tx polarity of SERDES. This is the transmitting
       side of the lines from EN8811H towards the MAC.
+      This property is deprecated, for details please refer to
+      Documentation/devicetree/bindings/phy/phy-common-props.yaml
+    deprecated: true
 
 required:
   - reg
@@ -44,6 +51,8 @@ unevaluatedProperties: false
 
 examples:
   - |
+    #include <dt-bindings/phy/phy.h>
+
     mdio {
         #address-cells = <1>;
         #size-cells = <0>;
@@ -51,6 +60,6 @@ examples:
         ethernet-phy@1 {
             compatible = "ethernet-phy-id03a2.a411";
             reg = <1>;
-            airoha,pnswap-rx;
+            rx-polarity = <PHY_POL_INVERT>;
         };
     };
-- 
2.34.1

Re: [PATCH net-next 9/9] dt-bindings: net: airoha,en8811h: deprecate "airoha,pnswap-rx" and "airoha,pnswap-tx"

[Rob Herring (Arm)]

On Sat, 22 Nov 2025 21:33:41 +0200, Vladimir Oltean wrote:
> Reference the common PHY properties, and update the example to use them.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  .../devicetree/bindings/net/airoha,en8811h.yaml       | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH net-next 0/9] XPCS polarity inversion via generic device tree properties

[Daniel Golle]

On Sat, Nov 22, 2025 at 09:33:32PM +0200, Vladimir Oltean wrote:
> Polarity inversion (described in patch 3/6) is a feature with at least 3
> potential new users waiting for a generic description:
> - Horatiu Vultur with the lan966x SerDes
> - Daniel Golle with the MaxLinear GSW1xx switches
> - Me with a custom SJA1105 board, switch which uses the DesignWare XPCS
> 
> I became interested in exploring the problem space because I was averse
> to the idea of adding vendor-specific device tree properties to describe
> a common need.

Thank you for coming up with a good solution, and even generalizing
this beyond networking scope :)

> 
> This set contains an implementation of a generic feature that should
> cater to all known needs that were identified during my documentation
> phase. I've added a new user - the XPCS - and I've converted an existing
> user - the EN8811H Ethernet PHY.
> 
> I haven't converted the rest due to various reasons:
> - "mediatek,pnswap" is defined bidirectionally and the underlying
>   SGMII_PN_SWAP_TX_RX register field doesn't make it clear which bit is
>   RX and which is TX. Needs more work and expert knowledge from maintainer.

Just to quickly answer to that one from MediaTek's SDK[1]:
#define SGMII_PN_SWAP_RX               BIT(1)
#define SGMII_PN_SWAP_TX               BIT(0)

So MediaTek LynxI is ready to be supported via the standard properties
you are suggesting.

[1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/5cecec123e1ab4c7f4eabd5630e8e8b2e89b9cf0/autobuild/unified/filogic/master/files/target/linux/mediatek/patches-6.6/999-2607-net-pcs-mtk-lynxi-add-individual-polarity-control.patch


> - "st,px_rx_pol_inv" - its binding is a .txt file and I don't have time
>   for such a large detour to convert it to dtschema.
> - "st,pcie-tx-pol-inv" and "st,sata-tx-pol-inv" - these are defined in a
>   .txt schema but are not implemented in any driver. My verdict would be
>   "delete the properties" but again, I would prefer not introducing such
>   dependency to this series.
> 
> Vladimir Oltean (9):
>   dt-bindings: phy: rename transmit-amplitude.yaml to
>     phy-common-props.yaml
>   dt-bindings: phy-common-props: create a reusable "protocol-names"
>     definition
>   dt-bindings: phy-common-props: RX and TX lane polarity inversion
>   dt-bindings: net: xpcs: allow properties from phy-common-props.yaml
>   phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
>   net: pcs: xpcs: promote SJA1105 TX polarity inversion to core
>   net: pcs: xpcs: allow lane polarity inversion
>   net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and
>     "airoha,pnswap-tx"
>   dt-bindings: net: airoha,en8811h: deprecate "airoha,pnswap-rx" and
>     "airoha,pnswap-tx"
> 
>  .../bindings/net/airoha,en8811h.yaml          |  11 +-
>  .../bindings/net/pcs/snps,dw-xpcs.yaml        |   5 +-
>  .../bindings/phy/phy-common-props.yaml        | 152 ++++++++++++++++++
>  .../bindings/phy/transmit-amplitude.yaml      | 103 ------------
>  MAINTAINERS                                   |  21 +++
>  drivers/net/pcs/Kconfig                       |   1 +
>  drivers/net/pcs/pcs-xpcs-nxp.c                |  11 --
>  drivers/net/pcs/pcs-xpcs.c                    |  58 ++++++-
>  drivers/net/pcs/pcs-xpcs.h                    |   2 +-
>  drivers/net/phy/Kconfig                       |   1 +
>  drivers/net/phy/air_en8811h.c                 |  50 ++++--
>  drivers/phy/Kconfig                           |   9 ++
>  drivers/phy/Makefile                          |   1 +
>  drivers/phy/phy-common-props.c                | 117 ++++++++++++++
>  include/dt-bindings/phy/phy.h                 |   4 +
>  include/linux/phy/phy-common-props.h          |  20 +++
>  16 files changed, 426 insertions(+), 140 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-common-props.yaml
>  delete mode 100644 Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
>  create mode 100644 drivers/phy/phy-common-props.c
>  create mode 100644 include/linux/phy/phy-common-props.h
> 
> -- 
> 2.34.1
>