linux-kernel - RE: [PATCH 1/2] stmmac: introduce flag to dynamically disable TX offload for rockchip devices

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <78EB27739596EE489E55E81C33FEC33A0B421348@de02wembxa.internal.synopsys.com>
Date:   Tue, 2 Apr 2019 07:59:51 +0000
From:   Jose Abreu <jose.abreu@...opsys.com>
To:     Philipp Tomsich <philipp.tomsich@...obroma-systems.com>,
        Heiko Stübner <heiko@...ech.de>,
        Christoph Müllner 
        <christoph.muellner@...obroma-systems.com>
CC:     Robin Murphy <robin.murphy@....com>,
        "Leonidas P. Papadakos" <papadakospan@...il.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jose Abreu <jose.abreu@...opsys.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Klaus Goger <klaus.goger@...obroma-systems.com>
Subject: RE: [PATCH 1/2] stmmac: introduce flag to dynamically disable TX
 offload for rockchip devices

From: Philipp Tomsich <philipp.tomsich@...obroma-systems.com>
Date: Mon, Apr 01, 2019 at 20:12:21

> + Christoph.
> 
> > On 01.04.2019, at 21:06, Heiko Stübner <heiko@...ech.de> wrote:
> > 
> > Am Montag, 1. April 2019, 20:54:45 CEST schrieb Robin Murphy:
> >> On 01/04/2019 19:18, Leonidas P. Papadakos wrote:
> >>> From: =?UTF-8?q?Kamil=20Trzci=C5=84ski?= <ayufan@...fan.eu>
> >>> 
> >>> Some rockchip boards exhibit an issue where tx checksumming does not work 
> with
> >>> packets larger than 1498.
> >> 
> >> Is it really a board-level problem? I'm no networking expert, but the 
> >> nature of the workaround suggests this is more likely to be some 
> >> inherent limitation of the IP block in the SoC, rather than something to 
> >> do with how the external pins get wired up. Does anyone have an RK3328 
> >> or RK3399 board that provably *does* checksum large packets correctly?
> > 
> > I don't have that many rk3399-boards with actual ethernet and even only
> > the rock64 from rk3328-land, but at least my rk3399-firefly also seems
> > affected by this.
> > 
> > But so far the rk3399-puma board from Theobroma did not show that ethernet
> > issue for me, so I've added two Theobroma people who may or may not tell
> > if they've also seen that issue.
> > 
> >> 
> >>> This is bad for network stability.
> >>> 
> >>> The previous approach was using force_thresh_dma_mode in the board dts, 
> which
> >>> does more than we need.
> >> 
> >> If indeed it is a SoC-level thing (or at least we want to treat it as 
> >> such), then couldn't we just hang it off the existing SoC-specific 
> >> compatibles in dwmac-rk.c and avoid the need for a new DT property at 
> >> all? After all, that's precisely why SoC-specific compatibles are a 
> >> thing in the first place.
> >> 

This can happen when FIFO size + PBL settings are not big enough for COE.

Can you please share the above settings ?

Thanks,
Jose Miguel Abreu