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

[Artem Shimko]

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