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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 10 Jun 2020 13:40:22 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Helmut Grohne <helmut.grohne@...enta.de>
Cc:     netdev@...r.kernel.org
Subject: Re: correct use of PHY_INTERFACE_MODE_RGMII{,_TXID,_RXID,_ID}



On 6/10/2020 1:12 PM, Andrew Lunn wrote:
> On Wed, Jun 10, 2020 at 10:12:37AM +0200, Helmut Grohne wrote:
>> Hi,
>>
>> I've been trying to write a dt for a board and got quite confused about
>> the RGMII delays. That's why I looked into it and got even more confused
>> by what I found. Different drivers handle this quite differently. Let me
>> summarize.
> 
> Hi Helmut
> 
> In general, in DT, put what you want the PHY to do. If the PCB does
> not add the delay, use rgmii-id. If the PCB does add the delay, then
> use rgmii.
> 
> It is quite confusing, we have had bugs, and some drivers just do odd
> things. In general, the MAC should not add delays. The PHY should add
> delays, based on what is passed via DT. This assumes the PHY actually
> implements the delays, which most PHYs do.

In a MAC to MAC connection, one of the MAC, or both, or the PCB must
ensure that appropriate delays are inserted in order for
the RGMII connection to be functional. Or put differently, you could
view one of the MAC abiding to the 'phy-mode' property as if it was a PHY.

This is the reason why you may find Device Trees like
arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts where we have a stmmac
connected to an external BCM53125 switch and the stmmac sets phy-mode =
'rgmii' while the switch sets phy-mode = 'rgmii-txid' in order to
account for the necessary delay.

The essential problem we have today is that there is no consistent, fool
proof and programmatic way to ensure that when a MAC and PHY or MAC and
MAC are interfaced to each other, that the delays are correct, this is
almost always a trial and error process which is irritating.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