* [PATCH net-next v1 0/3] Convert Micrel bindings to YAML, add keep-preamble-before-sfd
@ 2025-12-12 8:46 Stefan Eichenberger
2025-12-12 8:46 ` [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema Stefan Eichenberger
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-12 8:46 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, hkallweit1, linux, geert+renesas, ben.dooks
Cc: netdev, devicetree, linux-kernel, francesco.dolcini, rafael.beims
This series converts the Micrel Ethernet PHY device tree bindings to
YAML format. After the conversion, a new property is added that allows
to keep the preamble bytes before the start frame delimiter (SFD). This
helps to work around some issues with the EQOS Ethernet Controller used
on the i.MX8MP which would otherwise not receive frames from the PHY in
10MBit/s mode. The full description of the issue can be found in the
patch messages adding the new property.
Andrew Lunn I added you and myself as a maintainer to the micrel.yaml
file. Please let me know if you do not agree and if I should change
that.
Stefan Eichenberger (3):
dt-bindings: net: micrel: Convert to YAML schema
dt-bindings: net: micrel: Add keep-preamble-before-sfd
net: phy: micrel: Add keep-preamble-before-sfd property
.../bindings/net/micrel-ksz90x1.txt | 228 --------
.../devicetree/bindings/net/micrel.txt | 57 --
.../devicetree/bindings/net/micrel.yaml | 540 ++++++++++++++++++
drivers/net/phy/micrel.c | 29 +
4 files changed, 569 insertions(+), 285 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
--
2.51.0
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema
2025-12-12 8:46 [PATCH net-next v1 0/3] Convert Micrel bindings to YAML, add keep-preamble-before-sfd Stefan Eichenberger
@ 2025-12-12 8:46 ` Stefan Eichenberger
2025-12-12 10:29 ` Rob Herring (Arm)
` (2 more replies)
2025-12-12 8:46 ` [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd Stefan Eichenberger
2025-12-12 8:46 ` [PATCH net-next v1 3/3] net: phy: micrel: Add keep-preamble-before-sfd property Stefan Eichenberger
2 siblings, 3 replies; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-12 8:46 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, hkallweit1, linux, geert+renesas, ben.dooks
Cc: netdev, devicetree, linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Convert the devicetree bindings for the Micrel PHY to YAML schema. This
also combines the information from micrel.txt and micrel-ksz90x1.txt
into a single micrel.yaml file as this PHYs are from the same series.
Use yaml conditions to differentiate the properties that only apply to
specific PHY models.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
---
.../bindings/net/micrel-ksz90x1.txt | 228 --------
.../devicetree/bindings/net/micrel.txt | 57 --
.../devicetree/bindings/net/micrel.yaml | 527 ++++++++++++++++++
3 files changed, 527 insertions(+), 285 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
deleted file mode 100644
index 6f7b907d5a044..0000000000000
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-Micrel KSZ9021/KSZ9031/KSZ9131 Gigabit Ethernet PHY
-
-Some boards require special tuning values, particularly when it comes
-to clock delays. You can specify clock delay values in the PHY OF
-device node. Deprecated, but still supported, these properties can
-also be added to an Ethernet OF device node.
-
-Note that these settings are applied after any phy-specific fixup from
-phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
-and therefore may overwrite them.
-
-KSZ9021:
-
- All skew control options are specified in picoseconds. The minimum
- value is 0, the maximum value is 3000, and it can be specified in 200ps
- steps, *but* these values are in no way what you get because this chip's
- skew values actually increase in 120ps steps, starting from -840ps. The
- incorrect values came from an error in the original KSZ9021 datasheet
- before it was corrected in revision 1.2 (Feb 2014), but it is too late to
- change the driver now because of the many existing device trees that have
- been created using values that go up in increments of 200.
-
- The following table shows the actual skew delay you will get for each of the
- possible devicetree values, and the number that will be programmed into the
- corresponding pad skew register:
-
- Device Tree Value Delay Pad Skew Register Value
- -----------------------------------------------------
- 0 -840ps 0000
- 200 -720ps 0001
- 400 -600ps 0010
- 600 -480ps 0011
- 800 -360ps 0100
- 1000 -240ps 0101
- 1200 -120ps 0110
- 1400 0ps 0111
- 1600 120ps 1000
- 1800 240ps 1001
- 2000 360ps 1010
- 2200 480ps 1011
- 2400 600ps 1100
- 2600 720ps 1101
- 2800 840ps 1110
- 3000 960ps 1111
-
- Optional properties:
-
- - rxc-skew-ps : Skew control of RXC pad
- - rxdv-skew-ps : Skew control of RX CTL pad
- - txc-skew-ps : Skew control of TXC pad
- - txen-skew-ps : Skew control of TX CTL pad
- - rxd0-skew-ps : Skew control of RX data 0 pad
- - rxd1-skew-ps : Skew control of RX data 1 pad
- - rxd2-skew-ps : Skew control of RX data 2 pad
- - rxd3-skew-ps : Skew control of RX data 3 pad
- - txd0-skew-ps : Skew control of TX data 0 pad
- - txd1-skew-ps : Skew control of TX data 1 pad
- - txd2-skew-ps : Skew control of TX data 2 pad
- - txd3-skew-ps : Skew control of TX data 3 pad
-
-KSZ9031:
-
- All skew control options are specified in picoseconds. The minimum
- value is 0, and the maximum is property-dependent. The increment
- step is 60ps. The default value is the neutral setting, so setting
- rxc-skew-ps=<0> actually results in -900 picoseconds adjustment.
-
- The KSZ9031 hardware supports a range of skew values from negative to
- positive, where the specific range is property dependent. All values
- specified in the devicetree are offset by the minimum value so they
- can be represented as positive integers in the devicetree since it's
- difficult to represent a negative number in the devictree.
-
- The following 5-bit values table apply to rxc-skew-ps and txc-skew-ps.
-
- Pad Skew Value Delay (ps) Devicetree Value
- ------------------------------------------------------
- 0_0000 -900ps 0
- 0_0001 -840ps 60
- 0_0010 -780ps 120
- 0_0011 -720ps 180
- 0_0100 -660ps 240
- 0_0101 -600ps 300
- 0_0110 -540ps 360
- 0_0111 -480ps 420
- 0_1000 -420ps 480
- 0_1001 -360ps 540
- 0_1010 -300ps 600
- 0_1011 -240ps 660
- 0_1100 -180ps 720
- 0_1101 -120ps 780
- 0_1110 -60ps 840
- 0_1111 0ps 900
- 1_0000 60ps 960
- 1_0001 120ps 1020
- 1_0010 180ps 1080
- 1_0011 240ps 1140
- 1_0100 300ps 1200
- 1_0101 360ps 1260
- 1_0110 420ps 1320
- 1_0111 480ps 1380
- 1_1000 540ps 1440
- 1_1001 600ps 1500
- 1_1010 660ps 1560
- 1_1011 720ps 1620
- 1_1100 780ps 1680
- 1_1101 840ps 1740
- 1_1110 900ps 1800
- 1_1111 960ps 1860
-
- The following 4-bit values table apply to the txdX-skew-ps, rxdX-skew-ps
- data pads, and the rxdv-skew-ps, txen-skew-ps control pads.
-
- Pad Skew Value Delay (ps) Devicetree Value
- ------------------------------------------------------
- 0000 -420ps 0
- 0001 -360ps 60
- 0010 -300ps 120
- 0011 -240ps 180
- 0100 -180ps 240
- 0101 -120ps 300
- 0110 -60ps 360
- 0111 0ps 420
- 1000 60ps 480
- 1001 120ps 540
- 1010 180ps 600
- 1011 240ps 660
- 1100 300ps 720
- 1101 360ps 780
- 1110 420ps 840
- 1111 480ps 900
-
- Optional properties:
-
- Maximum value of 1860, default value 900:
-
- - rxc-skew-ps : Skew control of RX clock pad
- - txc-skew-ps : Skew control of TX clock pad
-
- Maximum value of 900, default value 420:
-
- - rxdv-skew-ps : Skew control of RX CTL pad
- - txen-skew-ps : Skew control of TX CTL pad
- - rxd0-skew-ps : Skew control of RX data 0 pad
- - rxd1-skew-ps : Skew control of RX data 1 pad
- - rxd2-skew-ps : Skew control of RX data 2 pad
- - rxd3-skew-ps : Skew control of RX data 3 pad
- - txd0-skew-ps : Skew control of TX data 0 pad
- - txd1-skew-ps : Skew control of TX data 1 pad
- - txd2-skew-ps : Skew control of TX data 2 pad
- - txd3-skew-ps : Skew control of TX data 3 pad
-
- - micrel,force-master:
- Boolean, force phy to master mode. Only set this option if the phy
- reference clock provided at CLK125_NDO pin is used as MAC reference
- clock because the clock jitter in slave mode is too high (errata#2).
- Attention: The link partner must be configurable as slave otherwise
- no link will be established.
-
-KSZ9131:
-LAN8841:
-
- All skew control options are specified in picoseconds. The increment
- step is 100ps. Unlike KSZ9031, the values represent picoseccond delays.
- A negative value can be assigned as rxc-skew-psec = <(-100)>;.
-
- Optional properties:
-
- Range of the value -700 to 2400, default value 0:
-
- - rxc-skew-psec : Skew control of RX clock pad
- - txc-skew-psec : Skew control of TX clock pad
-
- Range of the value -700 to 800, default value 0:
-
- - rxdv-skew-psec : Skew control of RX CTL pad
- - txen-skew-psec : Skew control of TX CTL pad
- - rxd0-skew-psec : Skew control of RX data 0 pad
- - rxd1-skew-psec : Skew control of RX data 1 pad
- - rxd2-skew-psec : Skew control of RX data 2 pad
- - rxd3-skew-psec : Skew control of RX data 3 pad
- - txd0-skew-psec : Skew control of TX data 0 pad
- - txd1-skew-psec : Skew control of TX data 1 pad
- - txd2-skew-psec : Skew control of TX data 2 pad
- - txd3-skew-psec : Skew control of TX data 3 pad
-
-Examples:
-
- /* Attach to an Ethernet device with autodetected PHY */
- &enet {
- rxc-skew-ps = <1800>;
- rxdv-skew-ps = <0>;
- txc-skew-ps = <1800>;
- txen-skew-ps = <0>;
- status = "okay";
- };
-
- /* Attach to an explicitly-specified PHY */
- mdio {
- phy0: ethernet-phy@0 {
- rxc-skew-ps = <1800>;
- rxdv-skew-ps = <0>;
- txc-skew-ps = <1800>;
- txen-skew-ps = <0>;
- reg = <0>;
- };
- };
- ethernet@70000 {
- phy = <&phy0>;
- phy-mode = "rgmii-id";
- };
-
-References
-
- Micrel ksz9021rl/rn Data Sheet, Revision 1.2. Dated 2/13/2014.
- http://www.micrel.com/_PDF/Ethernet/datasheets/ksz9021rl-rn_ds.pdf
-
- Micrel ksz9031rnx Data Sheet, Revision 2.1. Dated 11/20/2014.
- http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf
-
-Notes:
-
- Note that a previous version of the Micrel ksz9021rl/rn Data Sheet
- was missing extended register 106 (transmit data pad skews), and
- incorrectly specified the ps per step as 200ps/step instead of
- 120ps/step. The latest update to this document reflects the latest
- revision of the Micrel specification even though usage in the kernel
- still reflects that incorrect document.
diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
deleted file mode 100644
index 01622ce58112e..0000000000000
--- a/Documentation/devicetree/bindings/net/micrel.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Micrel PHY properties.
-
-These properties cover the base properties Micrel PHYs.
-
-Optional properties:
-
- - micrel,led-mode : LED mode value to set for PHYs with configurable LEDs.
-
- Configure the LED mode with single value. The list of PHYs and the
- bits that are currently supported:
-
- KSZ8001: register 0x1e, bits 15..14
- KSZ8041: register 0x1e, bits 15..14
- KSZ8021: register 0x1f, bits 5..4
- KSZ8031: register 0x1f, bits 5..4
- KSZ8051: register 0x1f, bits 5..4
- KSZ8081: register 0x1f, bits 5..4
- KSZ8091: register 0x1f, bits 5..4
- LAN8814: register EP5.0, bit 6
-
- See the respective PHY datasheet for the mode values.
-
- - micrel,rmii-reference-clock-select-25-mhz: RMII Reference Clock Select
- bit selects 25 MHz mode
-
- Setting the RMII Reference Clock Select bit enables 25 MHz rather
- than 50 MHz clock mode.
-
- Note that this option is only needed for certain PHY revisions with a
- non-standard, inverted function of this configuration bit.
- Specifically, a clock reference ("rmii-ref" below) is always needed to
- actually select a mode.
-
- - clocks, clock-names: contains clocks according to the common clock bindings.
-
- supported clocks:
- - KSZ8021, KSZ8031, KSZ8081, KSZ8091: "rmii-ref": The RMII reference
- input clock. Used to determine the XI input clock.
-
- - micrel,fiber-mode: If present the PHY is configured to operate in fiber mode
-
- Some PHYs, such as the KSZ8041FTL variant, support fiber mode, enabled
- by the FXEN boot strapping pin. It can't be determined from the PHY
- registers whether the PHY is in fiber mode, so this boolean device tree
- property can be used to describe it.
-
- In fiber mode, auto-negotiation is disabled and the PHY can only work in
- 100base-fx (full and half duplex) modes.
-
- - coma-mode-gpios: If present the given gpio will be deasserted when the
- PHY is probed.
-
- Some PHYs have a COMA mode input pin which puts the PHY into
- isolate and power-down mode. On some boards this input is connected
- to a GPIO of the SoC.
-
- Supported on the LAN8814.
diff --git a/Documentation/devicetree/bindings/net/micrel.yaml b/Documentation/devicetree/bindings/net/micrel.yaml
new file mode 100644
index 0000000000000..f48e9b9120ca0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/micrel.yaml
@@ -0,0 +1,527 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/micrel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Micrel KSZ series PHYs and switches
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Stefan Eichenberger <eichest@gmail.com>
+
+description: |
+ The Micrel KSZ series contains different network phys and switches.
+
+ Some boards require special tuning values, particularly when it comes to
+ clock delays. You can specify clock delay values in the PHY OF device node.
+
+properties:
+ compatible:
+ enum:
+ - ethernet-phy-id000e.7237 # KSZ8873MLL
+ - ethernet-phy-id0022.1430 # KSZ886X
+ - ethernet-phy-id0022.1435 # KSZ8863
+ - ethernet-phy-id0022.1510 # KSZ8041
+ - ethernet-phy-id0022.1537 # KSZ8041RNLI
+ - ethernet-phy-id0022.1550 # KSZ8051
+ - ethernet-phy-id0022.1555 # KSZ8021
+ - ethernet-phy-id0022.1556 # KSZ8031
+ - ethernet-phy-id0022.1560 # KSZ8081, KSZ8091
+ - ethernet-phy-id0022.1570 # KSZ8061
+ - ethernet-phy-id0022.1610 # KSZ9021
+ - ethernet-phy-id0022.1611 # KSZ9021RLRN
+ - ethernet-phy-id0022.161a # KSZ8001
+ - ethernet-phy-id0022.1620 # KSZ9031
+ - ethernet-phy-id0022.1631 # KSZ9477
+ - ethernet-phy-id0022.1640 # KSZ9131
+ - ethernet-phy-id0022.1650 # LAN8841
+ - ethernet-phy-id0022.1660 # LAN8814
+ - ethernet-phy-id0022.1670 # LAN8804
+ - ethernet-phy-id0022.1720 # KS8737
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ethernet-phy-id0022.1510
+ then:
+ properties:
+ micrel,fiber-mode:
+ type: boolean
+ description: |
+ If present the PHY is configured to operate in fiber mode.
+
+ The KSZ8041FTL variant, supports fiber mode, enabled by the FXEN
+ boot strapping pin. It can't be determined from the PHY registers
+ whether the PHY is in fiber mode, so this boolean device tree
+ property can be used to describe it.
+
+ In fiber mode, auto-negotiation is disabled and the PHY can only work in
+ 100base-fx (full and half duplex) modes.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id0022.1555
+ - ethernet-phy-id0022.1556
+ - ethernet-phy-id0022.1560
+ then:
+ properties:
+ clock-names:
+ const: rmii-ref
+ description: |
+ supported clocks:
+ - The RMII reference input clock. Used to determine the XI
+ input clock.
+ micrel,rmii-reference-clock-select-25-mhz:
+ type: boolean
+ description: |
+ RMII Reference Clock Select bit selects 25 MHz mode
+
+ Setting the RMII Reference Clock Select bit enables 25 MHz rather
+ than 50 MHz clock mode.
+
+ Note that this option in only needed for certain PHY revisions with a
+ non-standard, inverted function of this configuration bit.
+ Specifically, a clock reference ("rmii-ref") is always needed to
+ actually select a mode.
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ethernet-phy-id0022.1660
+ then:
+ properties:
+ coma-mode-gpios:
+ maxItems: 1
+ description: |
+ If present the given gpio will be deasserted when the PHY is probed.
+
+ Some PHYs have a COMA mode input pin which puts the PHY into
+ isolate and power-down mode. On some boards this input is connected
+ to a GPIO of the SoC.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id0022.1510
+ - ethernet-phy-id0022.1555
+ - ethernet-phy-id0022.1556
+ - ethernet-phy-id0022.1550
+ - ethernet-phy-id0022.1560
+ - ethernet-phy-id0022.161a
+ - ethernet-phy-id0022.1660
+ then:
+ properties:
+ micrel,led-mode:
+ description: |
+ LED mode value to set for PHYs with configurable LEDs.
+
+ Configure the LED mode with single value. The list of PHYs and the
+ bits that are currently supported:
+
+ KSZ8001: register 0x1e, bits 15..14
+ KSZ8041: register 0x1e, bits 15..14
+ KSZ8021: register 0x1f, bits 5..4
+ KSZ8031: register 0x1f, bits 5..4
+ KSZ8051: register 0x1f, bits 5..4
+ KSZ8081: register 0x1f, bits 5..4
+ KSZ8091: register 0x1f, bits 5..4
+ LAN8814: register EP5.0, bit 6
+
+ See the respective PHY datasheet for the mode values.
+ minimum: 0
+ maximum: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ethernet-phy-id0022.1620
+ then:
+ properties:
+ enable-edpd:
+ type: boolean
+ description:
+ Enable Energy Detect Power Down mode. Reduces power consumption when the
+ link is down.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id0022.1555
+ - ethernet-phy-id0022.1556
+ - ethernet-phy-id0022.1560
+ then:
+ properties:
+ clock-names:
+ const: rmii-ref
+ description: |
+ supported clocks:
+ - The RMII reference input clock. Used to determine the XI
+ input clock.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id0022.1610
+ - ethernet-phy-id0022.1611
+ then:
+ properties:
+ rxc-skew-ps:
+ description: |
+ Skew control of RXC pad (picoseconds). A value of 0 equals to a
+ skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ txc-skew-ps:
+ description: |
+ Skew control of TXC pad (picoseconds). A value of 0 equals to a
+ skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ rxdv-skew-ps:
+ description: |
+ Skew control of RX CTL pad (picoseconds). A value of 0 equals to a
+ skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ txen-skew-ps:
+ description: |
+ Skew control of TX CTL pad (picoseconds). A value of 0 equals to a
+ skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ rxd0-skew-ps:
+ description: |
+ Skew control of RX data 0 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ rxd1-skew-ps:
+ description: |
+ Skew control of RX data 1 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ rxd2-skew-ps:
+ description: |
+ Skew control of RX data 2 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ rxd3-skew-ps:
+ description: |
+ Skew control of RX data 3 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ txd0-skew-ps:
+ description: |
+ Skew control of TX data 0 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ txd1-skew-ps:
+ description: |
+ Skew control of TX data 1 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ txd2-skew-ps:
+ description: |
+ Skew control of TX data 2 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ txd3-skew-ps:
+ description: |
+ Skew control of TX data 3 pad (picoseconds). A value of 0 equals to
+ a skew of -840ps. Increments of 200ps are allowed.
+
+ The actual increment on the chip is 120ps ranging from -840ps to
+ 960ps, this mismatch comes from a documentation error before
+ datasheet revision 1.2 (Feb 2014):
+ minimum: 0
+ maximum: 3000
+ default: 1400
+ else:
+ if:
+ properties:
+ compatible:
+ contains:
+ const: ethernet-phy-id0022.1620
+ then:
+ properties:
+ rxc-skew-ps:
+ description: |
+ Skew control of RXC pad (picoseconds). A value of 0 equals to a skew
+ of -900ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 1860
+ default: 900
+ txc-skew-ps:
+ description: |
+ Skew control of TXC pad (picoseconds). A value of 0 equals to a skew
+ of -900ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 1860
+ default: 900
+ rxdv-skew-ps:
+ description: |
+ Skew control of RX CTL pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ txen-skew-ps:
+ description: |
+ Skew control of TX CTL pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ rxd0-skew-ps:
+ description: |
+ Skew control of RX data 0 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ rxd1-skew-ps:
+ description: |
+ Skew control of RX data 1 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ rxd2-skew-ps:
+ description: |
+ Skew control of RX data 2 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ rxd3-skew-ps:
+ description: |
+ Skew control of RX data 3 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ txd0-skew-ps:
+ description: |
+ Skew control of TX data 0 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ txd1-skew-ps:
+ description: |
+ Skew control of TX data 1 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ txd2-skew-ps:
+ description: |
+ Skew control of TX data 2 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ txd3-skew-ps:
+ description: |
+ Skew control of TX data 3 pad (picoseconds). A value of 0 equals to a
+ skew of -420ps. Increments of 60ps are allowed.
+ minimum: 0
+ maximum: 900
+ default: 420
+ else:
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id0022.1640
+ - ethernet-phy-id0022.1660
+ then:
+ properties:
+ rxc-skew-psec:
+ description: |
+ Skew control of RXC pad (picoseconds). A value of 0 equals to a
+ skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 2400
+ default: 0
+ txc-skew-psec:
+ description: |
+ Skew control of TXC pad (picoseconds). A value of 0 equals to a
+ skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 2400
+ default: 0
+ rxdv-skew-psec:
+ description: |
+ Skew control of RX CTL pad (picoseconds). A value of 0 equals to a
+ skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ txen-skew-psec:
+ description: |
+ Skew control of TX CTL pad (picoseconds). A value of 0 equals to a
+ skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ rxd0-skew-psec:
+ description: |
+ Skew control of RX data 0 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ rxd1-skew-psec:
+ description: |
+ Skew control of RX data 1 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ rxd2-skew-psec:
+ description: |
+ Skew control of RX data 2 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ rxd3-skew-psec:
+ description: |
+ Skew control of RX data 3 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ txd0-skew-psec:
+ description: |
+ Skew control of TX data 0 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ txd1-skew-psec:
+ description: |
+ Skew control of TX data 1 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ txd2-skew-psec:
+ description: |
+ Skew control of TX data 2 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+ txd3-skew-psec:
+ description: |
+ Skew control of TX data 3 pad (picoseconds). A value of 0 equals to
+ a skew value of 0ps. Increments of 100ps are allowed.
+ minimum: -700
+ maximum: 800
+ default: 0
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+
+ ethernet-phy@5 {
+ compatible = "ethernet-phy-id0022.1510";
+ reg = <5>;
+ micrel,led-mode = <2>;
+ micrel,fiber-mode;
+ };
+
+ ethernet-phy@7 {
+ compatible = "ethernet-phy-id0022.1610";
+ reg = <7>;
+ rxc-skew-ps = <3000>;
+ rxdv-skew-ps = <0>;
+ txc-skew-ps = <3000>;
+ txen-skew-ps = <0>;
+ };
+
+ ethernet-phy@9 {
+ compatible = "ethernet-phy-id0022.1640";
+ reg = <9>;
+ rxc-skew-psec = <(-100)>;
+ txc-skew-psec = <(-100)>;
+ };
+ };
--
2.51.0
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-12 8:46 [PATCH net-next v1 0/3] Convert Micrel bindings to YAML, add keep-preamble-before-sfd Stefan Eichenberger
2025-12-12 8:46 ` [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema Stefan Eichenberger
@ 2025-12-12 8:46 ` Stefan Eichenberger
2025-12-12 10:29 ` Rob Herring (Arm)
2025-12-15 14:03 ` Rob Herring
2025-12-12 8:46 ` [PATCH net-next v1 3/3] net: phy: micrel: Add keep-preamble-before-sfd property Stefan Eichenberger
2 siblings, 2 replies; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-12 8:46 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, hkallweit1, linux, geert+renesas, ben.dooks
Cc: netdev, devicetree, linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Add a property to activate a Micrel PHY feature that keeps the preamble
enabled before the SFD (Start Frame Delimiter) is transmitted.
This allows to workaround broken Ethernet controllers as found on the
NXP i.MX8MP. Specifically, errata ERR050694 that states:
ENET_QOS: MAC incorrectly discards the received packets when Preamble
Byte does not precede SFD or SMD.
The bit which disables this feature is not documented in the datasheet
from Micrel, but has been found by NXP and Micrel following this
discussion:
https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032
It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
10MBit. Withouth this property set, no packets are received. With this
property set, reception works fine.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
---
Documentation/devicetree/bindings/net/micrel.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel.yaml b/Documentation/devicetree/bindings/net/micrel.yaml
index f48e9b9120ca0..6d6136014cd62 100644
--- a/Documentation/devicetree/bindings/net/micrel.yaml
+++ b/Documentation/devicetree/bindings/net/micrel.yaml
@@ -165,6 +165,19 @@ allOf:
supported clocks:
- The RMII reference input clock. Used to determine the XI
input clock.
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ethernet-phy-id0022.1640
+ then:
+ properties:
+ micrel,keep-preamble-before-sfd:
+ type: boolean
+ description: |
+ If set, the PHY keeps sending preamble bits before SFD in
+ 10BASE-T mode. By default, the PHY removes preamble bits
+ before SFD.
- if:
properties:
compatible:
--
2.51.0
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH net-next v1 3/3] net: phy: micrel: Add keep-preamble-before-sfd property
2025-12-12 8:46 [PATCH net-next v1 0/3] Convert Micrel bindings to YAML, add keep-preamble-before-sfd Stefan Eichenberger
2025-12-12 8:46 ` [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema Stefan Eichenberger
2025-12-12 8:46 ` [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd Stefan Eichenberger
@ 2025-12-12 8:46 ` Stefan Eichenberger
2 siblings, 0 replies; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-12 8:46 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, hkallweit1, linux, geert+renesas, ben.dooks
Cc: netdev, devicetree, linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Add a property to keep the preamble before the SFD is sent from the PHY
to the Ethernet controller. By default the preamble is removed, this
property allows to keep it.
This allows to workaround broken Ethernet controllers as found on the
NXP i.MX8MP. Specifically, errata ERR050694 that states:
ENET_QOS: MAC incorrectly discards the received packets when Preamble
Byte does not precede SFD or SMD.
The bit which disables this feature is not documented in the datasheet
from Micrel, but has been found by NXP and Micrel following this
discussion:
https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032
It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
10MBit. Withouth this property set, no packets are received. With this
property set, reception works fine.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
---
drivers/net/phy/micrel.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 05de68b9f7191..0bcc380d73653 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -101,6 +101,14 @@
#define LAN8814_CABLE_DIAG_VCT_DATA_MASK GENMASK(7, 0)
#define LAN8814_PAIR_BIT_SHIFT 12
+/* KSZ9x31 remote loopback register */
+#define KSZ9x31_REMOTE_LOOPBACK 0x11
+/* This is an undocumented bit of the KSZ9131RNX.
+ * It was reported by NXP in cooperation with Micrel.
+ */
+#define KSZ9x31_REMOTE_LOOPBACK_KEEP_PREAMBLE BIT(2)
+#define KSZ9x31_REMOTE_LOOPBACK_EN BIT(8)
+
#define LAN8814_SKUS 0xB
#define LAN8814_WIRE_PAIR_MASK 0xF
@@ -455,6 +463,7 @@ struct kszphy_priv {
bool rmii_ref_clk_sel_val;
bool clk_enable;
bool is_ptp_available;
+ bool keep_preamble_before_sfd;
u64 stats[ARRAY_SIZE(kszphy_hw_stats)];
struct kszphy_phy_stats phy_stats;
};
@@ -1452,6 +1461,7 @@ static int ksz9131_config_init(struct phy_device *phydev)
"txd2-skew-psec", "txd3-skew-psec"
};
char *control_skews[2] = {"txen-skew-psec", "rxdv-skew-psec"};
+ struct kszphy_priv *priv = phydev->priv;
const struct device *dev_walker;
int ret;
@@ -1500,6 +1510,17 @@ static int ksz9131_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
+ if (priv->keep_preamble_before_sfd) {
+ ret = phy_read(phydev, KSZ9x31_REMOTE_LOOPBACK);
+ if (ret < 0)
+ return ret;
+
+ ret |= KSZ9x31_REMOTE_LOOPBACK_KEEP_PREAMBLE;
+ ret = phy_write(phydev, KSZ9x31_REMOTE_LOOPBACK, ret);
+ if (ret < 0)
+ return ret;
+ }
+
return 0;
}
@@ -2683,6 +2704,14 @@ static int kszphy_probe(struct phy_device *phydev)
priv->rmii_ref_clk_sel_val = true;
}
+ /* Keep the preamble before the SFD (Start Frame Delimiter). This might
+ * be needed on some boards with a broken Ethernet controller like the
+ * eqos used in the NXP i.MX8MP.
+ */
+ if (phydev_id_compare(phydev, PHY_ID_KSZ9131))
+ priv->keep_preamble_before_sfd = of_property_read_bool(np,
+ "micrel,keep-preamble-before-sfd");
+
return 0;
}
--
2.51.0
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-12 8:46 ` [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd Stefan Eichenberger
@ 2025-12-12 10:29 ` Rob Herring (Arm)
2025-12-15 14:03 ` Rob Herring
1 sibling, 0 replies; 17+ messages in thread
From: Rob Herring (Arm) @ 2025-12-12 10:29 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: kuba, krzk+dt, linux-kernel, netdev, davem, geert+renesas,
francesco.dolcini, conor+dt, rafael.beims, ben.dooks,
Stefan Eichenberger, hkallweit1, edumazet, devicetree,
andrew+netdev, pabeni, linux
On Fri, 12 Dec 2025 09:46:17 +0100, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
>
> Add a property to activate a Micrel PHY feature that keeps the preamble
> enabled before the SFD (Start Frame Delimiter) is transmitted.
>
> This allows to workaround broken Ethernet controllers as found on the
> NXP i.MX8MP. Specifically, errata ERR050694 that states:
> ENET_QOS: MAC incorrectly discards the received packets when Preamble
> Byte does not precede SFD or SMD.
>
> The bit which disables this feature is not documented in the datasheet
> from Micrel, but has been found by NXP and Micrel following this
> discussion:
> https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032
>
> It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
> 10MBit. Withouth this property set, no packets are received. With this
> property set, reception works fine.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> ---
> Documentation/devicetree/bindings/net/micrel.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/net/micrel.yaml:517:1: [warning] too many blank lines (2 > 1) (empty-lines)
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/renesas,ether.example.dtb: ethernet-phy@1 (ethernet-phy-id0022.1537): compatible: ['ethernet-phy-id0022.1537', 'ethernet-phy-ieee802.3-c22'] is too long
from schema $id: http://devicetree.org/schemas/net/micrel.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20251212084657.29239-3-eichest@gmail.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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema
2025-12-12 8:46 ` [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema Stefan Eichenberger
@ 2025-12-12 10:29 ` Rob Herring (Arm)
2025-12-12 14:51 ` Stefan Eichenberger
2025-12-12 14:16 ` Simon Horman
2025-12-15 14:37 ` Rob Herring
2 siblings, 1 reply; 17+ messages in thread
From: Rob Herring (Arm) @ 2025-12-12 10:29 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: hkallweit1, krzk+dt, linux-kernel, rafael.beims, pabeni,
ben.dooks, netdev, francesco.dolcini, edumazet, andrew+netdev,
conor+dt, linux, Stefan Eichenberger, devicetree, davem,
geert+renesas, kuba
On Fri, 12 Dec 2025 09:46:16 +0100, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
>
> Convert the devicetree bindings for the Micrel PHY to YAML schema. This
> also combines the information from micrel.txt and micrel-ksz90x1.txt
> into a single micrel.yaml file as this PHYs are from the same series.
> Use yaml conditions to differentiate the properties that only apply to
> specific PHY models.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> ---
> .../bindings/net/micrel-ksz90x1.txt | 228 --------
> .../devicetree/bindings/net/micrel.txt | 57 --
> .../devicetree/bindings/net/micrel.yaml | 527 ++++++++++++++++++
> 3 files changed, 527 insertions(+), 285 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
> create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/net/micrel.yaml:504:1: [warning] too many blank lines (2 > 1) (empty-lines)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20251212084657.29239-2-eichest@gmail.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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema
2025-12-12 8:46 ` [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema Stefan Eichenberger
2025-12-12 10:29 ` Rob Herring (Arm)
@ 2025-12-12 14:16 ` Simon Horman
2025-12-12 14:52 ` Stefan Eichenberger
2025-12-15 14:37 ` Rob Herring
2 siblings, 1 reply; 17+ messages in thread
From: Simon Horman @ 2025-12-12 14:16 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, hkallweit1, linux, geert+renesas, ben.dooks, netdev,
devicetree, linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Fri, Dec 12, 2025 at 09:46:16AM +0100, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
>
> Convert the devicetree bindings for the Micrel PHY to YAML schema. This
> also combines the information from micrel.txt and micrel-ksz90x1.txt
> into a single micrel.yaml file as this PHYs are from the same series.
> Use yaml conditions to differentiate the properties that only apply to
> specific PHY models.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> ---
> .../bindings/net/micrel-ksz90x1.txt | 228 --------
> .../devicetree/bindings/net/micrel.txt | 57 --
> .../devicetree/bindings/net/micrel.yaml | 527 ++++++++++++++++++
> 3 files changed, 527 insertions(+), 285 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
> create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
...
> - Optional properties:
> -
> - Maximum value of 1860, default value 900:
> -
> - - rxc-skew-ps : Skew control of RX clock pad
> - - txc-skew-ps : Skew control of TX clock pad
> -
> - Maximum value of 900, default value 420:
> -
> - - rxdv-skew-ps : Skew control of RX CTL pad
> - - txen-skew-ps : Skew control of TX CTL pad
> - - rxd0-skew-ps : Skew control of RX data 0 pad
> - - rxd1-skew-ps : Skew control of RX data 1 pad
> - - rxd2-skew-ps : Skew control of RX data 2 pad
> - - rxd3-skew-ps : Skew control of RX data 3 pad
> - - txd0-skew-ps : Skew control of TX data 0 pad
> - - txd1-skew-ps : Skew control of TX data 1 pad
> - - txd2-skew-ps : Skew control of TX data 2 pad
> - - txd3-skew-ps : Skew control of TX data 3 pad
> -
> - - micrel,force-master:
> - Boolean, force phy to master mode. Only set this option if the phy
> - reference clock provided at CLK125_NDO pin is used as MAC reference
> - clock because the clock jitter in slave mode is too high (errata#2).
> - Attention: The link partner must be configurable as slave otherwise
> - no link will be established.
Hi Stefan,
Sorry if this is off the mark, but Claude Code with
https://github.com/masoncl/review-prompts/ flags
that micrel,force-master is not included in the new .yaml
schema and yet it is used in the driver (and I would add,
several dts/dtsi files).
https://netdev-ai.bots.linux.dev/ai-review.html?id=2390d104-ff56-43f2-ba06-9650e8e5343b
...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema
2025-12-12 10:29 ` Rob Herring (Arm)
@ 2025-12-12 14:51 ` Stefan Eichenberger
0 siblings, 0 replies; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-12 14:51 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: hkallweit1, krzk+dt, linux-kernel, rafael.beims, pabeni,
ben.dooks, netdev, francesco.dolcini, edumazet, andrew+netdev,
conor+dt, linux, Stefan Eichenberger, devicetree, davem,
geert+renesas, kuba
On Fri, Dec 12, 2025 at 04:29:50AM -0600, Rob Herring (Arm) wrote:
>
> On Fri, 12 Dec 2025 09:46:16 +0100, Stefan Eichenberger wrote:
> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> >
> > Convert the devicetree bindings for the Micrel PHY to YAML schema. This
> > also combines the information from micrel.txt and micrel-ksz90x1.txt
> > into a single micrel.yaml file as this PHYs are from the same series.
> > Use yaml conditions to differentiate the properties that only apply to
> > specific PHY models.
> >
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > ---
> > .../bindings/net/micrel-ksz90x1.txt | 228 --------
> > .../devicetree/bindings/net/micrel.txt | 57 --
> > .../devicetree/bindings/net/micrel.yaml | 527 ++++++++++++++++++
> > 3 files changed, 527 insertions(+), 285 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> > delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
> > create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
> ./Documentation/devicetree/bindings/net/micrel.yaml:504:1: [warning] too many blank lines (2 > 1) (empty-lines)
>
> dtschema/dtc warnings/errors:
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20251212084657.29239-2-eichest@gmail.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.
Thanks for the finding, I will fix it in the next version. Somehow, my
linter doesn't catch that even if I run it manually, sorry about that.
Regards,
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema
2025-12-12 14:16 ` Simon Horman
@ 2025-12-12 14:52 ` Stefan Eichenberger
0 siblings, 0 replies; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-12 14:52 UTC (permalink / raw)
To: Simon Horman
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, hkallweit1, linux, geert+renesas, ben.dooks, netdev,
devicetree, linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Fri, Dec 12, 2025 at 02:16:14PM +0000, Simon Horman wrote:
> On Fri, Dec 12, 2025 at 09:46:16AM +0100, Stefan Eichenberger wrote:
> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> >
> > Convert the devicetree bindings for the Micrel PHY to YAML schema. This
> > also combines the information from micrel.txt and micrel-ksz90x1.txt
> > into a single micrel.yaml file as this PHYs are from the same series.
> > Use yaml conditions to differentiate the properties that only apply to
> > specific PHY models.
> >
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > ---
> > .../bindings/net/micrel-ksz90x1.txt | 228 --------
> > .../devicetree/bindings/net/micrel.txt | 57 --
> > .../devicetree/bindings/net/micrel.yaml | 527 ++++++++++++++++++
> > 3 files changed, 527 insertions(+), 285 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> > delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
> > create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>
> ...
>
> > - Optional properties:
> > -
> > - Maximum value of 1860, default value 900:
> > -
> > - - rxc-skew-ps : Skew control of RX clock pad
> > - - txc-skew-ps : Skew control of TX clock pad
> > -
> > - Maximum value of 900, default value 420:
> > -
> > - - rxdv-skew-ps : Skew control of RX CTL pad
> > - - txen-skew-ps : Skew control of TX CTL pad
> > - - rxd0-skew-ps : Skew control of RX data 0 pad
> > - - rxd1-skew-ps : Skew control of RX data 1 pad
> > - - rxd2-skew-ps : Skew control of RX data 2 pad
> > - - rxd3-skew-ps : Skew control of RX data 3 pad
> > - - txd0-skew-ps : Skew control of TX data 0 pad
> > - - txd1-skew-ps : Skew control of TX data 1 pad
> > - - txd2-skew-ps : Skew control of TX data 2 pad
> > - - txd3-skew-ps : Skew control of TX data 3 pad
> > -
> > - - micrel,force-master:
> > - Boolean, force phy to master mode. Only set this option if the phy
> > - reference clock provided at CLK125_NDO pin is used as MAC reference
> > - clock because the clock jitter in slave mode is too high (errata#2).
> > - Attention: The link partner must be configurable as slave otherwise
> > - no link will be established.
>
> Hi Stefan,
>
> Sorry if this is off the mark, but Claude Code with
> https://github.com/masoncl/review-prompts/ flags
> that micrel,force-master is not included in the new .yaml
> schema and yet it is used in the driver (and I would add,
> several dts/dtsi files).
>
> https://netdev-ai.bots.linux.dev/ai-review.html?id=2390d104-ff56-43f2-ba06-9650e8e5343b
>
That's correct, I missed that one. I will fix that in the next version.
Thanks for pointing it out!
Regards,
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-12 8:46 ` [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd Stefan Eichenberger
2025-12-12 10:29 ` Rob Herring (Arm)
@ 2025-12-15 14:03 ` Rob Herring
2025-12-17 9:58 ` Stefan Eichenberger
1 sibling, 1 reply; 17+ messages in thread
From: Rob Herring @ 2025-12-15 14:03 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, krzk+dt, conor+dt,
hkallweit1, linux, geert+renesas, ben.dooks, netdev, devicetree,
linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Fri, Dec 12, 2025 at 09:46:17AM +0100, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
>
> Add a property to activate a Micrel PHY feature that keeps the preamble
> enabled before the SFD (Start Frame Delimiter) is transmitted.
>
> This allows to workaround broken Ethernet controllers as found on the
> NXP i.MX8MP. Specifically, errata ERR050694 that states:
> ENET_QOS: MAC incorrectly discards the received packets when Preamble
> Byte does not precede SFD or SMD.
It doesn't really work right if you have to change the DT to work-around
a quirk in the kernel. You should have all the information needed
already in the DT. The compatible string for the i.MX8MP ethernet
controller is not sufficient?
>
> The bit which disables this feature is not documented in the datasheet
> from Micrel, but has been found by NXP and Micrel following this
> discussion:
> https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032
>
> It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
> 10MBit. Withouth this property set, no packets are received. With this
> property set, reception works fine.
What's the impact of just unconditionally setting this bit? Seems like
any impact would be minimal given 10MBit is probably pretty rare now.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema
2025-12-12 8:46 ` [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema Stefan Eichenberger
2025-12-12 10:29 ` Rob Herring (Arm)
2025-12-12 14:16 ` Simon Horman
@ 2025-12-15 14:37 ` Rob Herring
2025-12-17 9:41 ` Stefan Eichenberger
2 siblings, 1 reply; 17+ messages in thread
From: Rob Herring @ 2025-12-15 14:37 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, krzk+dt, conor+dt,
hkallweit1, linux, geert+renesas, ben.dooks, netdev, devicetree,
linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Fri, Dec 12, 2025 at 09:46:16AM +0100, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
>
> Convert the devicetree bindings for the Micrel PHY to YAML schema. This
> also combines the information from micrel.txt and micrel-ksz90x1.txt
> into a single micrel.yaml file as this PHYs are from the same series.
> Use yaml conditions to differentiate the properties that only apply to
yaml conditions? You mean json-schema conditionals. I think the whole
sentence can be dropped though.
> specific PHY models.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> ---
> .../bindings/net/micrel-ksz90x1.txt | 228 --------
> .../devicetree/bindings/net/micrel.txt | 57 --
> .../devicetree/bindings/net/micrel.yaml | 527 ++++++++++++++++++
> 3 files changed, 527 insertions(+), 285 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
> create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> deleted file mode 100644
> index 6f7b907d5a044..0000000000000
> --- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> +++ /dev/null
> @@ -1,228 +0,0 @@
> -Micrel KSZ9021/KSZ9031/KSZ9131 Gigabit Ethernet PHY
> -
> -Some boards require special tuning values, particularly when it comes
> -to clock delays. You can specify clock delay values in the PHY OF
> -device node. Deprecated, but still supported, these properties can
> -also be added to an Ethernet OF device node.
> -
> -Note that these settings are applied after any phy-specific fixup from
> -phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
> -and therefore may overwrite them.
> -
> -KSZ9021:
> -
> - All skew control options are specified in picoseconds. The minimum
> - value is 0, the maximum value is 3000, and it can be specified in 200ps
> - steps, *but* these values are in no way what you get because this chip's
> - skew values actually increase in 120ps steps, starting from -840ps. The
> - incorrect values came from an error in the original KSZ9021 datasheet
> - before it was corrected in revision 1.2 (Feb 2014), but it is too late to
> - change the driver now because of the many existing device trees that have
> - been created using values that go up in increments of 200.
> -
> - The following table shows the actual skew delay you will get for each of the
> - possible devicetree values, and the number that will be programmed into the
> - corresponding pad skew register:
> -
> - Device Tree Value Delay Pad Skew Register Value
> - -----------------------------------------------------
> - 0 -840ps 0000
> - 200 -720ps 0001
> - 400 -600ps 0010
> - 600 -480ps 0011
> - 800 -360ps 0100
> - 1000 -240ps 0101
> - 1200 -120ps 0110
> - 1400 0ps 0111
> - 1600 120ps 1000
> - 1800 240ps 1001
> - 2000 360ps 1010
> - 2200 480ps 1011
> - 2400 600ps 1100
> - 2600 720ps 1101
> - 2800 840ps 1110
> - 3000 960ps 1111
> -
> - Optional properties:
> -
> - - rxc-skew-ps : Skew control of RXC pad
> - - rxdv-skew-ps : Skew control of RX CTL pad
> - - txc-skew-ps : Skew control of TXC pad
> - - txen-skew-ps : Skew control of TX CTL pad
> - - rxd0-skew-ps : Skew control of RX data 0 pad
> - - rxd1-skew-ps : Skew control of RX data 1 pad
> - - rxd2-skew-ps : Skew control of RX data 2 pad
> - - rxd3-skew-ps : Skew control of RX data 3 pad
> - - txd0-skew-ps : Skew control of TX data 0 pad
> - - txd1-skew-ps : Skew control of TX data 1 pad
> - - txd2-skew-ps : Skew control of TX data 2 pad
> - - txd3-skew-ps : Skew control of TX data 3 pad
> -
> -KSZ9031:
> -
> - All skew control options are specified in picoseconds. The minimum
> - value is 0, and the maximum is property-dependent. The increment
> - step is 60ps. The default value is the neutral setting, so setting
> - rxc-skew-ps=<0> actually results in -900 picoseconds adjustment.
> -
> - The KSZ9031 hardware supports a range of skew values from negative to
> - positive, where the specific range is property dependent. All values
> - specified in the devicetree are offset by the minimum value so they
> - can be represented as positive integers in the devicetree since it's
> - difficult to represent a negative number in the devictree.
> -
> - The following 5-bit values table apply to rxc-skew-ps and txc-skew-ps.
> -
> - Pad Skew Value Delay (ps) Devicetree Value
> - ------------------------------------------------------
> - 0_0000 -900ps 0
> - 0_0001 -840ps 60
> - 0_0010 -780ps 120
> - 0_0011 -720ps 180
> - 0_0100 -660ps 240
> - 0_0101 -600ps 300
> - 0_0110 -540ps 360
> - 0_0111 -480ps 420
> - 0_1000 -420ps 480
> - 0_1001 -360ps 540
> - 0_1010 -300ps 600
> - 0_1011 -240ps 660
> - 0_1100 -180ps 720
> - 0_1101 -120ps 780
> - 0_1110 -60ps 840
> - 0_1111 0ps 900
> - 1_0000 60ps 960
> - 1_0001 120ps 1020
> - 1_0010 180ps 1080
> - 1_0011 240ps 1140
> - 1_0100 300ps 1200
> - 1_0101 360ps 1260
> - 1_0110 420ps 1320
> - 1_0111 480ps 1380
> - 1_1000 540ps 1440
> - 1_1001 600ps 1500
> - 1_1010 660ps 1560
> - 1_1011 720ps 1620
> - 1_1100 780ps 1680
> - 1_1101 840ps 1740
> - 1_1110 900ps 1800
> - 1_1111 960ps 1860
> -
> - The following 4-bit values table apply to the txdX-skew-ps, rxdX-skew-ps
> - data pads, and the rxdv-skew-ps, txen-skew-ps control pads.
> -
> - Pad Skew Value Delay (ps) Devicetree Value
> - ------------------------------------------------------
> - 0000 -420ps 0
> - 0001 -360ps 60
> - 0010 -300ps 120
> - 0011 -240ps 180
> - 0100 -180ps 240
> - 0101 -120ps 300
> - 0110 -60ps 360
> - 0111 0ps 420
> - 1000 60ps 480
> - 1001 120ps 540
> - 1010 180ps 600
> - 1011 240ps 660
> - 1100 300ps 720
> - 1101 360ps 780
> - 1110 420ps 840
> - 1111 480ps 900
> -
> - Optional properties:
> -
> - Maximum value of 1860, default value 900:
> -
> - - rxc-skew-ps : Skew control of RX clock pad
> - - txc-skew-ps : Skew control of TX clock pad
> -
> - Maximum value of 900, default value 420:
> -
> - - rxdv-skew-ps : Skew control of RX CTL pad
> - - txen-skew-ps : Skew control of TX CTL pad
> - - rxd0-skew-ps : Skew control of RX data 0 pad
> - - rxd1-skew-ps : Skew control of RX data 1 pad
> - - rxd2-skew-ps : Skew control of RX data 2 pad
> - - rxd3-skew-ps : Skew control of RX data 3 pad
> - - txd0-skew-ps : Skew control of TX data 0 pad
> - - txd1-skew-ps : Skew control of TX data 1 pad
> - - txd2-skew-ps : Skew control of TX data 2 pad
> - - txd3-skew-ps : Skew control of TX data 3 pad
> -
> - - micrel,force-master:
> - Boolean, force phy to master mode. Only set this option if the phy
> - reference clock provided at CLK125_NDO pin is used as MAC reference
> - clock because the clock jitter in slave mode is too high (errata#2).
> - Attention: The link partner must be configurable as slave otherwise
> - no link will be established.
> -
> -KSZ9131:
> -LAN8841:
> -
> - All skew control options are specified in picoseconds. The increment
> - step is 100ps. Unlike KSZ9031, the values represent picoseccond delays.
> - A negative value can be assigned as rxc-skew-psec = <(-100)>;.
> -
> - Optional properties:
> -
> - Range of the value -700 to 2400, default value 0:
> -
> - - rxc-skew-psec : Skew control of RX clock pad
> - - txc-skew-psec : Skew control of TX clock pad
> -
> - Range of the value -700 to 800, default value 0:
> -
> - - rxdv-skew-psec : Skew control of RX CTL pad
> - - txen-skew-psec : Skew control of TX CTL pad
> - - rxd0-skew-psec : Skew control of RX data 0 pad
> - - rxd1-skew-psec : Skew control of RX data 1 pad
> - - rxd2-skew-psec : Skew control of RX data 2 pad
> - - rxd3-skew-psec : Skew control of RX data 3 pad
> - - txd0-skew-psec : Skew control of TX data 0 pad
> - - txd1-skew-psec : Skew control of TX data 1 pad
> - - txd2-skew-psec : Skew control of TX data 2 pad
> - - txd3-skew-psec : Skew control of TX data 3 pad
> -
> -Examples:
> -
> - /* Attach to an Ethernet device with autodetected PHY */
> - &enet {
> - rxc-skew-ps = <1800>;
> - rxdv-skew-ps = <0>;
> - txc-skew-ps = <1800>;
> - txen-skew-ps = <0>;
> - status = "okay";
> - };
> -
> - /* Attach to an explicitly-specified PHY */
> - mdio {
> - phy0: ethernet-phy@0 {
> - rxc-skew-ps = <1800>;
> - rxdv-skew-ps = <0>;
> - txc-skew-ps = <1800>;
> - txen-skew-ps = <0>;
> - reg = <0>;
> - };
> - };
> - ethernet@70000 {
> - phy = <&phy0>;
> - phy-mode = "rgmii-id";
> - };
> -
> -References
> -
> - Micrel ksz9021rl/rn Data Sheet, Revision 1.2. Dated 2/13/2014.
> - http://www.micrel.com/_PDF/Ethernet/datasheets/ksz9021rl-rn_ds.pdf
> -
> - Micrel ksz9031rnx Data Sheet, Revision 2.1. Dated 11/20/2014.
> - http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf
> -
> -Notes:
> -
> - Note that a previous version of the Micrel ksz9021rl/rn Data Sheet
> - was missing extended register 106 (transmit data pad skews), and
> - incorrectly specified the ps per step as 200ps/step instead of
> - 120ps/step. The latest update to this document reflects the latest
> - revision of the Micrel specification even though usage in the kernel
> - still reflects that incorrect document.
> diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
> deleted file mode 100644
> index 01622ce58112e..0000000000000
> --- a/Documentation/devicetree/bindings/net/micrel.txt
> +++ /dev/null
> @@ -1,57 +0,0 @@
> -Micrel PHY properties.
> -
> -These properties cover the base properties Micrel PHYs.
> -
> -Optional properties:
> -
> - - micrel,led-mode : LED mode value to set for PHYs with configurable LEDs.
> -
> - Configure the LED mode with single value. The list of PHYs and the
> - bits that are currently supported:
> -
> - KSZ8001: register 0x1e, bits 15..14
> - KSZ8041: register 0x1e, bits 15..14
> - KSZ8021: register 0x1f, bits 5..4
> - KSZ8031: register 0x1f, bits 5..4
> - KSZ8051: register 0x1f, bits 5..4
> - KSZ8081: register 0x1f, bits 5..4
> - KSZ8091: register 0x1f, bits 5..4
> - LAN8814: register EP5.0, bit 6
> -
> - See the respective PHY datasheet for the mode values.
> -
> - - micrel,rmii-reference-clock-select-25-mhz: RMII Reference Clock Select
> - bit selects 25 MHz mode
> -
> - Setting the RMII Reference Clock Select bit enables 25 MHz rather
> - than 50 MHz clock mode.
> -
> - Note that this option is only needed for certain PHY revisions with a
> - non-standard, inverted function of this configuration bit.
> - Specifically, a clock reference ("rmii-ref" below) is always needed to
> - actually select a mode.
> -
> - - clocks, clock-names: contains clocks according to the common clock bindings.
> -
> - supported clocks:
> - - KSZ8021, KSZ8031, KSZ8081, KSZ8091: "rmii-ref": The RMII reference
> - input clock. Used to determine the XI input clock.
> -
> - - micrel,fiber-mode: If present the PHY is configured to operate in fiber mode
> -
> - Some PHYs, such as the KSZ8041FTL variant, support fiber mode, enabled
> - by the FXEN boot strapping pin. It can't be determined from the PHY
> - registers whether the PHY is in fiber mode, so this boolean device tree
> - property can be used to describe it.
> -
> - In fiber mode, auto-negotiation is disabled and the PHY can only work in
> - 100base-fx (full and half duplex) modes.
> -
> - - coma-mode-gpios: If present the given gpio will be deasserted when the
> - PHY is probed.
> -
> - Some PHYs have a COMA mode input pin which puts the PHY into
> - isolate and power-down mode. On some boards this input is connected
> - to a GPIO of the SoC.
> -
> - Supported on the LAN8814.
> diff --git a/Documentation/devicetree/bindings/net/micrel.yaml b/Documentation/devicetree/bindings/net/micrel.yaml
> new file mode 100644
> index 0000000000000..f48e9b9120ca0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/micrel.yaml
> @@ -0,0 +1,527 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/micrel.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Micrel KSZ series PHYs and switches
> +
> +maintainers:
> + - Andrew Lunn <andrew@lunn.ch>
> + - Stefan Eichenberger <eichest@gmail.com>
> +
> +description: |
> + The Micrel KSZ series contains different network phys and switches.
> +
> + Some boards require special tuning values, particularly when it comes to
> + clock delays. You can specify clock delay values in the PHY OF device node.
> +
> +properties:
> + compatible:
> + enum:
> + - ethernet-phy-id000e.7237 # KSZ8873MLL
> + - ethernet-phy-id0022.1430 # KSZ886X
> + - ethernet-phy-id0022.1435 # KSZ8863
> + - ethernet-phy-id0022.1510 # KSZ8041
> + - ethernet-phy-id0022.1537 # KSZ8041RNLI
> + - ethernet-phy-id0022.1550 # KSZ8051
> + - ethernet-phy-id0022.1555 # KSZ8021
> + - ethernet-phy-id0022.1556 # KSZ8031
> + - ethernet-phy-id0022.1560 # KSZ8081, KSZ8091
> + - ethernet-phy-id0022.1570 # KSZ8061
> + - ethernet-phy-id0022.1610 # KSZ9021
> + - ethernet-phy-id0022.1611 # KSZ9021RLRN
> + - ethernet-phy-id0022.161a # KSZ8001
> + - ethernet-phy-id0022.1620 # KSZ9031
> + - ethernet-phy-id0022.1631 # KSZ9477
> + - ethernet-phy-id0022.1640 # KSZ9131
> + - ethernet-phy-id0022.1650 # LAN8841
> + - ethernet-phy-id0022.1660 # LAN8814
> + - ethernet-phy-id0022.1670 # LAN8804
> + - ethernet-phy-id0022.1720 # KS8737
> +
> +allOf:
> + - $ref: ethernet-phy.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ethernet-phy-id0022.1510
> + then:
> + properties:
> + micrel,fiber-mode:
> + type: boolean
> + description: |
> + If present the PHY is configured to operate in fiber mode.
> +
> + The KSZ8041FTL variant, supports fiber mode, enabled by the FXEN
> + boot strapping pin. It can't be determined from the PHY registers
> + whether the PHY is in fiber mode, so this boolean device tree
> + property can be used to describe it.
> +
> + In fiber mode, auto-negotiation is disabled and the PHY can only work in
Wrap at 80.
> + 100base-fx (full and half duplex) modes.
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ethernet-phy-id0022.1555
> + - ethernet-phy-id0022.1556
> + - ethernet-phy-id0022.1560
> + then:
> + properties:
> + clock-names:
> + const: rmii-ref
> + description: |
> + supported clocks:
> + - The RMII reference input clock. Used to determine the XI
> + input clock.
> + micrel,rmii-reference-clock-select-25-mhz:
> + type: boolean
> + description: |
> + RMII Reference Clock Select bit selects 25 MHz mode
> +
> + Setting the RMII Reference Clock Select bit enables 25 MHz rather
> + than 50 MHz clock mode.
> +
> + Note that this option in only needed for certain PHY revisions with a
> + non-standard, inverted function of this configuration bit.
> + Specifically, a clock reference ("rmii-ref") is always needed to
> + actually select a mode.
Sounds like a dependency:
dependentRequired:
micrel,rmii-reference-clock-select-25-mhz: [ clock-names ]
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ethernet-phy-id0022.1660
> + then:
> + properties:
> + coma-mode-gpios:
> + maxItems: 1
> + description: |
> + If present the given gpio will be deasserted when the PHY is probed.
> +
> + Some PHYs have a COMA mode input pin which puts the PHY into
> + isolate and power-down mode. On some boards this input is connected
> + to a GPIO of the SoC.
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ethernet-phy-id0022.1510
> + - ethernet-phy-id0022.1555
> + - ethernet-phy-id0022.1556
> + - ethernet-phy-id0022.1550
> + - ethernet-phy-id0022.1560
> + - ethernet-phy-id0022.161a
> + - ethernet-phy-id0022.1660
> + then:
> + properties:
> + micrel,led-mode:
> + description: |
> + LED mode value to set for PHYs with configurable LEDs.
> +
> + Configure the LED mode with single value. The list of PHYs and the
> + bits that are currently supported:
> +
> + KSZ8001: register 0x1e, bits 15..14
> + KSZ8041: register 0x1e, bits 15..14
> + KSZ8021: register 0x1f, bits 5..4
> + KSZ8031: register 0x1f, bits 5..4
> + KSZ8051: register 0x1f, bits 5..4
> + KSZ8081: register 0x1f, bits 5..4
> + KSZ8091: register 0x1f, bits 5..4
> + LAN8814: register EP5.0, bit 6
> +
> + See the respective PHY datasheet for the mode values.
> + minimum: 0
> + maximum: 3
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ethernet-phy-id0022.1620
> + then:
> + properties:
> + enable-edpd:
> + type: boolean
> + description:
> + Enable Energy Detect Power Down mode. Reduces power consumption when the
> + link is down.
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ethernet-phy-id0022.1555
> + - ethernet-phy-id0022.1556
> + - ethernet-phy-id0022.1560
> + then:
> + properties:
> + clock-names:
> + const: rmii-ref
> + description: |
> + supported clocks:
> + - The RMII reference input clock. Used to determine the XI
> + input clock.
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ethernet-phy-id0022.1610
> + - ethernet-phy-id0022.1611
> + then:
> + properties:
> + rxc-skew-ps:
> + description: |
> + Skew control of RXC pad (picoseconds). A value of 0 equals to a
> + skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + txc-skew-ps:
> + description: |
> + Skew control of TXC pad (picoseconds). A value of 0 equals to a
> + skew of -840ps. Increments of 200ps are allowed.
multipleOf: 200
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + rxdv-skew-ps:
> + description: |
> + Skew control of RX CTL pad (picoseconds). A value of 0 equals to a
> + skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + txen-skew-ps:
> + description: |
> + Skew control of TX CTL pad (picoseconds). A value of 0 equals to a
> + skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + rxd0-skew-ps:
> + description: |
> + Skew control of RX data 0 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + rxd1-skew-ps:
> + description: |
> + Skew control of RX data 1 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + rxd2-skew-ps:
> + description: |
> + Skew control of RX data 2 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + rxd3-skew-ps:
> + description: |
> + Skew control of RX data 3 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + txd0-skew-ps:
> + description: |
> + Skew control of TX data 0 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + txd1-skew-ps:
> + description: |
> + Skew control of TX data 1 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + txd2-skew-ps:
> + description: |
> + Skew control of TX data 2 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
> + txd3-skew-ps:
> + description: |
> + Skew control of TX data 3 pad (picoseconds). A value of 0 equals to
> + a skew of -840ps. Increments of 200ps are allowed.
> +
> + The actual increment on the chip is 120ps ranging from -840ps to
> + 960ps, this mismatch comes from a documentation error before
> + datasheet revision 1.2 (Feb 2014):
> + minimum: 0
> + maximum: 3000
> + default: 1400
Since it is the same constraints, you can shorten all these with a
pattern:
patternProperties:
'^([rt]xd[0-3]|[rt]xc|rxdv|txen)-skew-ps$':
> + else:
> + if:
Avoid nested if/then schemas if possible. Doesn't look like it is
necessary here.
> + properties:
> + compatible:
> + contains:
> + const: ethernet-phy-id0022.1620
> + then:
> + properties:
> + rxc-skew-ps:
> + description: |
> + Skew control of RXC pad (picoseconds). A value of 0 equals to a skew
> + of -900ps. Increments of 60ps are allowed.
multipleOf: 60
(and drop the freeform text)
> + minimum: 0
> + maximum: 1860
> + default: 900
> + txc-skew-ps:
> + description: |
> + Skew control of TXC pad (picoseconds). A value of 0 equals to a skew
> + of -900ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 1860
> + default: 900
> + rxdv-skew-ps:
> + description: |
> + Skew control of RX CTL pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + txen-skew-ps:
> + description: |
> + Skew control of TX CTL pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + rxd0-skew-ps:
> + description: |
> + Skew control of RX data 0 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + rxd1-skew-ps:
> + description: |
> + Skew control of RX data 1 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + rxd2-skew-ps:
> + description: |
> + Skew control of RX data 2 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + rxd3-skew-ps:
> + description: |
> + Skew control of RX data 3 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + txd0-skew-ps:
> + description: |
> + Skew control of TX data 0 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + txd1-skew-ps:
> + description: |
> + Skew control of TX data 1 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + txd2-skew-ps:
> + description: |
> + Skew control of TX data 2 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + txd3-skew-ps:
> + description: |
> + Skew control of TX data 3 pad (picoseconds). A value of 0 equals to a
> + skew of -420ps. Increments of 60ps are allowed.
> + minimum: 0
> + maximum: 900
> + default: 420
> + else:
> + if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - ethernet-phy-id0022.1640
> + - ethernet-phy-id0022.1660
> + then:
> + properties:
> + rxc-skew-psec:
These are not a standard unit-suffix, so they need a type $ref. That
should be a warning, but probably isn't since these are underneeth an
if/then schema.
In general, the rule is don't define properties in if/then schemas.
Define them at the top level and then disallow them in if/then schemas
for specific compatibles. There's also a judgement call of when to split
bindings to separate files based on how long the if/then schemas are
compared to the top-level. I think this is well past that though using
patternProperties helps a lot. I think at least the 1640 and 1660 should
be split given the custom skew props.
Rob
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema
2025-12-15 14:37 ` Rob Herring
@ 2025-12-17 9:41 ` Stefan Eichenberger
0 siblings, 0 replies; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-17 9:41 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, krzk+dt, conor+dt,
hkallweit1, linux, geert+renesas, ben.dooks, netdev, devicetree,
linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
Hi Rob,
Thanks a lot for the feedback.
On Mon, Dec 15, 2025 at 08:37:34AM -0600, Rob Herring wrote:
> On Fri, Dec 12, 2025 at 09:46:16AM +0100, Stefan Eichenberger wrote:
> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> >
> > Convert the devicetree bindings for the Micrel PHY to YAML schema. This
> > also combines the information from micrel.txt and micrel-ksz90x1.txt
> > into a single micrel.yaml file as this PHYs are from the same series.
> > Use yaml conditions to differentiate the properties that only apply to
>
> yaml conditions? You mean json-schema conditionals. I think the whole
> sentence can be dropped though.
>
Yes, exactly. I will remove that sentence from future versions.
> > specific PHY models.
> >
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > ---
> > .../bindings/net/micrel-ksz90x1.txt | 228 --------
> > .../devicetree/bindings/net/micrel.txt | 57 --
> > .../devicetree/bindings/net/micrel.yaml | 527 ++++++++++++++++++
> > 3 files changed, 527 insertions(+), 285 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> > delete mode 100644 Documentation/devicetree/bindings/net/micrel.txt
> > create mode 100644 Documentation/devicetree/bindings/net/micrel.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> > deleted file mode 100644
> > index 6f7b907d5a044..0000000000000
> > --- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> > +++ /dev/null
> > @@ -1,228 +0,0 @@
> > -Micrel KSZ9021/KSZ9031/KSZ9131 Gigabit Ethernet PHY
> > -
> > -Some boards require special tuning values, particularly when it comes
> > -to clock delays. You can specify clock delay values in the PHY OF
> > -device node. Deprecated, but still supported, these properties can
> > -also be added to an Ethernet OF device node.
> > -
> > -Note that these settings are applied after any phy-specific fixup from
> > -phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
> > -and therefore may overwrite them.
> > -
> > -KSZ9021:
> > -
> > - All skew control options are specified in picoseconds. The minimum
> > - value is 0, the maximum value is 3000, and it can be specified in 200ps
> > - steps, *but* these values are in no way what you get because this chip's
> > - skew values actually increase in 120ps steps, starting from -840ps. The
> > - incorrect values came from an error in the original KSZ9021 datasheet
> > - before it was corrected in revision 1.2 (Feb 2014), but it is too late to
> > - change the driver now because of the many existing device trees that have
> > - been created using values that go up in increments of 200.
> > -
> > - The following table shows the actual skew delay you will get for each of the
> > - possible devicetree values, and the number that will be programmed into the
> > - corresponding pad skew register:
> > -
> > - Device Tree Value Delay Pad Skew Register Value
> > - -----------------------------------------------------
> > - 0 -840ps 0000
> > - 200 -720ps 0001
> > - 400 -600ps 0010
> > - 600 -480ps 0011
> > - 800 -360ps 0100
> > - 1000 -240ps 0101
> > - 1200 -120ps 0110
> > - 1400 0ps 0111
> > - 1600 120ps 1000
> > - 1800 240ps 1001
> > - 2000 360ps 1010
> > - 2200 480ps 1011
> > - 2400 600ps 1100
> > - 2600 720ps 1101
> > - 2800 840ps 1110
> > - 3000 960ps 1111
> > -
> > - Optional properties:
> > -
> > - - rxc-skew-ps : Skew control of RXC pad
> > - - rxdv-skew-ps : Skew control of RX CTL pad
> > - - txc-skew-ps : Skew control of TXC pad
> > - - txen-skew-ps : Skew control of TX CTL pad
> > - - rxd0-skew-ps : Skew control of RX data 0 pad
> > - - rxd1-skew-ps : Skew control of RX data 1 pad
> > - - rxd2-skew-ps : Skew control of RX data 2 pad
> > - - rxd3-skew-ps : Skew control of RX data 3 pad
> > - - txd0-skew-ps : Skew control of TX data 0 pad
> > - - txd1-skew-ps : Skew control of TX data 1 pad
> > - - txd2-skew-ps : Skew control of TX data 2 pad
> > - - txd3-skew-ps : Skew control of TX data 3 pad
> > -
> > -KSZ9031:
> > -
> > - All skew control options are specified in picoseconds. The minimum
> > - value is 0, and the maximum is property-dependent. The increment
> > - step is 60ps. The default value is the neutral setting, so setting
> > - rxc-skew-ps=<0> actually results in -900 picoseconds adjustment.
> > -
> > - The KSZ9031 hardware supports a range of skew values from negative to
> > - positive, where the specific range is property dependent. All values
> > - specified in the devicetree are offset by the minimum value so they
> > - can be represented as positive integers in the devicetree since it's
> > - difficult to represent a negative number in the devictree.
> > -
> > - The following 5-bit values table apply to rxc-skew-ps and txc-skew-ps.
> > -
> > - Pad Skew Value Delay (ps) Devicetree Value
> > - ------------------------------------------------------
> > - 0_0000 -900ps 0
> > - 0_0001 -840ps 60
> > - 0_0010 -780ps 120
> > - 0_0011 -720ps 180
> > - 0_0100 -660ps 240
> > - 0_0101 -600ps 300
> > - 0_0110 -540ps 360
> > - 0_0111 -480ps 420
> > - 0_1000 -420ps 480
> > - 0_1001 -360ps 540
> > - 0_1010 -300ps 600
> > - 0_1011 -240ps 660
> > - 0_1100 -180ps 720
> > - 0_1101 -120ps 780
> > - 0_1110 -60ps 840
> > - 0_1111 0ps 900
> > - 1_0000 60ps 960
> > - 1_0001 120ps 1020
> > - 1_0010 180ps 1080
> > - 1_0011 240ps 1140
> > - 1_0100 300ps 1200
> > - 1_0101 360ps 1260
> > - 1_0110 420ps 1320
> > - 1_0111 480ps 1380
> > - 1_1000 540ps 1440
> > - 1_1001 600ps 1500
> > - 1_1010 660ps 1560
> > - 1_1011 720ps 1620
> > - 1_1100 780ps 1680
> > - 1_1101 840ps 1740
> > - 1_1110 900ps 1800
> > - 1_1111 960ps 1860
> > -
> > - The following 4-bit values table apply to the txdX-skew-ps, rxdX-skew-ps
> > - data pads, and the rxdv-skew-ps, txen-skew-ps control pads.
> > -
> > - Pad Skew Value Delay (ps) Devicetree Value
> > - ------------------------------------------------------
> > - 0000 -420ps 0
> > - 0001 -360ps 60
> > - 0010 -300ps 120
> > - 0011 -240ps 180
> > - 0100 -180ps 240
> > - 0101 -120ps 300
> > - 0110 -60ps 360
> > - 0111 0ps 420
> > - 1000 60ps 480
> > - 1001 120ps 540
> > - 1010 180ps 600
> > - 1011 240ps 660
> > - 1100 300ps 720
> > - 1101 360ps 780
> > - 1110 420ps 840
> > - 1111 480ps 900
> > -
> > - Optional properties:
> > -
> > - Maximum value of 1860, default value 900:
> > -
> > - - rxc-skew-ps : Skew control of RX clock pad
> > - - txc-skew-ps : Skew control of TX clock pad
> > -
> > - Maximum value of 900, default value 420:
> > -
> > - - rxdv-skew-ps : Skew control of RX CTL pad
> > - - txen-skew-ps : Skew control of TX CTL pad
> > - - rxd0-skew-ps : Skew control of RX data 0 pad
> > - - rxd1-skew-ps : Skew control of RX data 1 pad
> > - - rxd2-skew-ps : Skew control of RX data 2 pad
> > - - rxd3-skew-ps : Skew control of RX data 3 pad
> > - - txd0-skew-ps : Skew control of TX data 0 pad
> > - - txd1-skew-ps : Skew control of TX data 1 pad
> > - - txd2-skew-ps : Skew control of TX data 2 pad
> > - - txd3-skew-ps : Skew control of TX data 3 pad
> > -
> > - - micrel,force-master:
> > - Boolean, force phy to master mode. Only set this option if the phy
> > - reference clock provided at CLK125_NDO pin is used as MAC reference
> > - clock because the clock jitter in slave mode is too high (errata#2).
> > - Attention: The link partner must be configurable as slave otherwise
> > - no link will be established.
> > -
> > -KSZ9131:
> > -LAN8841:
> > -
> > - All skew control options are specified in picoseconds. The increment
> > - step is 100ps. Unlike KSZ9031, the values represent picoseccond delays.
> > - A negative value can be assigned as rxc-skew-psec = <(-100)>;.
> > -
> > - Optional properties:
> > -
> > - Range of the value -700 to 2400, default value 0:
> > -
> > - - rxc-skew-psec : Skew control of RX clock pad
> > - - txc-skew-psec : Skew control of TX clock pad
> > -
> > - Range of the value -700 to 800, default value 0:
> > -
> > - - rxdv-skew-psec : Skew control of RX CTL pad
> > - - txen-skew-psec : Skew control of TX CTL pad
> > - - rxd0-skew-psec : Skew control of RX data 0 pad
> > - - rxd1-skew-psec : Skew control of RX data 1 pad
> > - - rxd2-skew-psec : Skew control of RX data 2 pad
> > - - rxd3-skew-psec : Skew control of RX data 3 pad
> > - - txd0-skew-psec : Skew control of TX data 0 pad
> > - - txd1-skew-psec : Skew control of TX data 1 pad
> > - - txd2-skew-psec : Skew control of TX data 2 pad
> > - - txd3-skew-psec : Skew control of TX data 3 pad
> > -
> > -Examples:
> > -
> > - /* Attach to an Ethernet device with autodetected PHY */
> > - &enet {
> > - rxc-skew-ps = <1800>;
> > - rxdv-skew-ps = <0>;
> > - txc-skew-ps = <1800>;
> > - txen-skew-ps = <0>;
> > - status = "okay";
> > - };
> > -
> > - /* Attach to an explicitly-specified PHY */
> > - mdio {
> > - phy0: ethernet-phy@0 {
> > - rxc-skew-ps = <1800>;
> > - rxdv-skew-ps = <0>;
> > - txc-skew-ps = <1800>;
> > - txen-skew-ps = <0>;
> > - reg = <0>;
> > - };
> > - };
> > - ethernet@70000 {
> > - phy = <&phy0>;
> > - phy-mode = "rgmii-id";
> > - };
> > -
> > -References
> > -
> > - Micrel ksz9021rl/rn Data Sheet, Revision 1.2. Dated 2/13/2014.
> > - http://www.micrel.com/_PDF/Ethernet/datasheets/ksz9021rl-rn_ds.pdf
> > -
> > - Micrel ksz9031rnx Data Sheet, Revision 2.1. Dated 11/20/2014.
> > - http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf
> > -
> > -Notes:
> > -
> > - Note that a previous version of the Micrel ksz9021rl/rn Data Sheet
> > - was missing extended register 106 (transmit data pad skews), and
> > - incorrectly specified the ps per step as 200ps/step instead of
> > - 120ps/step. The latest update to this document reflects the latest
> > - revision of the Micrel specification even though usage in the kernel
> > - still reflects that incorrect document.
> > diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
> > deleted file mode 100644
> > index 01622ce58112e..0000000000000
> > --- a/Documentation/devicetree/bindings/net/micrel.txt
> > +++ /dev/null
> > @@ -1,57 +0,0 @@
> > -Micrel PHY properties.
> > -
> > -These properties cover the base properties Micrel PHYs.
> > -
> > -Optional properties:
> > -
> > - - micrel,led-mode : LED mode value to set for PHYs with configurable LEDs.
> > -
> > - Configure the LED mode with single value. The list of PHYs and the
> > - bits that are currently supported:
> > -
> > - KSZ8001: register 0x1e, bits 15..14
> > - KSZ8041: register 0x1e, bits 15..14
> > - KSZ8021: register 0x1f, bits 5..4
> > - KSZ8031: register 0x1f, bits 5..4
> > - KSZ8051: register 0x1f, bits 5..4
> > - KSZ8081: register 0x1f, bits 5..4
> > - KSZ8091: register 0x1f, bits 5..4
> > - LAN8814: register EP5.0, bit 6
> > -
> > - See the respective PHY datasheet for the mode values.
> > -
> > - - micrel,rmii-reference-clock-select-25-mhz: RMII Reference Clock Select
> > - bit selects 25 MHz mode
> > -
> > - Setting the RMII Reference Clock Select bit enables 25 MHz rather
> > - than 50 MHz clock mode.
> > -
> > - Note that this option is only needed for certain PHY revisions with a
> > - non-standard, inverted function of this configuration bit.
> > - Specifically, a clock reference ("rmii-ref" below) is always needed to
> > - actually select a mode.
> > -
> > - - clocks, clock-names: contains clocks according to the common clock bindings.
> > -
> > - supported clocks:
> > - - KSZ8021, KSZ8031, KSZ8081, KSZ8091: "rmii-ref": The RMII reference
> > - input clock. Used to determine the XI input clock.
> > -
> > - - micrel,fiber-mode: If present the PHY is configured to operate in fiber mode
> > -
> > - Some PHYs, such as the KSZ8041FTL variant, support fiber mode, enabled
> > - by the FXEN boot strapping pin. It can't be determined from the PHY
> > - registers whether the PHY is in fiber mode, so this boolean device tree
> > - property can be used to describe it.
> > -
> > - In fiber mode, auto-negotiation is disabled and the PHY can only work in
> > - 100base-fx (full and half duplex) modes.
> > -
> > - - coma-mode-gpios: If present the given gpio will be deasserted when the
> > - PHY is probed.
> > -
> > - Some PHYs have a COMA mode input pin which puts the PHY into
> > - isolate and power-down mode. On some boards this input is connected
> > - to a GPIO of the SoC.
> > -
> > - Supported on the LAN8814.
> > diff --git a/Documentation/devicetree/bindings/net/micrel.yaml b/Documentation/devicetree/bindings/net/micrel.yaml
> > new file mode 100644
> > index 0000000000000..f48e9b9120ca0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/micrel.yaml
> > @@ -0,0 +1,527 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/micrel.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Micrel KSZ series PHYs and switches
> > +
> > +maintainers:
> > + - Andrew Lunn <andrew@lunn.ch>
> > + - Stefan Eichenberger <eichest@gmail.com>
> > +
> > +description: |
> > + The Micrel KSZ series contains different network phys and switches.
> > +
> > + Some boards require special tuning values, particularly when it comes to
> > + clock delays. You can specify clock delay values in the PHY OF device node.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - ethernet-phy-id000e.7237 # KSZ8873MLL
> > + - ethernet-phy-id0022.1430 # KSZ886X
> > + - ethernet-phy-id0022.1435 # KSZ8863
> > + - ethernet-phy-id0022.1510 # KSZ8041
> > + - ethernet-phy-id0022.1537 # KSZ8041RNLI
> > + - ethernet-phy-id0022.1550 # KSZ8051
> > + - ethernet-phy-id0022.1555 # KSZ8021
> > + - ethernet-phy-id0022.1556 # KSZ8031
> > + - ethernet-phy-id0022.1560 # KSZ8081, KSZ8091
> > + - ethernet-phy-id0022.1570 # KSZ8061
> > + - ethernet-phy-id0022.1610 # KSZ9021
> > + - ethernet-phy-id0022.1611 # KSZ9021RLRN
> > + - ethernet-phy-id0022.161a # KSZ8001
> > + - ethernet-phy-id0022.1620 # KSZ9031
> > + - ethernet-phy-id0022.1631 # KSZ9477
> > + - ethernet-phy-id0022.1640 # KSZ9131
> > + - ethernet-phy-id0022.1650 # LAN8841
> > + - ethernet-phy-id0022.1660 # LAN8814
> > + - ethernet-phy-id0022.1670 # LAN8804
> > + - ethernet-phy-id0022.1720 # KS8737
> > +
> > +allOf:
> > + - $ref: ethernet-phy.yaml#
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: ethernet-phy-id0022.1510
> > + then:
> > + properties:
> > + micrel,fiber-mode:
> > + type: boolean
> > + description: |
> > + If present the PHY is configured to operate in fiber mode.
> > +
> > + The KSZ8041FTL variant, supports fiber mode, enabled by the FXEN
> > + boot strapping pin. It can't be determined from the PHY registers
> > + whether the PHY is in fiber mode, so this boolean device tree
> > + property can be used to describe it.
> > +
> > + In fiber mode, auto-negotiation is disabled and the PHY can only work in
>
> Wrap at 80.
>
Thanks, I will fix that.
> > + 100base-fx (full and half duplex) modes.
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - ethernet-phy-id0022.1555
> > + - ethernet-phy-id0022.1556
> > + - ethernet-phy-id0022.1560
> > + then:
> > + properties:
> > + clock-names:
> > + const: rmii-ref
> > + description: |
> > + supported clocks:
> > + - The RMII reference input clock. Used to determine the XI
> > + input clock.
> > + micrel,rmii-reference-clock-select-25-mhz:
> > + type: boolean
> > + description: |
> > + RMII Reference Clock Select bit selects 25 MHz mode
> > +
> > + Setting the RMII Reference Clock Select bit enables 25 MHz rather
> > + than 50 MHz clock mode.
> > +
> > + Note that this option in only needed for certain PHY revisions with a
> > + non-standard, inverted function of this configuration bit.
> > + Specifically, a clock reference ("rmii-ref") is always needed to
> > + actually select a mode.
>
> Sounds like a dependency:
>
> dependentRequired:
> micrel,rmii-reference-clock-select-25-mhz: [ clock-names ]
>
Thanks, I will add that.
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: ethernet-phy-id0022.1660
> > + then:
> > + properties:
> > + coma-mode-gpios:
> > + maxItems: 1
> > + description: |
> > + If present the given gpio will be deasserted when the PHY is probed.
> > +
> > + Some PHYs have a COMA mode input pin which puts the PHY into
> > + isolate and power-down mode. On some boards this input is connected
> > + to a GPIO of the SoC.
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - ethernet-phy-id0022.1510
> > + - ethernet-phy-id0022.1555
> > + - ethernet-phy-id0022.1556
> > + - ethernet-phy-id0022.1550
> > + - ethernet-phy-id0022.1560
> > + - ethernet-phy-id0022.161a
> > + - ethernet-phy-id0022.1660
> > + then:
> > + properties:
> > + micrel,led-mode:
> > + description: |
> > + LED mode value to set for PHYs with configurable LEDs.
> > +
> > + Configure the LED mode with single value. The list of PHYs and the
> > + bits that are currently supported:
> > +
> > + KSZ8001: register 0x1e, bits 15..14
> > + KSZ8041: register 0x1e, bits 15..14
> > + KSZ8021: register 0x1f, bits 5..4
> > + KSZ8031: register 0x1f, bits 5..4
> > + KSZ8051: register 0x1f, bits 5..4
> > + KSZ8081: register 0x1f, bits 5..4
> > + KSZ8091: register 0x1f, bits 5..4
> > + LAN8814: register EP5.0, bit 6
> > +
> > + See the respective PHY datasheet for the mode values.
> > + minimum: 0
> > + maximum: 3
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: ethernet-phy-id0022.1620
> > + then:
> > + properties:
> > + enable-edpd:
> > + type: boolean
> > + description:
> > + Enable Energy Detect Power Down mode. Reduces power consumption when the
> > + link is down.
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - ethernet-phy-id0022.1555
> > + - ethernet-phy-id0022.1556
> > + - ethernet-phy-id0022.1560
> > + then:
> > + properties:
> > + clock-names:
> > + const: rmii-ref
> > + description: |
> > + supported clocks:
> > + - The RMII reference input clock. Used to determine the XI
> > + input clock.
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - ethernet-phy-id0022.1610
> > + - ethernet-phy-id0022.1611
> > + then:
> > + properties:
> > + rxc-skew-ps:
> > + description: |
> > + Skew control of RXC pad (picoseconds). A value of 0 equals to a
> > + skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + txc-skew-ps:
> > + description: |
> > + Skew control of TXC pad (picoseconds). A value of 0 equals to a
> > + skew of -840ps. Increments of 200ps are allowed.
>
> multipleOf: 200
I will add that to all relevant entries.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + rxdv-skew-ps:
> > + description: |
> > + Skew control of RX CTL pad (picoseconds). A value of 0 equals to a
> > + skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + txen-skew-ps:
> > + description: |
> > + Skew control of TX CTL pad (picoseconds). A value of 0 equals to a
> > + skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + rxd0-skew-ps:
> > + description: |
> > + Skew control of RX data 0 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + rxd1-skew-ps:
> > + description: |
> > + Skew control of RX data 1 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + rxd2-skew-ps:
> > + description: |
> > + Skew control of RX data 2 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + rxd3-skew-ps:
> > + description: |
> > + Skew control of RX data 3 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + txd0-skew-ps:
> > + description: |
> > + Skew control of TX data 0 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + txd1-skew-ps:
> > + description: |
> > + Skew control of TX data 1 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + txd2-skew-ps:
> > + description: |
> > + Skew control of TX data 2 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
> > + txd3-skew-ps:
> > + description: |
> > + Skew control of TX data 3 pad (picoseconds). A value of 0 equals to
> > + a skew of -840ps. Increments of 200ps are allowed.
> > +
> > + The actual increment on the chip is 120ps ranging from -840ps to
> > + 960ps, this mismatch comes from a documentation error before
> > + datasheet revision 1.2 (Feb 2014):
> > + minimum: 0
> > + maximum: 3000
> > + default: 1400
>
> Since it is the same constraints, you can shorten all these with a
> pattern:
>
> patternProperties:
> '^([rt]xd[0-3]|[rt]xc|rxdv|txen)-skew-ps$':
>
Thanks, I will do that.
> > + else:
> > + if:
>
> Avoid nested if/then schemas if possible. Doesn't look like it is
> necessary here.
Yes you are right, it is not necessary.
> > + properties:
> > + compatible:
> > + contains:
> > + const: ethernet-phy-id0022.1620
> > + then:
> > + properties:
> > + rxc-skew-ps:
> > + description: |
> > + Skew control of RXC pad (picoseconds). A value of 0 equals to a skew
> > + of -900ps. Increments of 60ps are allowed.
>
> multipleOf: 60
>
I will add that for all relevant entries.
> > + minimum: 0
> > + maximum: 1860
> > + default: 900
> > + txc-skew-ps:
> > + description: |
> > + Skew control of TXC pad (picoseconds). A value of 0 equals to a skew
> > + of -900ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 1860
> > + default: 900
> > + rxdv-skew-ps:
> > + description: |
> > + Skew control of RX CTL pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + txen-skew-ps:
> > + description: |
> > + Skew control of TX CTL pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + rxd0-skew-ps:
> > + description: |
> > + Skew control of RX data 0 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + rxd1-skew-ps:
> > + description: |
> > + Skew control of RX data 1 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + rxd2-skew-ps:
> > + description: |
> > + Skew control of RX data 2 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + rxd3-skew-ps:
> > + description: |
> > + Skew control of RX data 3 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + txd0-skew-ps:
> > + description: |
> > + Skew control of TX data 0 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + txd1-skew-ps:
> > + description: |
> > + Skew control of TX data 1 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + txd2-skew-ps:
> > + description: |
> > + Skew control of TX data 2 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + txd3-skew-ps:
> > + description: |
> > + Skew control of TX data 3 pad (picoseconds). A value of 0 equals to a
> > + skew of -420ps. Increments of 60ps are allowed.
> > + minimum: 0
> > + maximum: 900
> > + default: 420
> > + else:
> > + if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - ethernet-phy-id0022.1640
> > + - ethernet-phy-id0022.1660
> > + then:
> > + properties:
> > + rxc-skew-psec:
>
> These are not a standard unit-suffix, so they need a type $ref. That
> should be a warning, but probably isn't since these are underneeth an
> if/then schema.
>
The problem is that I get this error when I try to set the ref. That's
also why I added the additonal example. I think they disappear if I
would set the properties at the top level though as suggested by you.
$ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/micrel.yaml
make[1]: Entering directory '...'
SCHEMA Documentation/devicetree/bindings/processed-schema.json
CHKDT ../Documentation/devicetree/bindings
LINT ../Documentation/devicetree/bindings
DTEX Documentation/devicetree/bindings/net/micrel.example.dts
DTC [C] Documentation/devicetree/bindings/net/micrel.example.dtb
Documentation/devicetree/bindings/net/micrel.example.dtb: ethernet-phy@9 (ethernet-phy-id0022.1640): rxc-skew-psec: [4294967196] is not of type 'integer'
from schema $id: http://devicetree.org/schemas/net/micrel.yaml
Documentation/devicetree/bindings/net/micrel.example.dtb: ethernet-phy@9 (ethernet-phy-id0022.1640): Unevaluated properties are not allowed ('rxc-skew-psec', 'txc-skew-psec' were unexpected)
from schema $id: http://devicetree.org/schemas/net/micrel.yaml
> In general, the rule is don't define properties in if/then schemas.
> Define them at the top level and then disallow them in if/then schemas
> for specific compatibles. There's also a judgement call of when to split
> bindings to separate files based on how long the if/then schemas are
> compared to the top-level. I think this is well past that though using
> patternProperties helps a lot. I think at least the 1640 and 1660 should
> be split given the custom skew props.
I think for most properties it should be doable to define them at the
top level and disallow them for all other compatibles. However, I was
struggling with the -ps properties, because they have different
constratints and descriptions based on the compatible. I will see what I
can do there.
I will also try to split the micrel.yaml again into multiple files in
the next version.
Regards,
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-15 14:03 ` Rob Herring
@ 2025-12-17 9:58 ` Stefan Eichenberger
2025-12-17 12:21 ` Stefan Eichenberger
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-17 9:58 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, krzk+dt, conor+dt,
hkallweit1, linux, geert+renesas, ben.dooks, netdev, devicetree,
linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Mon, Dec 15, 2025 at 08:03:30AM -0600, Rob Herring wrote:
> On Fri, Dec 12, 2025 at 09:46:17AM +0100, Stefan Eichenberger wrote:
> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> >
> > Add a property to activate a Micrel PHY feature that keeps the preamble
> > enabled before the SFD (Start Frame Delimiter) is transmitted.
> >
> > This allows to workaround broken Ethernet controllers as found on the
> > NXP i.MX8MP. Specifically, errata ERR050694 that states:
> > ENET_QOS: MAC incorrectly discards the received packets when Preamble
> > Byte does not precede SFD or SMD.
>
> It doesn't really work right if you have to change the DT to work-around
> a quirk in the kernel. You should have all the information needed
> already in the DT. The compatible string for the i.MX8MP ethernet
> controller is not sufficient?
Is doing something like this acceptable in a phy driver?
if (of_machine_is_compatible("fsl,imx8mp")) {
...
}
That would be a different option, rather than having to add a new DT
property. Unfortunately, the workaround affects the PHY rather than the
MAC driver. This is why we considered adding a DT property.
> >
> > The bit which disables this feature is not documented in the datasheet
> > from Micrel, but has been found by NXP and Micrel following this
> > discussion:
> > https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032
> >
> > It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
> > 10MBit. Withouth this property set, no packets are received. With this
> > property set, reception works fine.
>
> What's the impact of just unconditionally setting this bit? Seems like
> any impact would be minimal given 10MBit is probably pretty rare now.
In theory it shouldn't have any negative impact. According to the
Errata:
The IEEE 802.3 standard states that, in MII/GMII modes, the byte
preceding the SFD (0xD5), SMD-S (0xE6,0x4C, 0x7F, or 0xB3), or SMD-C
(0x61, 0x52, 0x9E, or 0x2A) byte can be a non-PREAMBLE byte or there
can be no preceding preamble byte. The MAC receiver must successfully
receive a packet without any preamble(0x55) byte preceding the SFD,
SMD-S, or SMD-C byte.
However, since Micrel didn't document this bit and because the driver is
already older, we are afraid to break something for other users if we
enable it unconditionally.
Regards,
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-17 9:58 ` Stefan Eichenberger
@ 2025-12-17 12:21 ` Stefan Eichenberger
2025-12-17 13:55 ` Rob Herring
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-17 12:21 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, krzk+dt, conor+dt,
hkallweit1, linux, geert+renesas, ben.dooks, netdev, devicetree,
linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Wed, Dec 17, 2025 at 10:58:54AM +0100, Stefan Eichenberger wrote:
> On Mon, Dec 15, 2025 at 08:03:30AM -0600, Rob Herring wrote:
> > On Fri, Dec 12, 2025 at 09:46:17AM +0100, Stefan Eichenberger wrote:
> > > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > >
> > > Add a property to activate a Micrel PHY feature that keeps the preamble
> > > enabled before the SFD (Start Frame Delimiter) is transmitted.
> > >
> > > This allows to workaround broken Ethernet controllers as found on the
> > > NXP i.MX8MP. Specifically, errata ERR050694 that states:
> > > ENET_QOS: MAC incorrectly discards the received packets when Preamble
> > > Byte does not precede SFD or SMD.
> >
> > It doesn't really work right if you have to change the DT to work-around
> > a quirk in the kernel. You should have all the information needed
> > already in the DT. The compatible string for the i.MX8MP ethernet
> > controller is not sufficient?
>
> Is doing something like this acceptable in a phy driver?
> if (of_machine_is_compatible("fsl,imx8mp")) {
> ...
> }
>
> That would be a different option, rather than having to add a new DT
> property. Unfortunately, the workaround affects the PHY rather than the
> MAC driver. This is why we considered adding a DT property.
Francesco made a good point about this. The i.MX8MP has two MACs, but
only one of them is affected. Therefore, checking the machine's
compatible string would not be correct. As far as I know, checking the
MAC's compatible string from within the PHY driver is also not good
practice, is it?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-17 12:21 ` Stefan Eichenberger
@ 2025-12-17 13:55 ` Rob Herring
2025-12-17 14:30 ` Stefan Eichenberger
0 siblings, 1 reply; 17+ messages in thread
From: Rob Herring @ 2025-12-17 13:55 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, krzk+dt, conor+dt,
hkallweit1, linux, geert+renesas, ben.dooks, netdev, devicetree,
linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Wed, Dec 17, 2025 at 01:21:19PM +0100, Stefan Eichenberger wrote:
> On Wed, Dec 17, 2025 at 10:58:54AM +0100, Stefan Eichenberger wrote:
> > On Mon, Dec 15, 2025 at 08:03:30AM -0600, Rob Herring wrote:
> > > On Fri, Dec 12, 2025 at 09:46:17AM +0100, Stefan Eichenberger wrote:
> > > > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > > >
> > > > Add a property to activate a Micrel PHY feature that keeps the preamble
> > > > enabled before the SFD (Start Frame Delimiter) is transmitted.
> > > >
> > > > This allows to workaround broken Ethernet controllers as found on the
> > > > NXP i.MX8MP. Specifically, errata ERR050694 that states:
> > > > ENET_QOS: MAC incorrectly discards the received packets when Preamble
> > > > Byte does not precede SFD or SMD.
> > >
> > > It doesn't really work right if you have to change the DT to work-around
> > > a quirk in the kernel. You should have all the information needed
> > > already in the DT. The compatible string for the i.MX8MP ethernet
> > > controller is not sufficient?
> >
> > Is doing something like this acceptable in a phy driver?
> > if (of_machine_is_compatible("fsl,imx8mp")) {
> > ...
> > }
> >
> > That would be a different option, rather than having to add a new DT
> > property. Unfortunately, the workaround affects the PHY rather than the
> > MAC driver. This is why we considered adding a DT property.
>
> Francesco made a good point about this. The i.MX8MP has two MACs, but
> only one of them is affected. Therefore, checking the machine's
> compatible string would not be correct. As far as I know, checking the
> MAC's compatible string from within the PHY driver is also not good
> practice, is it?
It's not great, but probably what you need to do. The 2 MACs are the
same (compatible) or different? As that only works if they are
different. I suppose you need to only check the MAC the PHY is connected
to.
I think the ideal implementation would be the MAC driver calling some
phy API to apply the quirk, and then that gets passed on to the phy
driver. Surely this isn't the first case of a MAC-PHY combination
needing to go fiddle with some special setting.
Rob
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-17 13:55 ` Rob Herring
@ 2025-12-17 14:30 ` Stefan Eichenberger
2025-12-17 17:04 ` Andrew Lunn
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Eichenberger @ 2025-12-17 14:30 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, krzk+dt, conor+dt,
hkallweit1, linux, geert+renesas, ben.dooks, netdev, devicetree,
linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
On Wed, Dec 17, 2025 at 07:55:19AM -0600, Rob Herring wrote:
> On Wed, Dec 17, 2025 at 01:21:19PM +0100, Stefan Eichenberger wrote:
> > On Wed, Dec 17, 2025 at 10:58:54AM +0100, Stefan Eichenberger wrote:
> > > On Mon, Dec 15, 2025 at 08:03:30AM -0600, Rob Herring wrote:
> > > > On Fri, Dec 12, 2025 at 09:46:17AM +0100, Stefan Eichenberger wrote:
> > > > > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > > > >
> > > > > Add a property to activate a Micrel PHY feature that keeps the preamble
> > > > > enabled before the SFD (Start Frame Delimiter) is transmitted.
> > > > >
> > > > > This allows to workaround broken Ethernet controllers as found on the
> > > > > NXP i.MX8MP. Specifically, errata ERR050694 that states:
> > > > > ENET_QOS: MAC incorrectly discards the received packets when Preamble
> > > > > Byte does not precede SFD or SMD.
> > > >
> > > > It doesn't really work right if you have to change the DT to work-around
> > > > a quirk in the kernel. You should have all the information needed
> > > > already in the DT. The compatible string for the i.MX8MP ethernet
> > > > controller is not sufficient?
> > >
> > > Is doing something like this acceptable in a phy driver?
> > > if (of_machine_is_compatible("fsl,imx8mp")) {
> > > ...
> > > }
> > >
> > > That would be a different option, rather than having to add a new DT
> > > property. Unfortunately, the workaround affects the PHY rather than the
> > > MAC driver. This is why we considered adding a DT property.
> >
> > Francesco made a good point about this. The i.MX8MP has two MACs, but
> > only one of them is affected. Therefore, checking the machine's
> > compatible string would not be correct. As far as I know, checking the
> > MAC's compatible string from within the PHY driver is also not good
> > practice, is it?
>
> It's not great, but probably what you need to do. The 2 MACs are the
> same (compatible) or different? As that only works if they are
> different. I suppose you need to only check the MAC the PHY is connected
> to.
>
> I think the ideal implementation would be the MAC driver calling some
> phy API to apply the quirk, and then that gets passed on to the phy
> driver. Surely this isn't the first case of a MAC-PHY combination
> needing to go fiddle with some special setting.
I was also hoping to find something like that, but I couldn't really
find it. However, I will try looking in that direction. At least we can
identify the broken MAC via the compatible string of the MAC driver, as
they use two different compatibles: 'fsl,imx8mp-fec' (fine) and
'nxp,imx8mp-dwmac-eqos' (affected by the errata).
Regards,
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd
2025-12-17 14:30 ` Stefan Eichenberger
@ 2025-12-17 17:04 ` Andrew Lunn
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Lunn @ 2025-12-17 17:04 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: Rob Herring, andrew+netdev, davem, edumazet, kuba, pabeni,
krzk+dt, conor+dt, hkallweit1, linux, geert+renesas, ben.dooks,
netdev, devicetree, linux-kernel, francesco.dolcini, rafael.beims,
Stefan Eichenberger
> > I think the ideal implementation would be the MAC driver calling some
> > phy API to apply the quirk, and then that gets passed on to the phy
> > driver. Surely this isn't the first case of a MAC-PHY combination
> > needing to go fiddle with some special setting.
>
> I was also hoping to find something like that, but I couldn't really
> find it. However, I will try looking in that direction. At least we can
> identify the broken MAC via the compatible string of the MAC driver, as
> they use two different compatibles: 'fsl,imx8mp-fec' (fine) and
> 'nxp,imx8mp-dwmac-eqos' (affected by the errata).
Maybe see if you can use phy_register_fixup_for_id().
Andrew
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2025-12-17 17:05 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-12 8:46 [PATCH net-next v1 0/3] Convert Micrel bindings to YAML, add keep-preamble-before-sfd Stefan Eichenberger
2025-12-12 8:46 ` [PATCH net-next v1 1/3] dt-bindings: net: micrel: Convert to YAML schema Stefan Eichenberger
2025-12-12 10:29 ` Rob Herring (Arm)
2025-12-12 14:51 ` Stefan Eichenberger
2025-12-12 14:16 ` Simon Horman
2025-12-12 14:52 ` Stefan Eichenberger
2025-12-15 14:37 ` Rob Herring
2025-12-17 9:41 ` Stefan Eichenberger
2025-12-12 8:46 ` [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add keep-preamble-before-sfd Stefan Eichenberger
2025-12-12 10:29 ` Rob Herring (Arm)
2025-12-15 14:03 ` Rob Herring
2025-12-17 9:58 ` Stefan Eichenberger
2025-12-17 12:21 ` Stefan Eichenberger
2025-12-17 13:55 ` Rob Herring
2025-12-17 14:30 ` Stefan Eichenberger
2025-12-17 17:04 ` Andrew Lunn
2025-12-12 8:46 ` [PATCH net-next v1 3/3] net: phy: micrel: Add keep-preamble-before-sfd property Stefan Eichenberger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).