[PATCH net-next v4 0/4] net: dp83867: add new output-impedance DT binding

[PATCH net-next v4 0/4] net: dp83867: add new output-impedance DT binding

[Steffen Trumtrar]

Currently the dp83867 supports setting the io impedance to minimum,
maximum, default or a value from a nvmem cell. In situations where there
is no backend for a nvmem cell, the value can not be set to anything but
minimum, maximum or default.

Add support for a ti,output-impedance-ohms binding, allowing to specify
the impedance in ohms via the devicetree. It is mutually exclusive with
the nvmem cell and the boolean bindings for minimum and maximum; the
binding schema now enforces this for all of them.

Until now, dtschema never applied the binding: it had neither a
compatible nor a select. The binding gets the compatible of the PHY ID,
which several devicetrees already use. The Xilinx ZynqMP devicetrees
then fail validation on an unused #phy-cells in their DP83867 nodes
without the patch from

    https://patch.msgid.link/20261110-v7-4-topic-zynqmp-dp83867-v1-1-04500475a560@pengutronix.de 

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Changes in v4:
- split xilinx patch out of this series
  https://patch.msgid.link/20261110-v7-4-topic-zynqmp-dp83867-v1-1-04500475a560@pengutronix.de 
- Link to v3: https://patch.msgid.link/20261106-v7-2-topic-dp83867-v3-0-45e1d3adf1bf@pengutronix.de

Changes in v3:
- new patch: drop the unused #phy-cells from the Xilinx DP83867 nodes,
  which fail validation once the binding applies to them
- new patch: give the binding a compatible and reference
  ethernet-phy.yaml; without a compatible or select, dtschema never
  applied the binding, so the new constraints would not have been checked
- ti,output-impedance-ohms takes ohms (35..70) instead of the register
  value, the driver maps it linearly to the nearest of the 32 settings
  (the datasheet does not specify the impedance of each setting)
- fix the range check, out of range values were silently masked
- describe the mutual exclusivity instead of a wrong precedence in the
  commit messages
- fix typo in commit message
- also forbid ti,min-output-impedance together with
  ti,max-output-impedance and drop the precedence note from the binding
- rename the binding patch to "Add ti,output-impedance-ohms"
- Link to v2: https://patch.msgid.link/20260826-v7-2-topic-dp83867-v2-0-a97b4cec6e93@pengutronix.de

Changes in v2:
- change 'u8 *val' to 'u32 *val'
- fix logic in driver
- update description of new binding
- rename ti,output-impedance -> ti,output-impedance-ohms
- make mutual exclusivity explicit in binding
- Link to v1: https://patch.msgid.link/20260804-v7-2-topic-dp83867-v1-0-1ca79eb54eef@pengutronix.de

---
Steffen Trumtrar (4):
      dt-bindings: net: dp83867: add compatible and reference ethernet-phy.yaml
      dt-bindings: net: dp83867: make exclusivity explicit
      dt-bindings: net: dp83867: Add ti,output-impedance-ohms
      net: phy: dp83867: support setting output-impedance

 .../devicetree/bindings/net/ti,dp83867.yaml        | 47 ++++++++++++++++++----
 drivers/net/phy/dp83867.c                          | 29 +++++++++++--
 2 files changed, 65 insertions(+), 11 deletions(-)
---
base-commit: 6584acd42820478910a771efb28a355a707e9cb0
change-id: 20260804-v7-2-topic-dp83867-e73a84c37016

Best regards,
--  
Steffen Trumtrar <s.trumtrar@pengutronix.de>

[PATCH net-next v4 1/4] dt-bindings: net: dp83867: add compatible and reference ethernet-phy.yaml

[Steffen Trumtrar]

The binding has neither a compatible nor a select, so dtschema never
applies it to a node: neither the example nor any devicetree is checked
against it.

Add the compatible of the PHY ID, optionally followed by the generic
ethernet-phy-ieee802.3-c22, which several devicetrees use. Select on the
PHY ID only, as the fallback alone would select every clause 22 PHY.
Nodes without a compatible stay valid, but are not checked.

