Thread (44 messages) flat view 44 messages, 5 authors, 2021-08-11

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help