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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 27 May 2020 22:52:21 +0200
From:   Andrew Lunn <>
To:     Geert Uytterhoeven <>
Cc:     Oleksij Rempel <>,
        Philippe Schenker <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        Kazuya Mizuguchi <>,
        Grygorii Strashko <>
Subject: Re: [PATCH net-next v3] net: phy: micrel: add phy-mode support for
 the KSZ9031 PHY

> You may wonder what's the difference between 3 and 4? It's not just the
> PHY driver that looks at phy-mode!
> drivers/net/ethernet/renesas/ravb_main.c:ravb_set_delay_mode() also
> does, and configures an additional TX clock delay of 1.8 ns if TXID is
> enabled.

Hi Geert

That sounds like a MAC bug. Either the MAC insert the delay, or the
PHY does. If the MAC decides it is going to insert the delay, it
should be masking what it passes to phylib so that the PHY does not
add a second delay.

This whole area of RGMII delays has a number of historical bugs, which
often counter act each other. So you fix one, and it break somewhere

In this case, not allowing skews for plain RGMII is probably being too
strict. We probably should relax that constrain in this case, for this
PHY driver.


Powered by blists - more mailing lists