Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 25 Mar 2019 21:30:06 +0200
From:   Aaro Koskinen <aaro.koskinen@iki.fi>
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Vinod Koul <vkoul@kernel.org>,
        "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org,
        linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BISECTED, REGRESSION] Broken networking on MIPS/OCTEON
 EdgeRouter Lite
Message-ID: <20190325193006.GA16484@darkstar.musicnaut.iki.fi>
References: <20190322002125.GD7872@darkstar.musicnaut.iki.fi>
 <20190322064506.GB5348@vkoul-mobl>
 <20190322205059.GA29013@darkstar.musicnaut.iki.fi>
 <20190322212557.GF16623@lunn.ch>
 <20190322214120.GB29013@darkstar.musicnaut.iki.fi>
 <20190324201734.GC7782@lunn.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190324201734.GC7782@lunn.ch>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On Sun, Mar 24, 2019 at 09:17:34PM +0100, Andrew Lunn wrote:
> On Fri, Mar 22, 2019 at 11:41:20PM +0200, Aaro Koskinen wrote:
> > On Fri, Mar 22, 2019 at 10:25:57PM +0100, Andrew Lunn wrote:
> > > > The OCTEON HW code knows only about RGMII. And looking at
> > > > octeon ethernet staging driver it does phy connect always with
> > > > PHY_INTERFACE_MODE_GMII. I did some experimentation, and it seems that
> > > > with PHY_INTERFACE_MODE_RGMII_RXID it starts to work.. In the DT we have
> > > > for ethernet for this board:
> > > > 
> > > > 	rx-delay = <0>;
> > > > 	tx-delay = <0x10>;
> > > 
> > > These are not PHY properties. 
> > > 
> > > Looking at the code, it looks like these control delays the MAC
> > > inserts. I don't see a binding document for these properties, so i've
> > > no idea what 0x10 means. Before this driver moves out of staging,
> > > these values should be changed to be in ns.
> > 
> > Documentation/devicetree/bindings/net/cavium-pip.txt
> 
> Hi Aaro
> 
> Ah, sorry, missed that.
> 
> - rx-delay: Delay value for RGMII receive clock. Optional. Disabled if 0.
>   Value range is 1-31, and mapping to the actual delay varies depending on HW.
> 
> - tx-delay: Delay value for RGMII transmit clock. Optional. Disabled if 0.
>   Value range is 1-31, and mapping to the actual delay varies depending on HW.
> 
> I'm surprised this made it passed review. We try to avoid having DT
> poke magic values into registers. That is what this appears to be,
> since it is unclear what the value actually means.

It's probably not too late to improve this since those are
likely used only in-tree. Vendor GPL bundles provide some more
documentation for this setting, as does the FreeBSD source tree:
https://github.com/freebsd/freebsd/blob/master/sys/contrib/octeon-sdk/cvmx-asxx-defs.h#L911

But reading that, I think it could be still difficult to change it to
rx-delay-ps as it seems to be too coarse/unreliable.

> It is also good to state what happens if the property is not
> present. It often means it defaults to zero. But this implementation
> just leaves the value alone. So to be on the safe side, the DT blob
> should probably have these properties, so the behaviour is well
> defined.

The default is to set both to 16 on CN50XX and 24 on other chips.

A.