.../bindings/net/dapu,dap8211r.yaml | 73 +++++++ drivers/net/phy/Kconfig | 10 + drivers/net/phy/Makefile | 1 + drivers/net/phy/dap8211r.c | 191 ++++++++++++++++++ 4 files changed, 275 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, and an internal packet generator for
diagnostics.
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. The optional dapu,tx-inverted-clk
flag enables 180-degree TX clock phase shift for boards where signal
integrity or MAC requirements necessitate clock inversion.
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.
Due to the specific PCB layout of the platform and FPGA configuration,
the default RGMII timing configuration was insufficient, causing packet
loss during normal operation. Tuning the TX/RX line delays and enabling
clock inversion restored proper signal timing, resulting in zero packet
loss and stable link performance.
$ 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
grep -i "dap8211r" Documentation/devicetree/bindings/processed-schema.json
chema.json
"http://devicetree.org/schemas/net/dapu,dap8211r.yaml": {
"$filename": ".../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>;
dapu,tx-inverted-clk;
...
};
};
};
--
Best regards,
Artem Shimko
ChangeLog:
v3:
- Use phy_get_internal_delay() for delay validation and selection
- Add poll timeout for reset using read_poll_timeout()
v2:
- https://lore.kernel.org/all/20260716113805.593215-1-a.shimko.dev@gmail.com/T/#t
v1:
- https://lore.kernel.org/all/20260713131223.279555-1-a.shimko.dev@gmail.com/T/#t
Artem Shimko (2):
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 | 73 +++++++
drivers/net/phy/Kconfig | 10 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/dap8211r.c | 191 ++++++++++++++++++
4 files changed, 275 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dapu,dap8211r.yaml
create mode 100644 drivers/net/phy/dap8211r.c
--
2.43.0
Hi Artem, Please slow down a bit, you need to wait at least 24h between patch submissions : https://docs.kernel.org/process/maintainer-netdev.html On 7/16/26 19:33, Artem Shimko wrote: > 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, and an internal packet generator for > diagnostics. > > 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. The optional dapu,tx-inverted-clk > flag enables 180-degree TX clock phase shift for boards where signal > integrity or MAC requirements necessitate clock inversion. +Zhi Li This isn't the first time we see clock inversion being used to overcome RGMII timing issues, for setups that have too big of an internal delay, see [1]. I'm wondering if we should either reject this on the account that this is bad HW design, or embrace that in which case it would probably be a good idea to come-up with more generic ways to handle that. This patch proposes the "dapu,tx-inverted-clk" property, while Zhi Li's patch has a dedicated compatible for that (and inversion is on RX, on the MAC side) If clock inversion is a common thing for MAC and PHYs to be able to do, should we add some way of representing the RGMII delays that are introduced by the HW itself in DT, and let drivers figure-out from that if they need to resort to clock inversion to align clk and data correctly ? Phylib could maybe even provide helpers for that ? [1] : https://lore.kernel.org/netdev/20260707064159.1299-1-lizhi2@eswincomputing.com/ Maxime
Hi Maxime, I could suggest a couple options for how I should handle the driver: 1. Recognizing that this is a problem with the PCS layer, I can remove the inversion from the patch (but add it to my working project as a separate, non-upstream patch). This way, we'll just leave the delays setting in the driver, which is fairly common among driver users. 2. Leave the inversion in the driver until some future common framework solution is developed, and then adapt this part of the driver to that solution. I'd be happy to help develop/modify that framework =). A packet generator could also be added to it. -- Best regards, Artem On Thu, Jul 16, 2026 at 9:11 PM Maxime Chevallier <maxime.chevallier@bootlin.com> wrote: > > Hi Artem, > > Please slow down a bit, you need to wait at least 24h between patch > submissions : > > https://docs.kernel.org/process/maintainer-netdev.html > > On 7/16/26 19:33, Artem Shimko wrote: > > 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, and an internal packet generator for > > diagnostics. > > > > 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. The optional dapu,tx-inverted-clk > > flag enables 180-degree TX clock phase shift for boards where signal > > integrity or MAC requirements necessitate clock inversion. > > +Zhi Li > > This isn't the first time we see clock inversion being used to overcome > RGMII timing issues, for setups that have too big of an internal delay, > see [1]. > > I'm wondering if we should either reject this on the account that this > is bad HW design, or embrace that in which case it would probably be > a good idea to come-up with more generic ways to handle that. > > This patch proposes the "dapu,tx-inverted-clk" property, while Zhi Li's > patch has a dedicated compatible for that (and inversion is on RX, on the > MAC side) > > If clock inversion is a common thing for MAC and PHYs to be able to do, > should we add some way of representing the RGMII delays that are > introduced by the HW itself in DT, and let drivers figure-out from that > if they need to resort to clock inversion to align clk and data correctly ? > > Phylib could maybe even provide helpers for that ? > > [1] : https://lore.kernel.org/netdev/20260707064159.1299-1-lizhi2@eswincomputing.com/ > > Maxime >
Hi Artem, On 7/17/26 12:50, Artem Shimko wrote: > Hi Maxime, > > I could suggest a couple options for how I should handle the driver: > 1. Recognizing that this is a problem with the PCS layer, I can remove > the inversion from the patch > (but add it to my working project as a separate, non-upstream patch). > This way, we'll just leave the delays setting in the driver, which is > fairly common among driver users. > 2. Leave the inversion in the driver until some future common > framework solution is developed, and > then adapt this part of the driver to that solution. I'd be happy to > help develop/modify that framework =). > A packet generator could also be added to it. I'd say, you can send the patch without the clock inversion for now, to keep it simple and generic. If the clock inversion is something that you really need we can assess that in a second time. The rest of the driver looks fairly simple and nice :) Maxime
On Thu, Jul 16, 2026 at 08:11:26PM +0200, Maxime Chevallier wrote: > Hi Artem, > > Please slow down a bit, you need to wait at least 24h between patch > submissions : > > https://docs.kernel.org/process/maintainer-netdev.html Adding to that, there is no version history. How does v3 differ to v2. https://docs.kernel.org/process/submitting-patches.html Andrew
Hi Andrew, On Thu, Jul 16, 2026 at 9:32 PM Andrew Lunn <andrew@lunn.ch> wrote: > Adding to that, there is no version history. How does v3 differ to > v2. My apologies, I will fix it. -- Best regards, Artem
© 2016 - 2026 Red Hat, Inc.