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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 13 Apr 2020 06:42:07 +0000
From:   Jose Abreu <>
To:     Florian Fainelli <>,
        Jakub Kicinski <>
CC:     "" <>,
        "" <>,
        "" <>,
        "Giuseppe Cavallaro" <>,
        Alexandre Torgue <>,
        "David S. Miller" <>,
        "Maxime Coquelin" <>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
        "moderated list:ARM/STM32 ARCHITECTURE" 
        "open list" <>
Subject: RE: [PATCH net] net: stmmac: Guard against txfifosz=0

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.

Anyway, your patch looks sane to me. But if you start seeing TX Queue 
Timeout for higher MTU values then you'll need to add tx-fifo-depth 

Jose Miguel Abreu

Powered by blists - more mailing lists