lkml.org 
[lkml]   [2020]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH net] net: stmmac: Guard against txfifosz=0
Date
From: Chen-Yu Tsai <wens@kernel.org>
Date: Apr/13/2020, 07:50:47 (UTC+00:00)

> On Mon, Apr 13, 2020 at 2:42 PM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
> >
> > From: Florian Fainelli <f.fainelli@gmail.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.

---
Thanks,
Jose Miguel Abreu
\
 
 \ /
  Last update: 2020-04-13 09:00    [W:0.269 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site