* [PATCH net] net: stmmac: Guard against txfifosz=0
@ 2020-04-12 3:49 Florian Fainelli
2020-04-12 18:27 ` Jakub Kicinski
0 siblings, 1 reply; 8+ messages in thread
From: Florian Fainelli @ 2020-04-12 3:49 UTC (permalink / raw)
To: netdev
Cc: olteanv, mripard, Florian Fainelli, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
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
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH net] net: stmmac: Guard against txfifosz=0 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 0 siblings, 1 reply; 8+ messages in thread From: Jakub Kicinski @ 2020-04-12 18:27 UTC (permalink / raw) To: Florian Fainelli Cc: netdev, olteanv, mripard, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin, moderated list:ARM/STM32 ARCHITECTURE, moderated list:ARM/STM32 ARCHITECTURE, open list 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; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH net] net: stmmac: Guard against txfifosz=0 2020-04-12 18:27 ` Jakub Kicinski @ 2020-04-12 18:31 ` Florian Fainelli 2020-04-13 6:42 ` Jose Abreu 0 siblings, 1 reply; 8+ messages in thread From: Florian Fainelli @ 2020-04-12 18:31 UTC (permalink / raw) To: Jakub Kicinski Cc: netdev, olteanv, mripard, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin, moderated list:ARM/STM32 ARCHITECTURE, moderated list:ARM/STM32 ARCHITECTURE, open list 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH net] net: stmmac: Guard against txfifosz=0 2020-04-12 18:31 ` Florian Fainelli @ 2020-04-13 6:42 ` Jose Abreu 2020-04-13 6:50 ` Chen-Yu Tsai 0 siblings, 1 reply; 8+ messages in thread From: Jose Abreu @ 2020-04-13 6:42 UTC (permalink / raw) To: Florian Fainelli, Jakub Kicinski Cc: netdev, olteanv, mripard, Giuseppe Cavallaro, Alexandre Torgue, David S. Miller, Maxime Coquelin, moderated list:ARM/STM32 ARCHITECTURE, moderated list:ARM/STM32 ARCHITECTURE, open list 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH net] net: stmmac: Guard against txfifosz=0 2020-04-13 6:42 ` Jose Abreu @ 2020-04-13 6:50 ` Chen-Yu Tsai 2020-04-13 6:56 ` Jose Abreu 0 siblings, 1 reply; 8+ messages in thread From: Chen-Yu Tsai @ 2020-04-13 6:50 UTC (permalink / raw) To: Jose Abreu, Florian Fainelli Cc: Jakub Kicinski, Alexandre Torgue, netdev, open list, mripard, moderated list:ARM/STM32 ARCHITECTURE, Maxime Coquelin, Giuseppe Cavallaro, olteanv, David S. Miller, moderated list:ARM/STM32 ARCHITECTURE 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH net] net: stmmac: Guard against txfifosz=0 2020-04-13 6:50 ` Chen-Yu Tsai @ 2020-04-13 6:56 ` Jose Abreu 2020-04-14 1:49 ` Chen-Yu Tsai 0 siblings, 1 reply; 8+ messages in thread From: Jose Abreu @ 2020-04-13 6:56 UTC (permalink / raw) To: Chen-Yu Tsai, Florian Fainelli Cc: Jakub Kicinski, Alexandre Torgue, netdev, open list, mripard, moderated list:ARM/STM32 ARCHITECTURE, Maxime Coquelin, Giuseppe Cavallaro, olteanv, David S. Miller, moderated list:ARM/STM32 ARCHITECTURE 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH net] net: stmmac: Guard against txfifosz=0 2020-04-13 6:56 ` Jose Abreu @ 2020-04-14 1:49 ` Chen-Yu Tsai 2020-04-14 4:05 ` Florian Fainelli 0 siblings, 1 reply; 8+ messages in thread From: Chen-Yu Tsai @ 2020-04-14 1:49 UTC (permalink / raw) To: Jose Abreu Cc: Chen-Yu Tsai, Florian Fainelli, Jakub Kicinski, Alexandre Torgue, netdev, open list, mripard, moderated list:ARM/STM32 ARCHITECTURE, Maxime Coquelin, Giuseppe Cavallaro, olteanv, David S. Miller, moderated list:ARM/STM32 ARCHITECTURE 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH net] net: stmmac: Guard against txfifosz=0 2020-04-14 1:49 ` Chen-Yu Tsai @ 2020-04-14 4:05 ` Florian Fainelli 0 siblings, 0 replies; 8+ messages in thread From: Florian Fainelli @ 2020-04-14 4:05 UTC (permalink / raw) To: Chen-Yu Tsai, Jose Abreu Cc: Jakub Kicinski, Alexandre Torgue, netdev, open list, mripard, moderated list:ARM/STM32 ARCHITECTURE, Maxime Coquelin, Giuseppe Cavallaro, olteanv, David S. Miller, moderated list:ARM/STM32 ARCHITECTURE 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-04-14 4:05 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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).