From: Florian Fainelli <f.fainelli@gmail.com>
To: Chen-Yu Tsai <wens@kernel.org>, Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
Alexandre Torgue <alexandre.torgue@st.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"mripard@kernel.org" <mripard@kernel.org>,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-stm32@st-md-mailman.stormreply.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
"olteanv@gmail.com" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH net] net: stmmac: Guard against txfifosz=0
Date: Mon, 13 Apr 2020 21:05:48 -0700 [thread overview]
Message-ID: <c123b280-e66e-229e-a6a1-1999ed0b0338@gmail.com> (raw)
In-Reply-To: <CAGb2v64XcLHYFVwy8mnKnUR2qEcJOYLHJF1uDAcqmy484CUoFQ@mail.gmail.com>
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
prev parent reply other threads:[~2020-04-14 4:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-12 3:49 [PATCH net] net: stmmac: Guard against txfifosz=0 Florian Fainelli
2020-04-12 18:27 ` Jakub Kicinski
2020-04-12 18:31 ` Florian Fainelli
2020-04-13 6:42 ` Jose Abreu
2020-04-13 6:50 ` Chen-Yu Tsai
2020-04-13 6:56 ` Jose Abreu
2020-04-14 1:49 ` Chen-Yu Tsai
2020-04-14 4:05 ` Florian Fainelli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c123b280-e66e-229e-a6a1-1999ed0b0338@gmail.com \
--to=f.fainelli@gmail.com \
--cc=Jose.Abreu@synopsys.com \
--cc=alexandre.torgue@st.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mripard@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=peppe.cavallaro@st.com \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).