netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, olteanv@gmail.com, mripard@kernel.org,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	"David S. Miller" <davem@davemloft.net>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	"moderated list:ARM/STM32 ARCHITECTURE" 
	<linux-stm32@st-md-mailman.stormreply.com>,
	"moderated list:ARM/STM32 ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] net: stmmac: Guard against txfifosz=0
Date: Sun, 12 Apr 2020 11:31:55 -0700	[thread overview]
Message-ID: <ae06b4c6-6818-c053-6f33-55c96f88a4ae@gmail.com> (raw)
In-Reply-To: <20200412112756.687ff227@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>



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.

> 
>> Fixes: eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index e6898fd5223f..9c63ba6f86a9 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -3993,7 +3993,7 @@ static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
>>  	new_mtu = STMMAC_ALIGN(new_mtu);
>>  
>>  	/* If condition true, FIFO is too small or MTU too large */
>> -	if ((txfifosz < new_mtu) || (new_mtu > BUF_SIZE_16KiB))
>> +	if ((txfifosz < new_mtu && txfifosz) || (new_mtu > BUF_SIZE_16KiB))
>>  		return -EINVAL;
>>  
>>  	dev->mtu = new_mtu;
> 

-- 
Florian

  reply	other threads:[~2020-04-12 18:32 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 [this message]
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

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=ae06b4c6-6818-c053-6f33-55c96f88a4ae@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=alexandre.torgue@st.com \
    --cc=davem@davemloft.net \
    --cc=joabreu@synopsys.com \
    --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 \
    /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).