netdev - Re: correct use of PHY_INTERFACE_MODE_RGMII{,_TXID,_RXID,

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]

Message-ID: <bd14bc16-1f0b-695f-cd00-713c100bfda7@gmail.com>
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