[PATCH net] net: stmmac: Guard against txfifosz=0

[PATCH net] net: stmmac: Guard against txfifosz=0

[Florian Fainelli]

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.

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;
-- 
2.19.1

Re: [PATCH net] net: stmmac: Guard against txfifosz=0

[Jakub Kicinski]

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?

> 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;

Re: [PATCH net] net: stmmac: Guard against txfifosz=0

[Florian Fainelli]

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

RE: [PATCH net] net: stmmac: Guard against txfifosz=0

[Jose Abreu]

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.

Anyway, your patch looks sane to me. But if you start seeing TX Queue 
Timeout for higher MTU values then you'll need to add tx-fifo-depth 
property.

---
Thanks,
Jose Miguel Abreu

Re: [PATCH net] net: stmmac: Guard against txfifosz=0

[Chen-Yu Tsai]

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.

ChenYu

> Anyway, your patch looks sane to me. But if you start seeing TX Queue
> Timeout for higher MTU values then you'll need to add tx-fifo-depth
> property.
>
> ---
> Thanks,
> Jose Miguel Abreu
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH net] net: stmmac: Guard against txfifosz=0

[Jose Abreu]

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

Re: [PATCH net] net: stmmac: Guard against txfifosz=0

[Chen-Yu Tsai]

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.

ChenYu

Re: [PATCH net] net: stmmac: Guard against txfifosz=0

[Florian Fainelli]

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