.../bindings/net/dapu,dap8211r.yaml | 62 ++++++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/net/phy/Kconfig | 9 + drivers/net/phy/Makefile | 1 + drivers/net/phy/dap8211r.c | 206 ++++++++++++++++++ 5 files changed, 280 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/dapu,dap8211r.yaml create mode 100644 drivers/net/phy/dap8211r.c
Hello,
This series adds support for the DAPU Telecom DAP8211R(I) Gigabit
Ethernet PHY, commonly used in enterprise and industrial networking
applications. The PHY supports 10/100/1000 Mbps operation with RGMII
interface and includes features such as IEEE 802.3az Energy Efficient
Ethernet, IEEE 1588 SyncE.
The driver implements extended register access via indirect addressing
(registers 0x1E/0x1F) and provides comprehensive device tree support
for RGMII delay configuration. The rx-internal-delay-ps and
tx-internal-delay-ps properties allow precise tuning of clock delays
in 150 ps steps from 0 to 2250 ps.
This PHY is used on the NDA platform with 1G Ethernet tile and has
been tested on that hardware with successful link establishment and
RGMII delay tuning.
$ make dt_binding_check DT_SCHEMA_FILES=dapu,dap8211r.yaml
SCHEMA Documentation/devicetree/bindings/processed-schema.json
CHKDT ./Documentation/devicetree/bindings
LINT ./Documentation/devicetree/bindings
STYLE ./Documentation/devicetree/bindings
DTEX Documentation/devicetree/bindings/net/dapu,dap8211r.example.dts
DTC [C] Documentation/devicetree/bindings/net/dapu,dap8211r.example.dtb
$ yamllint Documentation/devicetree/bindings/net/dapu,dap8211r.yaml
$ grep -i "dap8211r" Documentation/devicetree/bindings/processed-schema.json
"http://devicetree.org/schemas/net/dapu,dap8211r.yaml": {
"$filename": "/home/a-shimko/patchwork/linux/Documentation/devicetree/bindings/net/dapu,dap8211r.yaml",
"$id": "http://devicetree.org/schemas/net/dapu,dap8211r.yaml#",
"title": "DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY",
Working with xgmac.
Board side:
$ arping -I eth0 192.168.5.100
ARPING 192.168.5.1 from 192.168.5.100 eth0
Unicast reply from 192.168.5.1 [board.mac.addr] 8.543ms
Unicast reply from 192.168.5.1 [board.mac.addr] 3.295ms
Unicast reply from 192.168.5.1 [board.mac.addr] 4.301ms
Unicast reply from 192.168.5.1 [board.mac.addr] 4.096ms
Unicast reply from 192.168.5.1 [board.mac.addr] 2.872ms
...
Unfortunately, there is a dependence on the axibus speed here
$ iperf3 -c 192.168.5.1
Connecting to host 192.168.5.1, port 5201
[ 5] local 192.168.5.100 port 58936 connected to 192.168.5.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 7.88 MBytes 65.8 Mbits/sec 0 150 KBytes
[ 5] 1.00-2.00 sec 8.50 MBytes 71.4 Mbits/sec 0 165 KBytes
[ 5] 2.00-3.00 sec 8.25 MBytes 69.2 Mbits/sec 0 165 KBytes
[ 5] 3.00-4.01 sec 8.50 MBytes 71.1 Mbits/sec 0 165 KBytes
[ 5] 4.01-5.00 sec 8.38 MBytes 70.3 Mbits/sec 0 165 KBytes
[ 5] 5.00-6.00 sec 8.50 MBytes 71.5 Mbits/sec 0 165 KBytes
[ 5] 6.00-7.01 sec 8.62 MBytes 72.0 Mbits/sec 0 174 KBytes
[ 5] 7.01-8.00 sec 8.62 MBytes 72.8 Mbits/sec 0 174 KBytes
[ 5] 8.00-9.00 sec 8.62 MBytes 72.2 Mbits/sec 0 174 KBytes
[ 5] 9.00-10.04 sec 8.62 MBytes 69.9 Mbits/sec 0 174 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 84.6 MBytes 70.7 Mbits/sec 0 sender
[ 5] 0.00-10.12 sec 84.8 MBytes 70.3 Mbits/sec receiveriperf Done.
$ ethtool -t eth0
...
The test extra info:
1. MAC Loopback 0
2. MAC Loopback (diff. queues) 0
3. PHY Loopback 0
...
ELP side:
...
17:29:11.974973 ARP, Reply ELP is-at elp.mac.addr(oui Unknown), length 28
17:29:12.975199 ARP, Request who-has ELP tell 192.168.5.100, length 46
17:29:12.975217 ARP, Reply ELP is-at elp.mac.addr(oui Unknown), length 28
17:29:13.975022 ARP, Request who-has ELP tell 192.168.5.100, length 46
17:29:13.975035 ARP, Reply ELP is-at elp.mac.addr(oui Unknown), length 28
17:29:14.974837 ARP, Request who-has ELP tell 192.168.5.100, length 46
17:29:14.974849 ARP, Reply ELP is-at elp.mac.addr(oui Unknown), length 28
17:29:15.975026 ARP, Request who-has ELP tell 192.168.5.100, length 46
...
Accepted connection from 192.168.5.100, port 58932
[ 5] local 192.168.5.1 port 5201 connected to 192.168.5.100 port 58936
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 7.12 MBytes 59.7 Mbits/sec
[ 5] 1.00-2.00 sec 8.50 MBytes 71.3 Mbits/sec
[ 5] 2.00-3.00 sec 8.50 MBytes 71.3 Mbits/sec
[ 5] 3.00-4.00 sec 8.38 MBytes 70.3 Mbits/sec
[ 5] 4.00-5.00 sec 8.50 MBytes 71.3 Mbits/sec
[ 5] 5.00-6.00 sec 8.38 MBytes 70.3 Mbits/sec
[ 5] 6.00-7.00 sec 8.62 MBytes 72.4 Mbits/sec
[ 5] 7.00-8.00 sec 8.62 MBytes 72.3 Mbits/sec
[ 5] 8.00-9.00 sec 8.62 MBytes 72.4 Mbits/sec
[ 5] 9.00-10.00 sec 8.62 MBytes 72.4 Mbits/sec
[ 5] 10.00-10.12 sec 896 KBytes 62.3 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.12 sec 84.8 MBytes 70.3 Mbits/sec receiver
DTS node example:
ðernet_1g_tile {
...
phy-mode = "rgmii-rxid";
phy-handle = <&phy1>;
...
mdio: mdio {
phy1: ethernet-phy@1 {
...
compatible = "ethernet-phy-id0008.011b";
rx-internal-delay-ps = <1050>;
...
};
};
};
--
Best regards,
Artem Shimko
ChangeLog:
v4 --> v5
- Add Guangdong Dapu to vendor-prefixes
- Remov unimplemented features from Kconfig help text
- Fix inconsistent handling of RGMII delay properties
- Add hardware-specified initial delay values for RX (0) and TX (1)
v3 --> v4
- Drop dapu,tx-inverted-clk (vendor-specific property removed)
- Fix driver behavior in relation to rgmii modes
- Apply software reset before RGMII register writes
v2 --> v3
- Use phy_get_internal_delay() for delay validation and selection
- Add poll timeout for reset using read_poll_timeout()
v1 --> v2
- Drop debugfs interface
- Simplify RGMII delay reading logic using of_property_read_u32()
- Fix missing newline at end of dapu,dap8211r.yaml (yamllint error)
- Simplify delay property description in DT binding
- Rename tx-inverted-clk to dapu,tx-inverted-clk (vendor prefix)
- Replace enum with multipleOf + maximum for delay validation
- Fix compatible string and tx-internal-delay-ps value in example
- Remove rounding logic, return -EINVAL for unsupported delay values
- Respect DT delay properties for all RGMII modes
- Add polling for self-clearing reset bit instead of fixed sleep
- Remove unused packet generator macros (DAP8211R_PKGC5 and related)
Artem Shimko (3):
dt-bindings: vendor-prefixes: add Guangdong Dapu Telecom Co., Ltd.
dt-bindings: net: add DAPU Telecom DAP8211R(I) PHY binding
net: phy: add DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY driver
.../bindings/net/dapu,dap8211r.yaml | 62 ++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
drivers/net/phy/Kconfig | 9 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/dap8211r.c | 206 ++++++++++++++++++
5 files changed, 280 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dapu,dap8211r.yaml
create mode 100644 drivers/net/phy/dap8211r.c
--
2.43.0
> DTS node example:
> ðernet_1g_tile {
> ...
> phy-mode = "rgmii-rxid";
> phy-handle = <&phy1>;
> ...
>
> mdio: mdio {
> phy1: ethernet-phy@1 {
> ...
> compatible = "ethernet-phy-id0008.011b";
> rx-internal-delay-ps = <1050>;
Is this a random example, or what you are actually using?
Andrew
Hi Andrew, On Tue, Aug 4, 2026 at 5:32 AM Andrew Lunn <andrew@lunn.ch> wrote: > Is this a random example, or what you are actually using? This is actually the configuration we're using on our hardware. -- Best regards, Artem
On Tue, Aug 04, 2026 at 10:03:30AM +0300, Artem Shimko wrote:
> Hi Andrew,
>
> On Tue, Aug 4, 2026 at 5:32 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > Is this a random example, or what you are actually using?
> This is actually the configuration we're using on our
> hardware.
phy-mode = "rgmii-rxid";
phy-handle = <&phy1>;
...
mdio: mdio {
phy1: ethernet-phy@1 {
...
compatible = "ethernet-phy-id0008.011b";
rx-internal-delay-ps = <1050>;
That is a very odd setup, half the 2ns delay the RGMII standard asks
for? Do you have an explanation for this?
Have you verified the writing of the delays in the PHY register don't
have a 1 bit shift error?
Andrew
Hi Andrew, On Tue, Aug 4, 2026 at 4:32 PM Andrew Lunn <andrew@lunn.ch> wrote: > That is a very odd setup, half the 2ns delay the RGMII standard asks > for? Do you have an explanation for this? I think this is a poor example, as the delay is due to clock inversion due to a mismatch in the PCB parameters. Perhaps I should use a more standard delay as an example as <1950>. > Have you verified the writing of the delays in the PHY register don't > have a 1 bit shift error? I verified them by reading back the RGMII_CON register (0xA003) after configuration, and the values are being applied correctly with no bit-shift error. Just my failed in example value =) Thank you for your time and review. -- Best regards, Artem
On Tue, Aug 04, 2026 at 05:08:49PM +0300, Artem Shimko wrote: > Hi Andrew, > > On Tue, Aug 4, 2026 at 4:32 PM Andrew Lunn <andrew@lunn.ch> wrote: > > That is a very odd setup, half the 2ns delay the RGMII standard asks > > for? Do you have an explanation for this? > I think this is a poor example, as the delay is due to clock inversion > due to a mismatch in the PCB parameters. Ah! Another things to explain with a comment... Andrew
Hi Andrew, On Tue, Aug 4, 2026 at 5:41 PM Andrew Lunn <andrew@lunn.ch> wrote: > Another things to explain with a comment... If you don't mind, I'll simply update the DT binding example to use the standard 1950 ps value, instead of the platform-specific 1050 ps value. This should avoid confusion for other developers. I think it's more appropriate. -- Best regards, Artem
© 2016 - 2026 Red Hat, Inc.