[PATCH v4 phy 00/16] Lynx 28G improvements part 1

[PATCH v4 phy 00/16] Lynx 28G improvements part 1

[Vladimir Oltean]

This is the first part in upstreaming a set of around 100 patches that
were developed in NXP's vendor Linux Factory kernel over the course of
several years.

This part is mainly concerned with correcting some historical mistakes
which make extending the driver more difficult:
- The 3 instances of this SerDes block, as seen on NXP LX2160A, need to
  be differentiated somehow, because otherwise, the driver cannot reject
  a configuration which is unsupported by the hardware. The proposal is
  to do that based on compatible string.
- Lanes cannot have electrical parameters described in the device tree,
  because they are not described in the device tree.
- The register naming scheme forces us to modify a single register field
  per lynx_28g_lane_rmw() call - leads to inefficient code
- lynx_28g_lane_set_sgmii(), lynx_28g_lane_set_10gbaser() are unfit for
  their required roles when the current SerDes protocol is 25GBase-R.
  They are replaced with a better structured approach.
- USXGMII and 10GBase-R have different protocol converters, and should
  be treated separately by the SerDes driver.

The device tree binding + driver changes are all non-breaking.
I also have device tree conversions for LX2160A and LX2162A which are
also non-breaking due to their partial nature.

If I were to replace patterns such as:
	phys = <&serdes_2 0>;
with:
	phys = <&serdes_2_lane_a>;

then the corresponding device tree conversions would also be breaking.
I don't _need_ to do that to make progress, but eventually I would like
to be able to.

In order to be able to make that kind of change in a non-breaking
manner in a reasonable number of years, I would like patches 1-3 to be
backported to stable kernels.

Compared to v3 here:
https://lore.kernel.org/linux-phy/20250926180505.760089-1-vladimir.oltean@nxp.com/
there are some new patches, but it overall shrank in size because I
deferred new features to "part 2". Essentially, v4 is like v3, except
with a better plan to handle device tree transitions without breakage,
and with the following patches temporarily dropped:
[PATCH v3 phy 14/17] phy: lynx-28g: add support for 25GBASER
[PATCH v3 phy 15/17] phy: lynx-28g: use timeouts when waiting for
 lane halt and reset
[PATCH v3 phy 16/17] phy: lynx-28g: truly power the lanes up or down
[PATCH v3 phy 17/17] phy: lynx-28g: implement phy_exit() operation

Compared to v2 here:
https://lore.kernel.org/lkml/d0c8bbf8-a0c5-469f-a148-de2235948c0f@solid-run.com/
v3 grew in size due to Josua's request to avoid unbounded loops waiting
for lane resets/halts/stops to complete.

Compared to v1 here:
https://lore.kernel.org/lkml/20250904154402.300032-1-vladimir.oltean@nxp.com/
v2 grew in size due to Josua's request for a device tree binding where
individual lanes have their own OF nodes. This seems to be the right
moment to make that change.

Detailed change log in individual patches. Thanks to Josua, Rob, Conor,
Krzysztof, Ioana who provided feedback on the previous version, and I
hope it has all been addressed.

Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: stable@vger.kernel.org

Ioana Ciornei (1):
  phy: lynx-28g: configure more equalization params for 1GbE and 10GbE

Vladimir Oltean (15):
  dt-bindings: phy: lynx-28g: permit lane OF PHY providers
  phy: lynx-28g: refactor lane probing to lynx_28g_probe_lane()
  phy: lynx-28g: support individual lanes as OF PHY providers
  phy: lynx-28g: remove LYNX_28G_ prefix from register names
  phy: lynx-28g: don't concatenate lynx_28g_lane_rmw() argument "reg"
    with "val" and "mask"
  phy: lynx-28g: use FIELD_GET() and FIELD_PREP()
  phy: lynx-28g: convert iowrite32() calls with magic values to macros
  phy: lynx-28g: restructure protocol configuration register accesses
  phy: lynx-28g: make lynx_28g_set_lane_mode() more systematic
  phy: lynx-28g: refactor lane->interface to lane->mode
  phy: lynx-28g: distinguish between 10GBASE-R and USXGMII
  phy: lynx-28g: use "dev" argument more in lynx_28g_probe()
  phy: lynx-28g: improve lynx_28g_probe() sequence
  dt-bindings: phy: lynx-28g: add compatible strings per SerDes and
    instantiation
  phy: lynx-28g: probe on per-SoC and per-instance compatible strings

 .../devicetree/bindings/phy/fsl,lynx-28g.yaml |  153 +-
 drivers/phy/freescale/phy-fsl-lynx-28g.c      | 1271 +++++++++++++----
 2 files changed, 1134 insertions(+), 290 deletions(-)

-- 
2.34.1

[PATCH v4 phy 01/16] dt-bindings: phy: lynx-28g: permit lane OF PHY providers

[Vladimir Oltean]

Josua Mayer requested to have OF nodes for each lane, so that he
(and other board developers) can further describe electrical parameters
individually.

For this use case, we need a container node to apply the already
existing Documentation/devicetree/bindings/phy/transmit-amplitude.yaml,
plus whatever other schemas might get standardized for TX equalization
parameters, polarity inversion etc.

When lane OF nodes exist, these are also PHY providers ("phys" phandles
can point directly to them). Compare that to the existing binding, where
the PHY provider is the top-level SerDes node, and the second cell in
the "phys" phandle specifies the lane index.

The new binding format overlaps over the old one without interfering,
but there is a caveat:

Existing device trees, which already have "phys = <&serdes1 0>" cannot
be converted to "phys = <&serdes_1_lane_a>", because in doing so, we
would break compatibility with old kernels which don't understand how to
translate the latter phandle to a PHY.

The transition to the new phandle format can be performed only after a
reasonable amount of time has elapsed after this schema change and the
corresponding driver change have been backported to stable kernels.

However, the aforementioned transition is not strictly necessary, and
the "hybrid" description (where individual lanes have their own OF node,
but are not pointed to by the "phys" phandle) can remain for an
indefinite amount of time, even if a little inelegant.

For newly introduced device trees, where there are no compatibility
concerns with old kernels to speak of, it is strongly recommended to use
the "phys = <&serdes_1_lane_a>" format. The same holds for phandles
towards lanes of LX2160A SerDes #3, which at the time of writing is not
yet described in fsl-lx2160a.dtsi, so there is no legacy to maintain.

To avoid the strange situation where we have a "phy" (SerDes node) ->
"phy" (lane node) hierarchy, let's rename the expected name of the
top-level node to "serdes", and update the example too. This has a
theoretical chance of causing regressions if bootloaders search for
hardcoded paths rather than using aliases, but to the best of my
knowledge, for LX2160A/LX2162A this is not the case.

