Messages in this thread | | | Subject | Re: [PATCH RFT] ravb: Mask PHY mode to avoid inserting delays twice | From | Sergei Shtylyov <> | Date | Sun, 31 May 2020 20:30:55 +0300 |
| |
Hello!
On 31.05.2020 7:51, David Miller wrote:
>> Until recently, the Micrel KSZ9031 PHY driver ignored any PHY mode >> ("RGMII-*ID") settings, but used the hardware defaults, augmented by >> explicit configuration of individual skew values using the "*-skew-ps" >> DT properties. The lack of PHY mode support was compensated by the >> EtherAVB MAC driver, which configures TX and/or RX internal delay >> itself, based on the PHY mode. >> >> However, now the KSZ9031 driver has gained PHY mode support, delays may >> be configured twice, causing regressions. E.g. on the Renesas >> Salvator-X board with R-Car M3-W ES1.0, TX performance dropped from ca. >> 400 Mbps to 0.1-0.3 Mbps, as measured by nuttcp. >> >> As internal delay configuration supported by the KSZ9031 PHY is too >> limited for some use cases, the ability to configure MAC internal delay >> is deemed useful and necessary. Hence a proper fix would involve >> splitting internal delay configuration in two parts, one for the PHY, >> and one for the MAC. However, this would require adding new DT >> properties, thus breaking DTB backwards-compatibility. >> >> Hence fix the regression in a backwards-compatibility way, by letting >> the EtherAVB driver mask the PHY mode when it has inserted a delay, to >> avoid the PHY driver adding a second delay. This also fixes messages >> like: >> >> Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: *-skew-ps values should be used only with phy-mode = "rgmii" >> >> as the PHY no longer sees the original RGMII-*ID mode. >> >> Solving the issue by splitting configuration in two parts can be handled >> in future patches, and would require retaining a backwards-compatibility >> mode anyway. >> >> Fixes: bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > Applied to net-next, thank you.
Why not to net.git? It's a fix after all...
MBR, Sergei
| |