The binding also references ethernet-controller.yaml, which describes
MACs; its node name pattern does not match a PHY node. Reference
ethernet-phy.yaml instead, which also describes reset-gpios and the
other generic PHY properties existing devicetrees use.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 Documentation/devicetree/bindings/net/ti,dp83867.yaml | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
index 4bc1f98fd9fe5..2cd8311ece5e5 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
@@ -8,7 +8,16 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: TI DP83867 ethernet PHY
 
 allOf:
-  - $ref: ethernet-controller.yaml#
+  - $ref: ethernet-phy.yaml#
+
+# only the PHY ID, not every PHY with the c22 fallback
+select:
+  properties:
+    compatible:
+      contains:
+        const: ethernet-phy-id2000.a231
+  required:
+    - compatible
 
 maintainers:
   - Andrew Davis <afd@ti.com>
@@ -28,6 +37,12 @@ description: |
     https://www.ti.com/lit/gpn/dp83867ir
 
 properties:
+  compatible:
+    minItems: 1
+    items:
+      - const: ethernet-phy-id2000.a231
+      - const: ethernet-phy-ieee802.3-c22
+
   reg:
     maxItems: 1
 
@@ -130,6 +145,7 @@ examples:
       #address-cells = <1>;
       #size-cells = <0>;
       ethphy0: ethernet-phy@0 {
+        compatible = "ethernet-phy-id2000.a231";
         reg = <0>;
         tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
         rx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;

-- 
2.56.0

Re: [PATCH net-next v4 1/4] dt-bindings: net: dp83867: add compatible and reference ethernet-phy.yaml

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] This patch adds `select: properties: compatible: contains:
  const: ethernet-phy-id2000.a231` to…

--

dt-bindings: net: dp83867: add compatible and reference ethernet-phy.yaml

This patch adds a compatible for the DP83867 PHY ID, with an optional
ethernet-phy-ieee802.3-c22 fallback. It also adds a select on the PHY ID,
so dtschema now applies the binding to nodes. The $ref changes from
ethernet-controller.yaml to ethernet-phy.yaml.

> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
> index 4bc1f98fd9fe5..2cd8311ece5e5 100644
> --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
> @@ -8,7 +8,16 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
>  title: TI DP83867 ethernet PHY
>  
>  allOf:
> -  - $ref: ethernet-controller.yaml#
> +  - $ref: ethernet-phy.yaml#
> +
> +# only the PHY ID, not every PHY with the c22 fallback
> +select:
> +  properties:
> +    compatible:
> +      contains:
> +        const: ethernet-phy-id2000.a231
> +  required:
> +    - compatible

[Severity: Medium]
With this select, the schema now applies to every in-tree node that has
"ethernet-phy-id2000.a231". The binding still ends with:

    unevaluatedProperties: false

