Messages in this thread | | | Subject | Re: [PATCH net] net: stmmac: Guard against txfifosz=0 | From | Florian Fainelli <> | Date | Mon, 13 Apr 2020 21:05:48 -0700 |
| |
On 4/13/2020 6:49 PM, Chen-Yu Tsai wrote: > On Mon, Apr 13, 2020 at 2:59 PM Jose Abreu <Jose.Abreu@synopsys.com> wrote: >> >> 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. > > 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! -- Florian
| |