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

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

Message-ID: <4a9839d6-3d90-4354-7b64-78d5c1126e99@arm.com>
Date:   Tue, 2 Apr 2019 12:49:36 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Jose Abreu <jose.abreu@...opsys.com>,
        Philipp Tomsich <philipp.tomsich@...obroma-systems.com>,
        Heiko Stübner <heiko@...ech.de>,
        Christoph Müllner 
        <christoph.muellner@...obroma-systems.com>
Cc:     "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>,
        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

On 02/04/2019 08:59, Jose Abreu wrote:
> 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 ?

Can the FIFO size be discovered by dumping registers, or does someone 
from Rockchip need to look up the IP configuration details?

FWIW, taking a look at the RK3399 TRM, this (p788) jumps out:

"PBL
...
For TxFIFO, valid PBL range in full duplex mode and duplex mode is
128 or less.
For RxFIFO, valid PBL range in full duplex mode is all."


Does that suggest that it's worth fiddling with the "snps,txpbl" value 
in DT?

Thanks,
Robin.