Several Xilinx ZynqMP devicetrees set #phy-cells on their DP83867 nodes.
For example, arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts has:

    phy0: ethernet-phy@21 {
        #phy-cells = <1>;
        compatible = "ethernet-phy-id2000.a231";

The same pattern is in zynqmp-zcu102-revB.dts, zynqmp-zcu104-revA.dts,
zynqmp-zcu104-revC.dts, zynqmp-zcu106-revA.dts, zynqmp-zcu111-revA.dts,
zynqmp-sck-kv-g-revA.dtso and zynqmp-sck-kv-g-revB.dtso. It is also in
zynqmp-sck-kr-g-revA.dtso and zynqmp-sck-kr-g-revB.dtso, with two PHYs
in each.

#phy-cells is not defined in ti,dp83867.yaml or in ethernet-phy.yaml. With
this patch, will make dtbs_check report "Unevaluated properties are not
allowed ('#phy-cells' was unexpected)" for all 12 of these nodes?

The commit message says:

    Reference
    ethernet-phy.yaml instead, which also describes reset-gpios and the
    other generic PHY properties existing devicetrees use.

That doesn't seem to hold for #phy-cells.

The later patches in the series keep the select and
unevaluatedProperties: false. They don't change these DTS files either, so
the mismatch is still there at the end of the series.

Should the series either drop #phy-cells from the Xilinx devicetrees, or
allow it in the schema? It looks bogus on an MDIO PHY that isn't a generic
PHY provider.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110-v7-2-topic-dp83867-v4-0-a268f83b1ec1%40pengutronix.de

[PATCH net-next v4 2/4] dt-bindings: net: dp83867: make exclusivity explicit

[Steffen Trumtrar]

The io_impedance_ctrl nvmem cell and the properties
ti,{min,max}-output-impedance are mutually exclusive, as noted in the
ti,max-output-impedance description.

As this is only stated in the description and not made explicit in the
schema, the binding checker will not catch if this condition is ignored.

Make it explicit in the schema that only one of them can be used. With
that, drop the note, which also described a precedence for device trees
that the schema now rejects.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 Documentation/devicetree/bindings/net/ti,dp83867.yaml | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
index 2cd8311ece5e5..833540743bdf6 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
@@ -7,9 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 
 title: TI DP83867 ethernet PHY
 
-allOf:
-  - $ref: ethernet-phy.yaml#
-
 # only the PHY ID, not every PHY with the c22 fallback
 select:
   properties:
@@ -67,11 +64,6 @@ properties:
     description: |
       MAC Interface Impedance control to set the programmable output impedance
       to a maximum value (70 ohms).
-      Note: Specifying an io_impedance_ctrl nvmem cell or one of the
-        ti,min-output-impedance, ti,max-output-impedance properties
-        are mutually exclusive. If more than one is present, an nvmem
-        cell takes precedence over ti,max-output-impedance, which in
-        turn takes precedence over ti,min-output-impedance.
 
   tx-fifo-depth:
     $ref: /schemas/types.yaml#/definitions/uint32
@@ -133,6 +125,15 @@ properties:
       Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable
       values.
 
+allOf:
+  - $ref: ethernet-phy.yaml#
+  - not:
+      required: [nvmem-cells, "ti,min-output-impedance"]
+  - not:
+      required: [nvmem-cells, "ti,max-output-impedance"]
+  - not:
+      required: ["ti,min-output-impedance", "ti,max-output-impedance"]
+
 required:
   - reg
 

-- 
2.56.0

[PATCH net-next v4 3/4] dt-bindings: net: dp83867: Add ti,output-impedance-ohms

[Steffen Trumtrar]

Currently, the output-impedance can only be set to default, minimum or
maximum or via a nvmem cell.
In cases where there is no backend for a nvmem cell, a value can not be
set.

Add a DT binding, 'ti,output-impedance-ohms', for specifying the
output-impedance in ohms, between 35 and 70. Like the existing
properties, it is mutually exclusive with the nvmem cell and with
ti,{min,max}-output-impedance.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 Documentation/devicetree/bindings/net/ti,dp83867.yaml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
index 833540743bdf6..557d2517a72ed 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
@@ -53,6 +53,16 @@ properties:
     items:
       - const: io_impedance_ctrl
 
+  ti,output-impedance-ohms:
+    description: |
+      MAC Interface Impedance control to set the programmable output impedance
+      to a value between minimum (35 ohms) and maximum (70 ohms). The PHY
+      has 32 settings in this range; the datasheet does not specify the
+      impedance of each setting, so the value is mapped linearly to the
+      nearest one.
+    minimum: 35
+    maximum: 70
+
   ti,min-output-impedance:
     type: boolean
     description: |
@@ -133,6 +143,12 @@ allOf:
       required: [nvmem-cells, "ti,max-output-impedance"]
   - not:
       required: ["ti,min-output-impedance", "ti,max-output-impedance"]
+  - not:
+      required: [nvmem-cells, "ti,output-impedance-ohms"]
+  - not:
+      required: ["ti,output-impedance-ohms", "ti,min-output-impedance"]
+  - not:
+      required: ["ti,output-impedance-ohms", "ti,max-output-impedance"]
 
 required:
   - reg

-- 
2.56.0

[PATCH net-next v4 4/4] net: phy: dp83867: support setting output-impedance

[Steffen Trumtrar]

Currently the dp83867 supports setting the io impedance to minimum,
maximum, default or a value from a nvmem cell. In situations where there
is no backend for a nvmem cell, the value can not be set to anything but
minimum, maximum or default.

Add support for the ti,output-impedance-ohms binding, allowing to
specify the impedance in ohms via the devicetree. The PHY has 32
settings between 35 and 70 ohms. The datasheet does not specify the
impedance of each setting, so the value is mapped linearly to the
nearest one.

With this mapping, 50 ohms results in 0x12. For non-OF devices, the
driver sets 0x0f (IO_IMPEDANCE_MIN / 2) as the 50 ohm default "per
datasheet", which would be 53 ohms with the linear mapping. As the
datasheet only gives the range, neither value can be checked against it.

The binding does not allow combining the new property with the nvmem
cell or the boolean properties. The driver still reads the nvmem cell
first, then ti,max-output-impedance, ti,min-output-impedance and
ti,output-impedance-ohms.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 drivers/net/phy/dp83867.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index a3cd5cb11ea0a..ca668e75f0c99 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -119,6 +119,9 @@
 #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK	0x1f
 #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX	0x0
 #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN	0x1f
+/* Output impedance at IO_IMPEDANCE_MIN and IO_IMPEDANCE_MAX (datasheet) */
+#define DP83867_IO_IMPEDANCE_MIN_OHMS		35
+#define DP83867_IO_IMPEDANCE_MAX_OHMS		70
 #define DP83867_IO_MUX_CFG_CLK_O_DISABLE	BIT(6)
 #define DP83867_IO_MUX_CFG_CLK_O_SEL_MASK	(0x1f << 8)
 #define DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT	8
@@ -542,7 +545,8 @@ static int dp83867_of_init_io_impedance(struct phy_device *phydev)
 	struct device *dev = &phydev->mdio.dev;
 	struct device_node *of_node = dev->of_node;
 	struct nvmem_cell *cell;
-	u8 *buf, val;
+	u8 *buf;
+	u32 val;
 	int ret;
 
 	cell = of_nvmem_cell_get(of_node, "io_impedance_ctrl");
@@ -553,12 +557,29 @@ static int dp83867_of_init_io_impedance(struct phy_device *phydev)
 						"failed to get nvmem cell io_impedance_ctrl\n");
 
 		/* If no nvmem cell, check for the boolean properties. */
