Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support for microchip lan937x

On Mon, Aug 02, 2021 at 04:59:11PM +0300, Vladimir Oltean wrote:

On Mon, Aug 02, 2021 at 03:13:01PM +0200, Andrew Lunn wrote:

quoted

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.

quoted

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.

It is a can or worms. For the used use case for the mv88e6xxx, it is a
DSA link, so there isn't really one side MAC and the other side
PHY. And if i remember correctly, both sides use rgmii-rxid.

     Andrew