Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support for microchip lan937x
From: Vladimir Oltean <olteanv@gmail.com>
Date: 2021-08-02 14:16:51
Also in:
lkml, netdev
On Mon, Aug 02, 2021 at 03:13:01PM +0200, Andrew Lunn wrote:
In general, the MAC does nothing, and passes the value to the PHY. The PHY inserts delays as requested. To address Vladimir point, PHY_INTERFACE_MODE_RGMII_TXID would mean the PHY adds delay in the TX direction, and assumes the RX delay comes from somewhere else, probably the PCB.
For the PHY, that is the only portion where things are clear.
I only recommend the MAC adds delays when the PHY cannot, or there is no PHY, e.g. SoC to switch, or switch to switch link. There are a few MAC drivers that do add delays, mostly because that is how the vendor crap tree does it. So as i said, what you propose is O.K, it follows this general rule of thumb.
The "rule of thumb" for a MAC driver is actually applied in reverse by
most MAC drivers compared to what Russell described should be happening.
For example, mv88e6xxx_port_set_rgmii_delay():
switch (mode) {
case PHY_INTERFACE_MODE_RGMII_RXID:
reg |= MV88E6XXX_PORT_MAC_CTL_RGMII_DELAY_RXCLK;
The mv88e6xxx is a MAC, so when it has a phy-mode = "rgmii-rxid", it
should assume it is connected to a link partner (PHY or otherwise) that
has applied the RXCLK delay already. So it should only be concerned with
the TXCLK delay. That is my point. I am just trying to lay out the
points to Prasanna that would make a sane system going forward. I am not
sure that we actually have an in-tree driver that is sane in that
regard.
That discussion, and Russell's point, was here, btw:
https://patchwork.ozlabs.org/project/netdev/patch/20200616074955.GA9092@laureti-dev/#2461123