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
| ||
|
Date: Tue, 14 Apr 2020 09:49:57 +0800 From: Chen-Yu Tsai <wens@...nel.org> To: Jose Abreu <Jose.Abreu@...opsys.com> Cc: Chen-Yu Tsai <wens@...nel.org>, Florian Fainelli <f.fainelli@...il.com>, Jakub Kicinski <kuba@...nel.org>, Alexandre Torgue <alexandre.torgue@...com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, "mripard@...nel.org" <mripard@...nel.org>, "moderated list:ARM/STM32 ARCHITECTURE" <linux-stm32@...md-mailman.stormreply.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>, Giuseppe Cavallaro <peppe.cavallaro@...com>, "olteanv@...il.com" <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, "moderated list:ARM/STM32 ARCHITECTURE" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH net] net: stmmac: Guard against txfifosz=0 On Mon, Apr 13, 2020 at 2:59 PM Jose Abreu <Jose.Abreu@...opsys.com> wrote: > > From: Chen-Yu Tsai <wens@...nel.org> > Date: Apr/13/2020, 07:50:47 (UTC+00:00) > > > On Mon, Apr 13, 2020 at 2:42 PM Jose Abreu <Jose.Abreu@...opsys.com> wrote: > > > > > > From: Florian Fainelli <f.fainelli@...il.com> > > > 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. ChenYu
Powered by blists - more mailing lists