Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 12 Aug 2021 16:26:41 +0100
Message-ID: <87v94a8z0u.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Thierry Reding <thierry.reding@gmail.com>
Cc:     Matteo Croce <mcroce@linux.microsoft.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
        Giuseppe Cavallaro <peppe.cavallaro@st.com>,
        Alexandre Torgue <alexandre.torgue@foss.st.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Drew Fustini <drew@beagleboard.org>,
        Emil Renner Berthing <kernel@esmil.dk>,
        Jon Hunter <jonathanh@nvidia.com>,
        Will Deacon <will@kernel.org>
Subject: Re: [PATCH net-next] stmmac: align RX buffers
In-Reply-To: <YRUwMjeQnXH5RfoB@orome.fritz.box>
References: <20210614022504.24458-1-mcroce@linux.microsoft.com>
        <871r71azjw.wl-maz@kernel.org>
        <YROpd450N+n6hYt2@orome.fritz.box>
        <87pmuk9ku9.wl-maz@kernel.org>
        <YRUwMjeQnXH5RfoB@orome.fritz.box>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Thu, 12 Aug 2021 15:29:06 +0100,
Thierry Reding <thierry.reding@gmail.com> wrote:
> 
> On Wed, Aug 11, 2021 at 02:23:10PM +0100, Marc Zyngier wrote:

[...]

> > I love this machine... Did this issue occur with the Denver CPUs
> > disabled?
> 
> Interestingly I've been doing some work on a newer device called Jetson
> TX2 NX (which is kind of a trimmed-down version of Jetson TX2, in the
> spirit of the Jetson Nano) and I can't seem to reproduce these failures
> there (tested on next-20210812).
> 
> I'll go dig out my Jetson TX2 to run the same tests there, because I've
> also been using a development version of the bootloader stack and
> flashing tools and all that, so it's possible that something was fixed
> at that level. I don't think I've ever tried disabling the Denver CPUs,
> but then I've also never seen these issues myself.
> 
> Just out of curiosity, what version of the BSP have you been using to
> flash?

I've only used the BSP for a few weeks when I got the board last
year. The only thing I use from it is u-boot to chainload an upstream
u-boot, and boot Debian from there.

> One other thing that I ran into: there's a known issue with the PHY
> configuration. We mark the PHY on most devices as "rgmii-id" on most
> devices and then the Marvell PHY driver needs to be enabled. Jetson TX2
> has phy-mode = "rgmii", so it /should/ work okay.
> 
> Typically what we're seeing with that misconfiguration is that the
> device fails to get an IP address, but it might still be worth trying to
> switch Jetson TX2 to rgmii-id and using the Marvell PHY, to see if that
> improves anything.

I never failed to get an IP address. Overall, networking has been
solid on this machine until this patch. I'll try and mess with this
when I get time, but that's probably going to be next week now.

[...]

> > That'd be pretty annoying. Do you know if the Ethernet is a coherent
> > device on this machine? or does it need active cache maintenance?
> 
> I don't think Ethernet is a coherent device on Tegra186. I think
> Tegra194 had various improvements with regard to coherency, but most
> devices on Tegra186 do need active cache maintenance.
> 
> Let me dig through some old patches and mailing list threads. I vaguely
> recall prototyping a patch that did something special for outer cache
> flushing, but that may have been Tegra132, not Tegra186. I also don't
> think we ended up merging that because it turned out to not be needed.

ARMv8 forbid any sort of *visible* outer cache, so I really hope this
is not required. We wouldn't be able to support it.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.