Re: [PATCH net-next 4/8] net: dsa: lan9645x: add basic dsa driver for LAN9645X

[Vladimir Oltean]

On Thu, Mar 05, 2026 at 03:58:16PM +0100, Andrew Lunn wrote:
> So, the best thing to do is hard code the delays in the MAC to 0, and
> pass phy-mode to the PHY.

To extend that line of reasoning one step further. If somebody does end
up needing to configure delays in the MAC and observes that phy-mode is
acted upon only by the PHY layer, and that irrespective of phy-mode the
MAC delays are always 0, then they will turn to the rx-internal-delay-ps
and tx-internal-delay-ps properties added to the MAC OF node. Using
these has the benefit that it does not collide with the phy-mode meaning
in any way, so is not a compatibility problem.

> Now, this is a switch, so there is one complexity. Some switches make
> use of an RGMII port to connect to the host. You then have the host
> RGMII MAC connected to the switch RGMII MAC. Delays have to be added
> somewhere. Since the switch MAC is playing the role of the PHY, in the
> eyes of the host, we allow such a port to add delays.

Well, since rx-internal-delay-ps and tx-internal-delay-ps in the MAC OF
node would handle that case as well, there isn't any need really to
complicate the implementation with any custom phy-mode interpretation
there either. Introducing the concept of a "PHY role" for RGMII delays
in CPU ports is rather unnecessary given the tools we have today.