linux-kernel - Re: [PATCH v2 2/2] net: phy: realtek: Change TX-delay setting for RGMII modes only

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 Apr 2019 22:44:00 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Serge Semin <fancer.lancer@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Serge Semin <Sergey.Semin@...latforms.ru>,
        netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] net: phy: realtek: Change TX-delay setting for
 RGMII modes only

Hello Vladimir,

On Tue, Apr 30, 2019 at 12:37 AM Vladimir Oltean <olteanv@...il.com> wrote:
[...]
> Moreover, RGMII *always* needs clock skew. As a fact, all delays
> applied on RX and RX, by the PHY, MAC or traces, should always amount
> to a logical "rgmii-id". There's nothing that needs to be described
> about that. Everybody knows it.
thank you for mentioning this - I didn't know about it. I thought that
the delays have to be added in "some cases" only (without knowing the
definition of "some cases").

> What Linux gets told through the phy-mode property for RGMII is where
> there's extra stuff to do, and where there's nothing to do. There are
> also unwritten rules about whose job it is to apply the clock skew
> (MAC or PHY).That is 100% configuration and 0% description.
the phy-mode property is documented here [0] and the rgmii modes have
a short explanation about the delays.
that said: the documentation currently ignores the fact that a PCB
designer might have added a delay

> > Then in accordance with the phy-mode property value MAC and PHY drivers
> > determine which way the MAC and PHY are connected to each other and how
> > their settings are supposed to be customized to comply with it. This
> > interpretation perfectly fits with the "DT is the hardware description"
> > rule.
> >
>
> Most of the phy-mode properties really mean nothing. I changed the
> phy-mode from "sgmii" to "rgmii" on a PHY binding I had at hand and
> nothing happened (traffic still runs normally). I think this behavior
> is 100% within expectation.
the PHY drivers I know of don't complain if the phy-mode is not supported.
however, there are MAC drivers which complain in this case, see [1]
for one example


Martin


[0] https://github.com/torvalds/linux/blob/bf3bd966dfd7d9582f50e9bd08b15922197cd277/Documentation/devicetree/bindings/net/ethernet.txt#L17
[1] https://github.com/torvalds/linux/blob/bf3bd966dfd7d9582f50e9bd08b15922197cd277/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c#L187