Re: [PATCH net-next v3 0/2] Add DAPU Telecom DAP8211R(I) Gigabit Ethernet PHY driver

[Maxime Chevallier]

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@xxxxxxxxxxxxxxxxxx/

Maxime