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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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;
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 <[email protected]>
>> ---
>> 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
On Mon, Apr 13, 2020 at 2:42 PM Jose Abreu <[email protected]> wrote:
>
> From: Florian Fainelli <[email protected]>
> 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Chen-Yu Tsai <[email protected]>
Date: Apr/13/2020, 07:50:47 (UTC+00:00)
> On Mon, Apr 13, 2020 at 2:42 PM Jose Abreu <[email protected]> wrote:
> >
> > From: Florian Fainelli <[email protected]>
> > 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
From: Florian Fainelli <[email protected]>
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
On Mon, Apr 13, 2020 at 2:59 PM Jose Abreu <[email protected]> wrote:
>
> From: Chen-Yu Tsai <[email protected]>
> Date: Apr/13/2020, 07:50:47 (UTC+00:00)
>
> > On Mon, Apr 13, 2020 at 2:42 PM Jose Abreu <[email protected]> wrote:
> > >
> > > From: Florian Fainelli <[email protected]>
> > > 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
On 4/13/2020 6:49 PM, Chen-Yu Tsai wrote:
> On Mon, Apr 13, 2020 at 2:59 PM Jose Abreu <[email protected]> wrote:
>>
>> From: Chen-Yu Tsai <[email protected]>
>> Date: Apr/13/2020, 07:50:47 (UTC+00:00)
>>
>>> On Mon, Apr 13, 2020 at 2:42 PM Jose Abreu <[email protected]> wrote:
>>>>
>>>> From: Florian Fainelli <[email protected]>
>>>> 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