Link: https://lore.kernel.org/lkml/02270f62-9334-400c-b7b9-7e6a44dbbfc9@solid-run.com/
Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v3-v4: patch is new (broken out from previous "[PATCH v3 phy 12/17]
       dt-bindings: phy: lynx-28g: add compatible strings per SerDes
       and instantiation") to deal just with the lane OF nodes, in a
       backportable way

 .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 71 ++++++++++++++++++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
index ff9f9ca0f19c..e96229c2f8fb 100644
--- a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
@@ -20,6 +20,32 @@ properties:
   "#phy-cells":
     const: 1
 
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^phy@[0-7]$":
+    type: object
+    description: SerDes lane (single RX/TX differential pair)
+
+    properties:
+      reg:
+        minimum: 0
+        maximum: 7
+        description: Lane index as seen in register map
+
+      "#phy-cells":
+        const: 0
+
+    required:
+      - reg
+      - "#phy-cells"
+
+    additionalProperties: false
+
 required:
   - compatible
   - reg
@@ -32,9 +58,52 @@ examples:
     soc {
       #address-cells = <2>;
       #size-cells = <2>;
-      serdes_1: phy@1ea0000 {
+
+      serdes@1ea0000 {
         compatible = "fsl,lynx-28g";
         reg = <0x0 0x1ea0000 0x0 0x1e30>;
+        #address-cells = <1>;
+        #size-cells = <0>;
         #phy-cells = <1>;
+
+        phy@0 {
+          reg = <0>;
+          #phy-cells = <0>;
+        };
+
+        phy@1 {
+          reg = <1>;
+          #phy-cells = <0>;
+        };
+
+        phy@2 {
+          reg = <2>;
+          #phy-cells = <0>;
+        };
+
+        phy@3 {
+          reg = <3>;
+          #phy-cells = <0>;
+        };
+
+        phy@4 {
+          reg = <4>;
+          #phy-cells = <0>;
+        };
+
+        phy@5 {
+          reg = <5>;
+          #phy-cells = <0>;
+        };
+
+        phy@6 {
+          reg = <6>;
+          #phy-cells = <0>;
+        };
+
+        phy@7 {
+          reg = <7>;
+          #phy-cells = <0>;
+        };
       };
     };
-- 
2.34.1

[PATCH v4 phy 02/16] phy: lynx-28g: refactor lane probing to lynx_28g_probe_lane()

[Vladimir Oltean]

This simplifies the main control flow a little bit and makes the logic
reusable for probing the lanes with OF nodes if those exist.

Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v3->v4:
- patch is new, broken out from previous "[PATCH v3 phy 13/17] phy:
  lynx-28g: probe on per-SoC and per-instance compatible strings" to
  deal only with lane OF nodes, in a backportable way

 drivers/phy/freescale/phy-fsl-lynx-28g.c | 42 +++++++++++++++---------
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
index c20d2636c5e9..901240bbcade 100644
--- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
+++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
@@ -579,12 +579,33 @@ static struct phy *lynx_28g_xlate(struct device *dev,
 	return priv->lane[idx].phy;
 }
 
+static int lynx_28g_probe_lane(struct lynx_28g_priv *priv, int id,
+			       struct device_node *dn)
+{
+	struct lynx_28g_lane *lane = &priv->lane[id];
+	struct phy *phy;
+
+	memset(lane, 0, sizeof(*lane));
+
+	phy = devm_phy_create(priv->dev, dn, &lynx_28g_ops);
+	if (IS_ERR(phy))
+		return PTR_ERR(phy);
+
+	lane->priv = priv;
+	lane->phy = phy;
+	lane->id = id;
+	phy_set_drvdata(phy, lane);
+	lynx_28g_lane_read_configuration(lane);
+
+	return 0;
+}
+
 static int lynx_28g_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct phy_provider *provider;
 	struct lynx_28g_priv *priv;
-	int i;
+	int err;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -597,21 +618,10 @@ static int lynx_28g_probe(struct platform_device *pdev)
 
 	lynx_28g_pll_read_configuration(priv);
 
-	for (i = 0; i < LYNX_28G_NUM_LANE; i++) {
-		struct lynx_28g_lane *lane = &priv->lane[i];
-		struct phy *phy;
-
-		memset(lane, 0, sizeof(*lane));
-
-		phy = devm_phy_create(&pdev->dev, NULL, &lynx_28g_ops);
-		if (IS_ERR(phy))
-			return PTR_ERR(phy);
-
-		lane->priv = priv;
-		lane->phy = phy;
-		lane->id = i;
-		phy_set_drvdata(phy, lane);
-		lynx_28g_lane_read_configuration(lane);
+	for (int i = 0; i < LYNX_28G_NUM_LANE; i++) {
+		err = lynx_28g_probe_lane(priv, i, NULL);
+		if (err)
+			return err;
 	}
 
 	dev_set_drvdata(dev, priv);
-- 
2.34.1

[PATCH v4 phy 03/16] phy: lynx-28g: support individual lanes as OF PHY providers

[Vladimir Oltean]

Currently, the bindings of this multi-lane SerDes are such that
consumers specify the lane index in the PHY cell, and the lane itself is
not described in the device tree.

It is desirable to describe individual Lynx 28G SerDes lanes in the
device tree, in order to be able to customize electrical properties such
as those in Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
(or others).

If each lane may have an OF node, it appears natural for consumers to
have their "phys" phandle point to that OF node.

The problem is that transitioning between one format and another is a
breaking change. The bindings of the 28G Lynx SerDes can themselves be
extended in a backward-compatible way, but the consumers cannot be
modified without breaking them.

Namely, if we have:

&mac {
	phys = <&serdes1 0>;
};

we cannot update the device tree to:

&mac {
	phys = <&serdes1_lane_0>;
};

because old kernels cannot resolve this phandle to a valid PHY.

The proposal here is to keep tolerating existing device trees, which are
not supposed to be changed, but modify lynx_28g_xlate() to also resolve
the new format with #phy-cells = <0> in the lanes.

This way we support 3 modes:
- Legacy device trees, no OF nodes for lanes
- New device trees, OF nodes for lanes and "phys" phandle points towards
  them
- Hybrid device trees, OF nodes for lanes (to describe electrical
  parameters), but "phys" phandle points towards the SerDes top-level
  provider

Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v3->v4:
- patch is new, broken out from previous "[PATCH v3 phy 13/17] phy:
  lynx-28g: probe on per-SoC and per-instance compatible strings" to
  deal only with lane OF nodes, in a backportable way
- contains a new idea to support phandles either to the SerDes or to
  lane nodes, via a single xlate function that redirects to
  of_phy_simple_xlate() if the phandle is to the lane, or is implemented
  as before if the phandle is to the SerDes.
- Compared to v3 where we decided based on the compatible string whether
  to use lynx_28g_xlate() which expects the SerDes as PHY provider, or
  of_phy_simple_xlate() which expects the lanes as PHY provider, here we
  completely decouple those two concepts and patch lynx_28g_xlate() to
  support both cases.

 drivers/phy/freescale/phy-fsl-lynx-28g.c | 49 +++++++++++++++++++++---
 1 file changed, 44 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
index 901240bbcade..61a992ff274f 100644
--- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
+++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
@@ -571,7 +571,14 @@ static struct phy *lynx_28g_xlate(struct device *dev,
 				  const struct of_phandle_args *args)
 {
 	struct lynx_28g_priv *priv = dev_get_drvdata(dev);
-	int idx = args->args[0];
+	int idx;
+
+	if (args->args_count == 0)
+		return of_phy_simple_xlate(dev, args);
+	else if (args->args_count != 1)
+		return ERR_PTR(-ENODEV);
+
+	idx = args->args[0];
 
 	if (WARN_ON(idx >= LYNX_28G_NUM_LANE))
 		return ERR_PTR(-EINVAL);
@@ -605,6 +612,7 @@ static int lynx_28g_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct phy_provider *provider;
 	struct lynx_28g_priv *priv;
+	struct device_node *dn;
 	int err;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
@@ -618,10 +626,41 @@ static int lynx_28g_probe(struct platform_device *pdev)
 
 	lynx_28g_pll_read_configuration(priv);
 
-	for (int i = 0; i < LYNX_28G_NUM_LANE; i++) {
-		err = lynx_28g_probe_lane(priv, i, NULL);
-		if (err)
-			return err;
+	dn = dev_of_node(dev);
+	if (of_get_child_count(dn)) {
+		struct device_node *child;
+
+		for_each_available_child_of_node(dn, child) {
+			u32 reg;
+
+			/* PHY subnode name must be 'phy'. */
+			if (!(of_node_name_eq(child, "phy")))
+				continue;
+
+			if (of_property_read_u32(child, "reg", &reg)) {
+				dev_err(dev, "No \"reg\" property for %pOF\n", child);
+				of_node_put(child);
+				return -EINVAL;
+			}
+
+			if (reg >= LYNX_28G_NUM_LANE) {
+				dev_err(dev, "\"reg\" property out of range for %pOF\n", child);
+				of_node_put(child);
+				return -EINVAL;
+			}
+
+			err = lynx_28g_probe_lane(priv, reg, child);
+			if (err) {
+				of_node_put(child);
+				return err;
+			}
+		}
+	} else {
+		for (int i = 0; i < LYNX_28G_NUM_LANE; i++) {
+			err = lynx_28g_probe_lane(priv, i, NULL);
+			if (err)
+				return err;
+		}
 	}
 
 	dev_set_drvdata(dev, priv);
-- 
2.34.1

[PATCH v4 phy 15/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation

[Vladimir Oltean]

The 28G Lynx SerDes is instantiated 3 times in the NXP LX2160A SoC and
twice in the NXP LX2162A. All these instances share the same register
map, but the number of lanes and the protocols supported by each lane
differs in a way that isn't detectable by the programming model.

Going by the generic "fsl,lynx-28g" compatible string and expecting all
SerDes instantiations to use it was a mistake that needs to be fixed.

The two major options considered are
(a) encode the SoC and the SerDes instance in the compatible string,
    everything else is the responsibility of the driver to derive based
    on this sufficient information
(b) add sufficient device tree properties to describe the per-lane
    differences, as well as the different lane count

Another important consideration is that any decision made here should
be consistent with the decisions taken for the yet-to-be-introduced
10G Lynx SerDes (older generation for older SoCs), because of how
similar they are.

I've seen option (b) at play in this unmerged patch set for the 10G Lynx
here, and I didn't like it:
https://lore.kernel.org/linux-phy/20230413160607.4128315-3-sean.anderson@seco.com/

This is because there, we have a higher degree of variability in the
PCCR register values that need to be written per protocol. This makes
that approach more drawn-out and more prone to errors, compared to (a)
which is more succinct and obviously correct.

So I've chosen option (a) through elimination, and this also reflects
how the SoC reference manual provides different tables with protocol
combinations for each SerDes. NXP clearly documents these as not
identical, and refers to them as such (SerDes 1, 2, etc).

The per-SoC compatible string is prepended to the "fsl,lynx-28g" generic
compatible, which is left there for compatibility with old kernels. An
exception would be LX2160A SerDes #3, which at the time of writing is
not described in fsl-lx2160a.dtsi, and is a non-networking SerDes, so
the existing Linux driver is useless for it. So there is no practical
reason to put the "fsl,lynx-28g" fallback for "fsl,lx2160a-serdes3".

The specific compatible strings give us the opportunity to express more
constraints in the schema that we weren't able to express before:
- We allow #phy-cells in the top-level SerDes node only for
  compatibility with old kernels that don't know how to translate
  "phys = <&serdes_1_lane_a>" to a PHY. We don't need that feature for
  the not-yet-introduced LX2160A SerDes #3, so make the presence of
  #phy-cells at the top level be dependent on the presence of the
  "fsl,lynx-28g" fallback compatible.
- The modernization of the compatible string should come together with
  per-lane OF nodes.
- LX2162A SerDes 1 has fewer lanes than the others, and trying to use
  lanes 0-3 would be a mistake that could be caught by the schema.

Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v3->v4:
- OF nodes per lane broken out as a separate "[PATCH v4 phy 01/16]
  dt-bindings: phy: lynx-28g: permit lane OF PHY providers"
- rewritten commit message
- s|"^phy@[0-9a-f]+$"|"^phy@[0-7]$"|g in patternProperties
- define "#address-cells" and "#size-cells" as part of common
  properties, only leave the part which marks them required in the allOf
  constraints area
v2->v3:
- re-add "fsl,lynx-28g" as fallback compatible, and #phy-cells = <1> in
  top-level "serdes" node
- drop useless description texts
- fix text formatting
- schema is more lax to allow overlaying old and new required properties
v1->v2:
- drop the usage of "fsl,lynx-28g" as a fallback compatible
- mark "fsl,lynx-28g" as deprecated
- implement Josua's request for per-lane OF nodes for the new compatible
  strings

 .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 86 +++++++++++++++++--
 1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
index e96229c2f8fb..114dbb32fe7f 100644
--- a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
@@ -9,17 +9,41 @@ title: Freescale Lynx 28G SerDes PHY
 maintainers:
   - Ioana Ciornei <ioana.ciornei@nxp.com>
 
+description:
+  The Lynx 28G is a multi-lane, multi-protocol SerDes (PCIe, SATA, Ethernet)
+  present in multiple instances on NXP LX2160A and LX2162A SoCs. All instances
+  share a common register map and programming model, however they differ in
+  supported protocols per lane in a way that is not detectable by said
+  programming model without prior knowledge. The distinction is made through
+  the compatible string.
+
 properties:
   compatible:
-    enum:
-      - fsl,lynx-28g
+    oneOf:
+      - const: fsl,lynx-28g
+        deprecated: true
+        description:
+          Legacy compatibility string for Lynx 28G SerDes. Any assumption
+          regarding whether a certain lane supports a certain protocol may
+          be incorrect. Deprecated except when used as a fallback. Use
+          device-specific strings instead.
+      - items:
+          - const: fsl,lx2160a-serdes1
+          - const: fsl,lynx-28g
+      - items:
+          - const: fsl,lx2160a-serdes2
+          - const: fsl,lynx-28g
+      - items:
+          - const: fsl,lx2162a-serdes1
+          - const: fsl,lynx-28g
+      - items:
+          - const: fsl,lx2162a-serdes2
+          - const: fsl,lynx-28g
+      - const: fsl,lx2160a-serdes3
 
   reg:
     maxItems: 1
 
-  "#phy-cells":
-    const: 1
-
   "#address-cells":
     const: 1
 
@@ -49,7 +73,55 @@ patternProperties:
 required:
   - compatible
   - reg
-  - "#phy-cells"
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: fsl,lynx-28g
+    then:
+      # Legacy case: parent is the PHY provider, cell encodes lane index
+      properties:
+        "#phy-cells":
+          const: 1
+      required:
+        - "#phy-cells"
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,lx2160a-serdes1
+              - fsl,lx2160a-serdes2
+              - fsl,lx2160a-serdes3
+              - fsl,lx2162a-serdes1
+              - fsl,lx2162a-serdes2
+    then:
+      # Modern binding: lanes must have their own nodes
+      required:
+        - "#address-cells"
+        - "#size-cells"
+
+  # LX2162A SerDes 1 has fewer lanes than the others
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: fsl,lx2162a-serdes1
+    then:
+      patternProperties:
+        "^phy@[0-7]$":
+          properties:
+            reg:
+              enum: [4, 5, 6, 7]
+    else:
+      patternProperties:
+        "^phy@[0-7]$":
+          properties:
+            reg:
+              enum: [0, 1, 2, 3, 4, 5, 6, 7]
 
 additionalProperties: false
 
@@ -60,7 +132,7 @@ examples:
       #size-cells = <2>;
 
       serdes@1ea0000 {
-        compatible = "fsl,lynx-28g";
+        compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g";
         reg = <0x0 0x1ea0000 0x0 0x1e30>;
         #address-cells = <1>;
         #size-cells = <0>;
-- 
2.34.1

[PATCH v4 phy 16/16] phy: lynx-28g: probe on per-SoC and per-instance compatible strings

[Vladimir Oltean]

Add driver support for probing on the new, per-instance and per-SoC
bindings, which provide the following benefits:
- they allow rejecting unsupported protocols per lane (10GbE on SerDes 2
  lanes 0-5)
- individual lanes have their own OF nodes as PHY providers, which
  allows board device tree authors to tune electrical parameters such as
  TX amplitude, equalization etc.

Probing on "fsl,lynx-28g" is still supported, but the feature set is
frozen in time to just 1GbE and 10GbE (essentially the feature set as of
this change). However, we encourage the user at probe time to update the
device tree.

Refactor the per-lane logic from lynx_28g_probe() into
lynx_28g_lane_probe(), and call it from two distinct paths depending on
whether the modern or the legacy compatible string is used, with an OF
node for the lane or without.

Notable implication of the above: when lanes have disabled OF nodes, we
skip creating PHYs for them, and must also skip the CDR lock workaround.

lynx_28g_supports_lane_mode() was a SerDes-global function and now
becomes per lane, to reflect the specific capabilities each instance may
have.

Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v3->v4:
- the introduction of "bool lane_phy_providers" from lynx_28g_probe()
  disappeared, and the whole "is the SerDes a PHY provider, or the
  individual lanes?" question is now handled by "[PATCH v4 phy 03/16]
  phy: lynx-28g: support individual lanes as OF PHY providers"
v2->v3:
- reword commit message
- add some comments regarding the "fsl,lynx-28g" fallback mechanism
- skip CDR lock workaround for lanes with no PHY (disabled in the device
  tree in the new binding)
v1->v2:
- remove priv->info->get_pccr() and priv->info->get_pcvt_offset().
  These were always called directly as lynx_28g_get_pccr() and
  lynx_28g_get_pcvt_offset().
- Add forgotten priv->info->lane_supports_mode() test to
  lynx_28g_supports_lane_mode().
- Rename the "fsl,lynx-28g" drvdata as lynx_info_compat rather than
  lynx_info_lx2160a_serdes1, to reflect its treatment as less featured.
- Implement a separate lane probing path for the #phy-cells = <0> case.

 drivers/phy/freescale/phy-fsl-lynx-28g.c | 202 ++++++++++++++++++++---
 1 file changed, 179 insertions(+), 23 deletions(-)

 drivers/phy/freescale/phy-fsl-lynx-28g.c | 127 +++++++++++++++++++++--
 1 file changed, 117 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
index 649c5c2fa4ad..906cd1a4af19 100644
--- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
+++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
@@ -433,9 +433,15 @@ struct lynx_28g_lane {
 	enum lynx_lane_mode mode;
 };
 
+struct lynx_info {
+	bool (*lane_supports_mode)(int lane, enum lynx_lane_mode mode);
+	int first_lane;
+};
+
 struct lynx_28g_priv {
 	void __iomem *base;
 	struct device *dev;
+	const struct lynx_info *info;
 	/* Serialize concurrent access to registers shared between lanes,
 	 * like PCCn
 	 */
@@ -500,11 +506,18 @@ static enum lynx_lane_mode phy_interface_to_lane_mode(phy_interface_t intf)
 	}
 }
 
-static bool lynx_28g_supports_lane_mode(struct lynx_28g_priv *priv,
+/* A lane mode is supported if we have a PLL that can provide its required
+ * clock net, and if there is a protocol converter for that mode on that lane.
+ */
+static bool lynx_28g_supports_lane_mode(struct lynx_28g_lane *lane,
 					enum lynx_lane_mode mode)
 {
+	struct lynx_28g_priv *priv = lane->priv;
 	int i;
 
+	if (!priv->info->lane_supports_mode(lane->id, mode))
+		return false;
+
 	for (i = 0; i < LYNX_28G_NUM_PLL; i++) {
 		if (PLLnRSTCTL_DIS(priv->pll[i].rstctl))
 			continue;
@@ -687,6 +700,86 @@ static int lynx_28g_get_pcvt_offset(int lane, enum lynx_lane_mode lane_mode)
 	}
 }
 
+static bool lx2160a_serdes1_lane_supports_mode(int lane,
+					       enum lynx_lane_mode mode)
+{
+	return true;
+}
+
+static bool lx2160a_serdes2_lane_supports_mode(int lane,
+					       enum lynx_lane_mode mode)
+{
+	switch (mode) {
+	case LANE_MODE_1000BASEX_SGMII:
+		return true;
+	case LANE_MODE_USXGMII:
+	case LANE_MODE_10GBASER:
+		return lane == 6 || lane == 7;
+	default:
+		return false;
+	}
+}
+
+static bool lx2160a_serdes3_lane_supports_mode(int lane,
+					       enum lynx_lane_mode mode)
+{
+	/*
+	 * Non-networking SerDes, and this driver supports only
+	 * networking protocols
+	 */
+	return false;
+}
+
+static bool lx2162a_serdes1_lane_supports_mode(int lane,
+					       enum lynx_lane_mode mode)
+{
+	return true;
+}
+
+static bool lx2162a_serdes2_lane_supports_mode(int lane,
+					       enum lynx_lane_mode mode)
+{
+	return lx2160a_serdes2_lane_supports_mode(lane, mode);
+}
+
+static bool lynx_28g_compat_lane_supports_mode(int lane,
+					       enum lynx_lane_mode mode)
+{
+	switch (mode) {
+	case LANE_MODE_1000BASEX_SGMII:
+	case LANE_MODE_USXGMII:
+	case LANE_MODE_10GBASER:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static const struct lynx_info lynx_info_compat = {
+	.lane_supports_mode = lynx_28g_compat_lane_supports_mode,
+};
+
+static const struct lynx_info lynx_info_lx2160a_serdes1 = {
+	.lane_supports_mode = lx2160a_serdes1_lane_supports_mode,
+};
+
+static const struct lynx_info lynx_info_lx2160a_serdes2 = {
+	.lane_supports_mode = lx2160a_serdes2_lane_supports_mode,
+};
+
+static const struct lynx_info lynx_info_lx2160a_serdes3 = {
+	.lane_supports_mode = lx2160a_serdes3_lane_supports_mode,
+};
+
+static const struct lynx_info lynx_info_lx2162a_serdes1 = {
+	.lane_supports_mode = lx2162a_serdes1_lane_supports_mode,
+	.first_lane = 4,
+};
+
+static const struct lynx_info lynx_info_lx2162a_serdes2 = {
+	.lane_supports_mode = lx2162a_serdes2_lane_supports_mode,
+};
+
 static int lynx_pccr_read(struct lynx_28g_lane *lane, enum lynx_lane_mode mode,
 			  u32 *val)
 {
@@ -939,7 +1032,6 @@ static int lynx_28g_lane_enable_pcvt(struct lynx_28g_lane *lane,
 static int lynx_28g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
 {
 	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
-	struct lynx_28g_priv *priv = lane->priv;
 	int powered_up = lane->powered_up;
 	enum lynx_lane_mode lane_mode;
 	int err = 0;
@@ -951,7 +1043,7 @@ static int lynx_28g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
 		return -EOPNOTSUPP;
 
 	lane_mode = phy_interface_to_lane_mode(submode);
-	if (!lynx_28g_supports_lane_mode(priv, lane_mode))
+	if (!lynx_28g_supports_lane_mode(lane, lane_mode))
 		return -EOPNOTSUPP;
 
 	if (lane_mode == lane->mode)
@@ -984,14 +1076,13 @@ static int lynx_28g_validate(struct phy *phy, enum phy_mode mode, int submode,
 			     union phy_configure_opts *opts __always_unused)
 {
 	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
-	struct lynx_28g_priv *priv = lane->priv;
 	enum lynx_lane_mode lane_mode;
 
 	if (mode != PHY_MODE_ETHERNET)
 		return -EOPNOTSUPP;
 
 	lane_mode = phy_interface_to_lane_mode(submode);
-	if (!lynx_28g_supports_lane_mode(priv, lane_mode))
+	if (!lynx_28g_supports_lane_mode(lane, lane_mode))
 		return -EOPNOTSUPP;
 
 	return 0;
@@ -1067,8 +1158,10 @@ static void lynx_28g_cdr_lock_check(struct work_struct *work)
 	u32 rrstctl;
 	int i;
 
-	for (i = 0; i < LYNX_28G_NUM_LANE; i++) {
+	for (i = priv->info->first_lane; i < LYNX_28G_NUM_LANE; i++) {
 		lane = &priv->lane[i];
+		if (!lane->phy)
+			continue;
 
 		mutex_lock(&lane->phy->mutex);
 
@@ -1127,7 +1220,8 @@ static struct phy *lynx_28g_xlate(struct device *dev,
 
 	idx = args->args[0];
 
-	if (WARN_ON(idx >= LYNX_28G_NUM_LANE))
+	if (WARN_ON(idx >= LYNX_28G_NUM_LANE ||
+		    idx < priv->info->first_lane))
 		return ERR_PTR(-EINVAL);
 
 	return priv->lane[idx].phy;
@@ -1167,10 +1261,18 @@ static int lynx_28g_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	priv->dev = dev;
+	priv->info = of_device_get_match_data(dev);
 	dev_set_drvdata(dev, priv);
 	spin_lock_init(&priv->pcc_lock);
 	INIT_DELAYED_WORK(&priv->cdr_check, lynx_28g_cdr_lock_check);
 
+	/*
+	 * If we get here it means we probed on a device tree where
+	 * "fsl,lynx-28g" wasn't the fallback, but the sole compatible string.
+	 */
+	if (priv->info == &lynx_info_compat)
+		dev_warn(dev, "Please update device tree to use per-device compatible strings\n");
+
 	priv->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(priv->base))
 		return PTR_ERR(priv->base);
@@ -1194,7 +1296,7 @@ static int lynx_28g_probe(struct platform_device *pdev)
 				return -EINVAL;
 			}
 
-			if (reg >= LYNX_28G_NUM_LANE) {
+			if (reg < priv->info->first_lane || reg >= LYNX_28G_NUM_LANE) {
 				dev_err(dev, "\"reg\" property out of range for %pOF\n", child);
 				of_node_put(child);
 				return -EINVAL;
@@ -1207,7 +1309,7 @@ static int lynx_28g_probe(struct platform_device *pdev)
 			}
 		}
 	} else {
-		for (int i = 0; i < LYNX_28G_NUM_LANE; i++) {
+		for (int i = priv->info->first_lane; i < LYNX_28G_NUM_LANE; i++) {
 			err = lynx_28g_probe_lane(priv, i, NULL);
 			if (err)
 				return err;
@@ -1233,7 +1335,12 @@ static void lynx_28g_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id lynx_28g_of_match_table[] = {
-	{ .compatible = "fsl,lynx-28g" },
+	{ .compatible = "fsl,lx2160a-serdes1", .data = &lynx_info_lx2160a_serdes1 },
+	{ .compatible = "fsl,lx2160a-serdes2", .data = &lynx_info_lx2160a_serdes2 },
+	{ .compatible = "fsl,lx2160a-serdes3", .data = &lynx_info_lx2160a_serdes3 },
+	{ .compatible = "fsl,lx2162a-serdes1", .data = &lynx_info_lx2162a_serdes1 },
+	{ .compatible = "fsl,lx2162a-serdes2", .data = &lynx_info_lx2162a_serdes2 },
+	{ .compatible = "fsl,lynx-28g", .data = &lynx_info_compat }, /* fallback, keep last */
 	{ },
 };
 MODULE_DEVICE_TABLE(of, lynx_28g_of_match_table);
-- 
2.34.1

Re: [PATCH v4 phy 15/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation

[Rob Herring (Arm)]

On Mon, 10 Nov 2025 11:22:40 +0200, Vladimir Oltean wrote:
> The 28G Lynx SerDes is instantiated 3 times in the NXP LX2160A SoC and
> twice in the NXP LX2162A. All these instances share the same register
> map, but the number of lanes and the protocols supported by each lane
> differs in a way that isn't detectable by the programming model.
> 
> Going by the generic "fsl,lynx-28g" compatible string and expecting all
> SerDes instantiations to use it was a mistake that needs to be fixed.
> 
> The two major options considered are
> (a) encode the SoC and the SerDes instance in the compatible string,
>     everything else is the responsibility of the driver to derive based
>     on this sufficient information
> (b) add sufficient device tree properties to describe the per-lane
>     differences, as well as the different lane count
> 
> Another important consideration is that any decision made here should
> be consistent with the decisions taken for the yet-to-be-introduced
> 10G Lynx SerDes (older generation for older SoCs), because of how
> similar they are.
> 
> I've seen option (b) at play in this unmerged patch set for the 10G Lynx
> here, and I didn't like it:
> https://lore.kernel.org/linux-phy/20230413160607.4128315-3-sean.anderson@seco.com/
> 
> This is because there, we have a higher degree of variability in the
> PCCR register values that need to be written per protocol. This makes
> that approach more drawn-out and more prone to errors, compared to (a)
> which is more succinct and obviously correct.
> 
> So I've chosen option (a) through elimination, and this also reflects
> how the SoC reference manual provides different tables with protocol
> combinations for each SerDes. NXP clearly documents these as not
> identical, and refers to them as such (SerDes 1, 2, etc).
> 
> The per-SoC compatible string is prepended to the "fsl,lynx-28g" generic
> compatible, which is left there for compatibility with old kernels. An
> exception would be LX2160A SerDes #3, which at the time of writing is
> not described in fsl-lx2160a.dtsi, and is a non-networking SerDes, so
> the existing Linux driver is useless for it. So there is no practical
> reason to put the "fsl,lynx-28g" fallback for "fsl,lx2160a-serdes3".
> 
> The specific compatible strings give us the opportunity to express more
> constraints in the schema that we weren't able to express before:
> - We allow #phy-cells in the top-level SerDes node only for
>   compatibility with old kernels that don't know how to translate
>   "phys = <&serdes_1_lane_a>" to a PHY. We don't need that feature for
>   the not-yet-introduced LX2160A SerDes #3, so make the presence of
>   #phy-cells at the top level be dependent on the presence of the
>   "fsl,lynx-28g" fallback compatible.
> - The modernization of the compatible string should come together with
>   per-lane OF nodes.
> - LX2162A SerDes 1 has fewer lanes than the others, and trying to use
>   lanes 0-3 would be a mistake that could be caught by the schema.
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v3->v4:
> - OF nodes per lane broken out as a separate "[PATCH v4 phy 01/16]
>   dt-bindings: phy: lynx-28g: permit lane OF PHY providers"
> - rewritten commit message
> - s|"^phy@[0-9a-f]+$"|"^phy@[0-7]$"|g in patternProperties
> - define "#address-cells" and "#size-cells" as part of common
>   properties, only leave the part which marks them required in the allOf
>   constraints area
> v2->v3:
> - re-add "fsl,lynx-28g" as fallback compatible, and #phy-cells = <1> in
>   top-level "serdes" node
> - drop useless description texts
> - fix text formatting
> - schema is more lax to allow overlaying old and new required properties
> v1->v2:
> - drop the usage of "fsl,lynx-28g" as a fallback compatible
> - mark "fsl,lynx-28g" as deprecated
> - implement Josua's request for per-lane OF nodes for the new compatible
>   strings
> 
>  .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 86 +++++++++++++++++--
>  1 file changed, 79 insertions(+), 7 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/fsl,lynx-28g.example.dtb: serdes@1ea0000 (fsl,lx2160a-serdes1): '#phy-cells' does not match any of the regexes: '^phy@[0-7]$', '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/phy/fsl,lynx-28g.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20251110092241.1306838-16-vladimir.oltean@nxp.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH v4 phy 15/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation

[Vladimir Oltean]

On Mon, Nov 10, 2025 at 04:29:27AM -0600, Rob Herring (Arm) wrote:
> 
> On Mon, 10 Nov 2025 11:22:40 +0200, Vladimir Oltean wrote:
> > The 28G Lynx SerDes is instantiated 3 times in the NXP LX2160A SoC and
> > twice in the NXP LX2162A. All these instances share the same register
> > map, but the number of lanes and the protocols supported by each lane
> > differs in a way that isn't detectable by the programming model.
> > 
> > Going by the generic "fsl,lynx-28g" compatible string and expecting all
> > SerDes instantiations to use it was a mistake that needs to be fixed.
> > 
> > The two major options considered are
> > (a) encode the SoC and the SerDes instance in the compatible string,
> >     everything else is the responsibility of the driver to derive based
> >     on this sufficient information
> > (b) add sufficient device tree properties to describe the per-lane
> >     differences, as well as the different lane count
> > 
> > Another important consideration is that any decision made here should
> > be consistent with the decisions taken for the yet-to-be-introduced
> > 10G Lynx SerDes (older generation for older SoCs), because of how
> > similar they are.
> > 
> > I've seen option (b) at play in this unmerged patch set for the 10G Lynx
> > here, and I didn't like it:
> > https://lore.kernel.org/linux-phy/20230413160607.4128315-3-sean.anderson@seco.com/
> > 
> > This is because there, we have a higher degree of variability in the
> > PCCR register values that need to be written per protocol. This makes
> > that approach more drawn-out and more prone to errors, compared to (a)
> > which is more succinct and obviously correct.
> > 
> > So I've chosen option (a) through elimination, and this also reflects
> > how the SoC reference manual provides different tables with protocol
> > combinations for each SerDes. NXP clearly documents these as not
> > identical, and refers to them as such (SerDes 1, 2, etc).
> > 
> > The per-SoC compatible string is prepended to the "fsl,lynx-28g" generic
> > compatible, which is left there for compatibility with old kernels. An
> > exception would be LX2160A SerDes #3, which at the time of writing is
> > not described in fsl-lx2160a.dtsi, and is a non-networking SerDes, so
> > the existing Linux driver is useless for it. So there is no practical
> > reason to put the "fsl,lynx-28g" fallback for "fsl,lx2160a-serdes3".
> > 
> > The specific compatible strings give us the opportunity to express more
> > constraints in the schema that we weren't able to express before:
> > - We allow #phy-cells in the top-level SerDes node only for
> >   compatibility with old kernels that don't know how to translate
> >   "phys = <&serdes_1_lane_a>" to a PHY. We don't need that feature for
> >   the not-yet-introduced LX2160A SerDes #3, so make the presence of
> >   #phy-cells at the top level be dependent on the presence of the
> >   "fsl,lynx-28g" fallback compatible.
> > - The modernization of the compatible string should come together with
> >   per-lane OF nodes.
> > - LX2162A SerDes 1 has fewer lanes than the others, and trying to use
> >   lanes 0-3 would be a mistake that could be caught by the schema.
> > 
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > ---
> > v3->v4:
> > - OF nodes per lane broken out as a separate "[PATCH v4 phy 01/16]
> >   dt-bindings: phy: lynx-28g: permit lane OF PHY providers"
> > - rewritten commit message
> > - s|"^phy@[0-9a-f]+$"|"^phy@[0-7]$"|g in patternProperties
> > - define "#address-cells" and "#size-cells" as part of common
> >   properties, only leave the part which marks them required in the allOf
> >   constraints area
> > v2->v3:
> > - re-add "fsl,lynx-28g" as fallback compatible, and #phy-cells = <1> in
> >   top-level "serdes" node
> > - drop useless description texts
> > - fix text formatting
> > - schema is more lax to allow overlaying old and new required properties
> > v1->v2:
> > - drop the usage of "fsl,lynx-28g" as a fallback compatible
> > - mark "fsl,lynx-28g" as deprecated
> > - implement Josua's request for per-lane OF nodes for the new compatible
> >   strings
> > 
> >  .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 86 +++++++++++++++++--
> >  1 file changed, 79 insertions(+), 7 deletions(-)
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/fsl,lynx-28g.example.dtb: serdes@1ea0000 (fsl,lx2160a-serdes1): '#phy-cells' does not match any of the regexes: '^phy@[0-7]$', '^pinctrl-[0-9]+$'
> 	from schema $id: http://devicetree.org/schemas/phy/fsl,lynx-28g.yaml
> 
> doc reference errors (make refcheckdocs):
> 
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20251110092241.1306838-16-vladimir.oltean@nxp.com
> 
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>

I'm terribly sorry about this. There was a testing fault that led to
this mistake remaining uncaught.
Originally I was testing with "make -j $ncpu DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=net/ dt_binding_check":
https://github.com/vladimiroltean/nipa/commit/5579a443f88ec7f8a3e33108acb3d9d529ff825a
(and because this is a patch on Documentation/dt-bindings/phy/ rather than net/,
I missed the warnings).
I had fixed this when submitting the pull request to Jakub (removed DT_SCHEMA_FILES=net/):
https://github.com/linux-netdev/nipa/pull/65/commits/b7d53ebaaeaf1a4e474d6cd85b3b73d557a669a2
but I forgot to pull in the modification back into the test automation framework that I used :-/

Anyway, regarding the warning itself: I had forgotten in the 1+ month
since v3 why I had to do this:
https://lore.kernel.org/linux-phy/20250926180505.760089-13-vladimir.oltean@nxp.com/

 properties:
-  "#phy-cells":
-    const: 1
+
+  "#phy-cells": true // <--- this
...
+allOf:
...
+      properties:
+        "#phy-cells":
+          const: 1
+      required:
+        - "#phy-cells"

so I removed that part, but I'll have to add it back.


@linux-phy maintainers, if this turns out to be the only problem after
review, could you still consider applying patches 1-14, so that I can
make less noise while resending?

Re: [PATCH v4 phy 01/16] dt-bindings: phy: lynx-28g: permit lane OF PHY providers

[Rob Herring (Arm)]

On Mon, 10 Nov 2025 11:22:26 +0200, Vladimir Oltean wrote:
> Josua Mayer requested to have OF nodes for each lane, so that he
> (and other board developers) can further describe electrical parameters
> individually.
> 
> For this use case, we need a container node to apply the already
> existing Documentation/devicetree/bindings/phy/transmit-amplitude.yaml,
> plus whatever other schemas might get standardized for TX equalization
> parameters, polarity inversion etc.
> 
> When lane OF nodes exist, these are also PHY providers ("phys" phandles
> can point directly to them). Compare that to the existing binding, where
> the PHY provider is the top-level SerDes node, and the second cell in
> the "phys" phandle specifies the lane index.
> 
> The new binding format overlaps over the old one without interfering,
> but there is a caveat:
> 
> Existing device trees, which already have "phys = <&serdes1 0>" cannot
> be converted to "phys = <&serdes_1_lane_a>", because in doing so, we
> would break compatibility with old kernels which don't understand how to
> translate the latter phandle to a PHY.
> 
> The transition to the new phandle format can be performed only after a
> reasonable amount of time has elapsed after this schema change and the
> corresponding driver change have been backported to stable kernels.
> 
> However, the aforementioned transition is not strictly necessary, and
> the "hybrid" description (where individual lanes have their own OF node,
> but are not pointed to by the "phys" phandle) can remain for an
> indefinite amount of time, even if a little inelegant.
> 
> For newly introduced device trees, where there are no compatibility
> concerns with old kernels to speak of, it is strongly recommended to use
> the "phys = <&serdes_1_lane_a>" format. The same holds for phandles
> towards lanes of LX2160A SerDes #3, which at the time of writing is not
> yet described in fsl-lx2160a.dtsi, so there is no legacy to maintain.
> 
> To avoid the strange situation where we have a "phy" (SerDes node) ->
> "phy" (lane node) hierarchy, let's rename the expected name of the
> top-level node to "serdes", and update the example too. This has a
> theoretical chance of causing regressions if bootloaders search for
> hardcoded paths rather than using aliases, but to the best of my
> knowledge, for LX2160A/LX2162A this is not the case.
> 
> Link: https://lore.kernel.org/lkml/02270f62-9334-400c-b7b9-7e6a44dbbfc9@solid-run.com/
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: stable@vger.kernel.org
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v3-v4: patch is new (broken out from previous "[PATCH v3 phy 12/17]
>        dt-bindings: phy: lynx-28g: add compatible strings per SerDes
>        and instantiation") to deal just with the lane OF nodes, in a
>        backportable way
> 
>  .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 71 ++++++++++++++++++-
>  1 file changed, 70 insertions(+), 1 deletion(-)
> 

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

Re: [PATCH v4 phy 01/16] dt-bindings: phy: lynx-28g: permit lane OF PHY providers

[Vinod Koul]

On 10-11-25, 11:22, Vladimir Oltean wrote:
> Josua Mayer requested to have OF nodes for each lane, so that he
> (and other board developers) can further describe electrical parameters
> individually.
> 
> For this use case, we need a container node to apply the already
> existing Documentation/devicetree/bindings/phy/transmit-amplitude.yaml,
> plus whatever other schemas might get standardized for TX equalization
> parameters, polarity inversion etc.
> 
> When lane OF nodes exist, these are also PHY providers ("phys" phandles
> can point directly to them). Compare that to the existing binding, where
> the PHY provider is the top-level SerDes node, and the second cell in
> the "phys" phandle specifies the lane index.
> 
> The new binding format overlaps over the old one without interfering,
> but there is a caveat:
> 
> Existing device trees, which already have "phys = <&serdes1 0>" cannot
> be converted to "phys = <&serdes_1_lane_a>", because in doing so, we
> would break compatibility with old kernels which don't understand how to
> translate the latter phandle to a PHY.
> 
> The transition to the new phandle format can be performed only after a
> reasonable amount of time has elapsed after this schema change and the
> corresponding driver change have been backported to stable kernels.
> 
> However, the aforementioned transition is not strictly necessary, and
> the "hybrid" description (where individual lanes have their own OF node,
> but are not pointed to by the "phys" phandle) can remain for an
> indefinite amount of time, even if a little inelegant.
> 
> For newly introduced device trees, where there are no compatibility
> concerns with old kernels to speak of, it is strongly recommended to use
> the "phys = <&serdes_1_lane_a>" format. The same holds for phandles
> towards lanes of LX2160A SerDes #3, which at the time of writing is not
> yet described in fsl-lx2160a.dtsi, so there is no legacy to maintain.
> 
> To avoid the strange situation where we have a "phy" (SerDes node) ->
> "phy" (lane node) hierarchy, let's rename the expected name of the
> top-level node to "serdes", and update the example too. This has a
> theoretical chance of causing regressions if bootloaders search for
> hardcoded paths rather than using aliases, but to the best of my
> knowledge, for LX2160A/LX2162A this is not the case.
> 
> Link: https://lore.kernel.org/lkml/02270f62-9334-400c-b7b9-7e6a44dbbfc9@solid-run.com/
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: stable@vger.kernel.org

You can keep cc lines after s-o-b line after the '---' separator, that
way it will be skipped when applying while email client will cc folks.

My main question was cc stable, for a binding additions, that might not
be helpful as dts may not have these updates, so why port bindings?

-- 
~Vinod

Re: [PATCH v4 phy 02/16] phy: lynx-28g: refactor lane probing to lynx_28g_probe_lane()

[Vinod Koul]

On 10-11-25, 11:22, Vladimir Oltean wrote:
> This simplifies the main control flow a little bit and makes the logic
> reusable for probing the lanes with OF nodes if those exist.
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: stable@vger.kernel.org
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v3->v4:
> - patch is new, broken out from previous "[PATCH v3 phy 13/17] phy:
>   lynx-28g: probe on per-SoC and per-instance compatible strings" to
>   deal only with lane OF nodes, in a backportable way
> 
>  drivers/phy/freescale/phy-fsl-lynx-28g.c | 42 +++++++++++++++---------
>  1 file changed, 26 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> index c20d2636c5e9..901240bbcade 100644
> --- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
> +++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> @@ -579,12 +579,33 @@ static struct phy *lynx_28g_xlate(struct device *dev,
>  	return priv->lane[idx].phy;
>  }
>  
> +static int lynx_28g_probe_lane(struct lynx_28g_priv *priv, int id,
> +			       struct device_node *dn)
> +{
> +	struct lynx_28g_lane *lane = &priv->lane[id];
> +	struct phy *phy;
> +
> +	memset(lane, 0, sizeof(*lane));

priv is kzalloc, so why memset here?

-- 
~Vinod

Re: [PATCH v4 phy 01/16] dt-bindings: phy: lynx-28g: permit lane OF PHY providers

[Vladimir Oltean]

Hi Vinod,

Thanks for taking a look at this patch set!

On Thu, Nov 13, 2025 at 10:16:49PM +0530, Vinod Koul wrote:
> > Link: https://lore.kernel.org/lkml/02270f62-9334-400c-b7b9-7e6a44dbbfc9@solid-run.com/
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Cc: stable@vger.kernel.org
> 
> You can keep cc lines after s-o-b line after the '---' separator, that
> way it will be skipped when applying while email client will cc folks.

Yes, but keeping the CC list even when the patch is applied was the
intention, especially for stable.

> My main question was cc stable, for a binding additions, that might not
> be helpful as dts may not have these updates, so why port bindings?

There is a faction of people, whose point as a matter of fact I do
understand, is that if you make an update to the device tree, you
shouldn't be required to also update the kernel for things to continue
to work as before.

The purpose of backporting the binding addition to stable is exactly in
order for kernels such as linux-6.12.y to start supporting modified
device trees, such that one day we could roll out such modifications.
The series doesn't depend on that, but the "DT is ABI" statement has
implications in terms of kernel <-> device tree compatibility, if you
consider the fact that they can be delivered to a board through
different channels. For example, you try to ship a bootloader that
provides its own device tree to the kernel to support generic distros
which don't come with device trees prepackaged, and you have to support
2 LTS kernels with that same device tree.

Re: [PATCH v4 phy 02/16] phy: lynx-28g: refactor lane probing to lynx_28g_probe_lane()

[Vladimir Oltean]

On Thu, Nov 13, 2025 at 10:19:55PM +0530, Vinod Koul wrote:
> On 10-11-25, 11:22, Vladimir Oltean wrote:
> > diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> > index c20d2636c5e9..901240bbcade 100644
> > --- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
> > +++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> > @@ -579,12 +579,33 @@ static struct phy *lynx_28g_xlate(struct device *dev,
> >  	return priv->lane[idx].phy;
> >  }
> >  
> > +static int lynx_28g_probe_lane(struct lynx_28g_priv *priv, int id,
> > +			       struct device_node *dn)
> > +{
> > +	struct lynx_28g_lane *lane = &priv->lane[id];
> > +	struct phy *phy;
> > +
> > +	memset(lane, 0, sizeof(*lane));
> 
> priv is kzalloc, so why memset here?

Great question, but this is a pattern that was pre-existing in the code,
and I don't like modifying code as I move it. I had to put a stop
somewhere (series is already 16 patch long). I can absolutely remove the
memset in part 2 once this one is merged.

Re: [PATCH v4 phy 02/16] phy: lynx-28g: refactor lane probing to lynx_28g_probe_lane()

[Vladimir Oltean]

Hi Vinod,

On Thu, Nov 13, 2025 at 06:56:46PM +0200, Vladimir Oltean wrote:
> On Thu, Nov 13, 2025 at 10:19:55PM +0530, Vinod Koul wrote:
> > On 10-11-25, 11:22, Vladimir Oltean wrote:
> > > diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> > > index c20d2636c5e9..901240bbcade 100644
> > > --- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
> > > +++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> > > @@ -579,12 +579,33 @@ static struct phy *lynx_28g_xlate(struct device *dev,
> > >  	return priv->lane[idx].phy;
> > >  }
> > >  
> > > +static int lynx_28g_probe_lane(struct lynx_28g_priv *priv, int id,
> > > +			       struct device_node *dn)
> > > +{
> > > +	struct lynx_28g_lane *lane = &priv->lane[id];
> > > +	struct phy *phy;
> > > +
> > > +	memset(lane, 0, sizeof(*lane));
> > 
> > priv is kzalloc, so why memset here?
> 
> Great question, but this is a pattern that was pre-existing in the code,
> and I don't like modifying code as I move it. I had to put a stop
> somewhere (series is already 16 patch long). I can absolutely remove the
> memset in part 2 once this one is merged.

Do you have any other comments? I'd like to know what your plans are
with this set.