Messages in this thread | | | Date | Mon, 2 Aug 2021 16:59:11 +0300 | From | Vladimir Oltean <> | Subject | Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support for microchip lan937x |
| |
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
| |