lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 2 Aug 2021 22:47:16 +0200 From: Andrew Lunn <andrew@...n.ch> To: Vladimir Oltean <olteanv@...il.com> Cc: Prasanna Vengateshan <prasanna.vengateshan@...rochip.com>, netdev@...r.kernel.org, robh+dt@...nel.org, UNGLinuxDriver@...rochip.com, Woojung.Huh@...rochip.com, hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net, kuba@...nel.org, linux-kernel@...r.kernel.org, vivien.didelot@...il.com, f.fainelli@...il.com, devicetree@...r.kernel.org Subject: 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: > > 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. 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
Powered by blists - more mailing lists