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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 13 Apr 2020 21:05:48 -0700
From:   Florian Fainelli <>
To:     Chen-Yu Tsai <>,
        Jose Abreu <>
Cc:     Jakub Kicinski <>,
        Alexandre Torgue <>,
        "" <>,
        open list <>,
        "" <>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
        Maxime Coquelin <>,
        Giuseppe Cavallaro <>,
        "" <>,
        "David S. Miller" <>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
Subject: Re: [PATCH net] net: stmmac: Guard against txfifosz=0

On 4/13/2020 6:49 PM, Chen-Yu Tsai wrote:
> On Mon, Apr 13, 2020 at 2:59 PM Jose Abreu <> wrote:
>> From: Chen-Yu Tsai <>
>> Date: Apr/13/2020, 07:50:47 (UTC+00:00)
>>> On Mon, Apr 13, 2020 at 2:42 PM Jose Abreu <> wrote:
>>>> From: Florian Fainelli <>
>>>> Date: Apr/12/2020, 19:31:55 (UTC+00:00)
>>>>> On 4/12/2020 11:27 AM, Jakub Kicinski wrote:
>>>>>> On Sat, 11 Apr 2020 20:49:31 -0700 Florian Fainelli wrote:
>>>>>>> After commit bfcb813203e619a8960a819bf533ad2a108d8105 ("net: dsa:
>>>>>>> configure the MTU for switch ports") my Lamobo R1 platform which uses
>>>>>>> an allwinner,sun7i-a20-gmac compatible Ethernet MAC started to fail
>>>>>>> by rejecting a MTU of 1536. The reason for that is that the DMA
>>>>>>> capabilities are not readable on this version of the IP, and there is
>>>>>>> also no 'tx-fifo-depth' property being provided in Device Tree. The
>>>>>>> property is documented as optional, and is not provided.
>>>>>>> The minimum MTU that the network device accepts is ETH_ZLEN - ETH_HLEN,
>>>>>>> so rejecting the new MTU based on the txfifosz value unchecked seems a
>>>>>>> bit too heavy handed here.
>>>>>> OTOH is it safe to assume MTUs up to 16k are valid if device tree lacks
>>>>>> the optional property? Is this change purely to preserve backward
>>>>>> (bug-ward?) compatibility, even if it's not entirely correct to allow
>>>>>> high MTU values? (I think that'd be worth stating in the commit message
>>>>>> more explicitly.) Is there no "reasonable default" we could select for
>>>>>> txfifosz if property is missing?
>>>>> Those are good questions, and I do not know how to answer them as I am
>>>>> not familiar with the stmmac HW design, but I am hoping Jose can respond
>>>>> on this patch. It does sound like providing a default TX FIFO size would
>>>>> solve that MTU problem, too, but without a 'tx-fifo-depth' property
>>>>> specified in Device Tree, and with the "dma_cap" being empty for this
>>>>> chip, I have no idea what to set it to.
>>>> Unfortunately, allwinner uses GMAC which does not have any mean to detect
>>>> TX FIFO Size. Default value in HW is 2k but this can not be the case in
>>>> these platforms if HW team decided to change it.
>>> I looked at all the publicly available datasheets and Allwinner uses
>>> 4K TX FIFO and 16K RX FIFO in all SoCs. Not sure if this would help.
>> Yes, thanks for finding this!
>> So, I think correct fix is then to hard-code these values in dwmac-sunxi.c
>> probe function using the already available platform data structure.
> I guess we should also set this in the device trees, so that all DT users
> can benefit.

Sure, but that will be a bit harder to roll in as a bug fix. I will go
ahead and submit a fix for dwmac-sunxi.c to specify a 4KB TX FIFO and
16KB RX FIFO. Thanks!

Powered by blists - more mailing lists