-		if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+		if (of_property_read_bool(of_node, "ti,max-output-impedance")) {
 			dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
-		else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+		} else if (of_property_read_bool(of_node, "ti,min-output-impedance")) {
 			dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
-		else
+		} else if (of_property_read_u32(of_node, "ti,output-impedance-ohms", &val) == 0) {
+			if (val < DP83867_IO_IMPEDANCE_MIN_OHMS ||
+			    val > DP83867_IO_IMPEDANCE_MAX_OHMS) {
+				phydev_err(phydev, "'ti,output-impedance-ohms' contents out of range\n");
+				return -ERANGE;
+			}
+			/*
+			 * 0x00 = 70 ohms ... 0x1f = 35 ohms. The datasheet
+			 * does not specify the settings in between, map the
+			 * range linearly to the nearest one.
+			 */
+			dp83867->io_impedance =
+				DIV_ROUND_CLOSEST((DP83867_IO_IMPEDANCE_MAX_OHMS - val) *
+						  DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK,
+						  DP83867_IO_IMPEDANCE_MAX_OHMS -
+						  DP83867_IO_IMPEDANCE_MIN_OHMS);
+		} else {
 			dp83867->io_impedance = -1; /* leave at default */
+		}
 
 		return 0;
 	}

-- 
2.56.0

Re: [PATCH net-next v4 4/4] net: phy: dp83867: support setting output-impedance

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 2

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new 'ti,output-impedance-ohms' property turns an absolute
  ohm value into a fixed IO_IMPEDANCE_CTRL code with a straight line: 70…
- [Low] After this patch dp83867.c holds two conflicting descriptions of
  the same IO_IMPEDANCE_CTRL field.
- [Low] In dp83867_of_init_io_impedance(), the comment '/* If no nvmem
  cell, check for the boolean properties.

--

net: phy: dp83867: support setting output-impedance

This commit adds support for a ti,output-impedance-ohms devicetree
property to the dp83867 driver. A value in the range 35..70 ohms is mapped
linearly onto the 32 IO_IMPEDANCE_CTRL codes, and values outside that
range fail with -ERANGE.

> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index a3cd5cb11ea0a..ca668e75f0c99 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c

[ ... ]

