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: Sun, 10 Oct 2021 18:53:28 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Andrew Lunn <andrew@...n.ch> Cc: Ansuel Smith <ansuelsmth@...il.com>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Rob Herring <robh+dt@...nel.org>, Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [net-next PATCH v4 06/13] net: dsa: qca8k: move rgmii delay detection to phylink mac_config On Sun, Oct 10, 2021 at 05:18:16PM +0200, Andrew Lunn wrote: > > > -{ > > > - struct device_node *port_dn; > > > - phy_interface_t mode; > > > - struct dsa_port *dp; > > > - u32 val; > > > - > > > - /* CPU port is already checked */ > > > - dp = dsa_to_port(priv->ds, 0); > > > - > > > - port_dn = dp->dn; > > > - > > > - /* Check if port 0 is set to the correct type */ > > > - of_get_phy_mode(port_dn, &mode); > > > - if (mode != PHY_INTERFACE_MODE_RGMII_ID && > > > - mode != PHY_INTERFACE_MODE_RGMII_RXID && > > > - mode != PHY_INTERFACE_MODE_RGMII_TXID) { > > > - return 0; > > > - } > > > - > > > - switch (mode) { > > > - case PHY_INTERFACE_MODE_RGMII_ID: > > > - case PHY_INTERFACE_MODE_RGMII_RXID: > > > > Also, since you touch this area. > > There have been tons of discussions on this topic, but I believe that > > your interpretation of the RGMII delays is wrong. > > Basically a MAC should not apply delays based on the phy-mode string (so > > it should treat "rgmii" same as "rgmii-id"), but based on the value of > > "rx-internal-delay-ps" and "tx-internal-delay-ps". > > The phy-mode is for a PHY to use. > > There is one exception to this, when the MAC is taking the place of a > PHY, i.e. CPU port. You need delays added somewhere, and the mv88e6xxx > driver will look at the phy-mode in this case. Yes, and I don't think it's an actual exception, it's still back-to-back MACs. It is true on the other hand that some drivers don't seem to behave this way. Russell has been suggesting that the phy-mode should be treated the same way regardless of whether a PHY is attached or not. It would be nice to reach a common agreement so that we know what to suggest people to do. > And i think in general, a DSA driver needs this for the CPU port. Not saying it doesn't need it, just saying that the need for the {rx,tx}-internal-delay-ps MAC property was not recognized at the time and that's why the vast majority of drivers don't act upon it. The qca8k driver is somewhat special in that it does parse these new properties, but at the same time also parse the phy-mode, that is kind of strange.
Powered by blists - more mailing lists