Message-ID: <20190508004809.qhiz4bpqtxe34276@mobilestation>
Date:   Wed, 8 May 2019 03:48:10 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Vladimir Oltean <olteanv@...il.com>
Cc:     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 folks

On Tue, Apr 30, 2019 at 10:44:00PM +0200, Martin Blumenstingl wrote:
> 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

So as far as I can conclude from the whole discussion, we don't really
want the realtek driver to return an error in case if any unsupported
mode is passed to the config_init method including the RGMII_RXID one,
which in some cases could be enabled via RXDLY pin strapping (like on
rtl8211F). The reason is quite justified: even though there is no
known way to alter the RX-delay on the rtl8211F PHY side, the delay
can be enabled via external pin. In this case rgmii-rxid mode can be
enabled in dts and should be considered a correct error-less PHY node
property.

In order to have this all summed up, I'll shortly send a v3 patchset with
alterations based on the discussion results. Maintainers then will be able
to post their comments in reply to it.

Cheers.
-Sergey

Powered by blists - more mailing lists