> @@ -553,12 +557,29 @@ static int dp83867_of_init_io_impedance(struct phy_device *phydev)
>  						"failed to get nvmem cell io_impedance_ctrl\n");
>  
>  		/* If no nvmem cell, check for the boolean properties. */
> -		if (of_property_read_bool(of_node, "ti,max-output-impedance"))
> +		if (of_property_read_bool(of_node, "ti,max-output-impedance")) {
>  			dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> -		else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
> +		} else if (of_property_read_bool(of_node, "ti,min-output-impedance")) {
>  			dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
> -		else
> +		} else if (of_property_read_u32(of_node, "ti,output-impedance-ohms", &val) == 0) {

[Severity: Low]
This isn't a bug, but the comment above still says "check for the boolean
properties". The block now also reads the u32 ti,output-impedance-ohms
property and can return -ERANGE. Could the comment be updated to match?

> +			if (val < DP83867_IO_IMPEDANCE_MIN_OHMS ||
> +			    val > DP83867_IO_IMPEDANCE_MAX_OHMS) {
> +				phydev_err(phydev, "'ti,output-impedance-ohms' contents out of range\n");
> +				return -ERANGE;
> +			}
> +			/*
> +			 * 0x00 = 70 ohms ... 0x1f = 35 ohms. The datasheet
> +			 * does not specify the settings in between, map the
> +			 * range linearly to the nearest one.
> +			 */

[Severity: Low]
With this mapping, 50 ohms becomes 0x12 and 0x0f is about 53 ohms. The
non-OF dp83867_of_init() in the same file still says something different:

	/* Per datasheet, IO impedance is default to 50-ohm, so we set the
	 * same here or else the default '0' means highest IO impedance
	 * which is wrong.
	 */
	dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN / 2;

So after this patch the driver has two descriptions of the same field. A
nominal 50 ohms programs a different code depending on whether
CONFIG_OF_MDIO is enabled.

The commit message mentions this mismatch, but both the comment and the
two values are left as they are. Should the two paths agree, or should one
of the comments say that its value is only approximate?

> +			dp83867->io_impedance =
> +				DIV_ROUND_CLOSEST((DP83867_IO_IMPEDANCE_MAX_OHMS - val) *
> +						  DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK,
> +						  DP83867_IO_IMPEDANCE_MAX_OHMS -
> +						  DP83867_IO_IMPEDANCE_MIN_OHMS);

[Severity: Medium]
Can a fixed linear formula give the requested impedance on a given chip?

Commit ab1e9de84aff ("dt-bindings: dp83867: add binding for
io_impedance_ctrl nvmem cell") says the IO_IMPEDANCE_CTRL reset value is
"factory calibrated to a value corresponding to approximately 50 ohms".
It also says:

  There is no fixed mapping from register values to values in the range
  35-70 ohms; it varies from chip to chip, and even that target range is
  approximate.

That is why a per-board nvmem cell was added then, rather than an ohms
property.

With this patch, ti,output-impedance-ohms = <50> computes 0x12 on every
part. dp83867_config_init() then writes that code over the factory-trimmed
value on each probe, resume and soft reset:

	/* If specified, set io impedance */
	if (dp83867->io_impedance >= 0)
		phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
			       DP83867_IO_MUX_CFG_IO_IMPEDANCE_MASK,
			       dp83867->io_impedance);

As a result, the RGMII output impedance can differ from the requested ohms
from one chip to the next, and no error is reported.

If the binding description for ti,output-impedance-ohms also documents
this linear mapping, the ohm semantics become DT ABI that the hardware
cannot guarantee.

Would a raw register code property work better here? Another option would
be to document the ohm value as approximate and keep the reset value as
the 50 ohm point.

> +		} else {
>  			dp83867->io_impedance = -1; /* leave at default */
> +		}
>  
>  		return 0;
>  	}

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110-v7-2-topic-dp83867-v4-0-a268f83b1ec1%40pengutronix.de

Re: [PATCH net-next v4 4/4] net: phy: dp83867: support setting output-impedance

[Andrew Lunn]

> Would a raw register code property work better here?

That goes against DT best practices.

> Another option would
> be to document the ohm value as approximate

This seems more reasonable.

     Andrew