public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Yanteng Si <si.yanteng@linux.dev>, Furong Xu <0x1207@gmail.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4 3/3] net: stmmac: Specify hardware capability value when FIFO size isn't specified
Date: Fri, 31 Jan 2025 15:54:16 +0000	[thread overview]
Message-ID: <915713e1-b67f-4eae-82c6-8dceae8f97a7@arm.com> (raw)
In-Reply-To: <2ed9e7c7-e760-409e-a431-823bc3f21cb7@lunn.ch>

On 31/01/2025 15:29, Andrew Lunn wrote:
> On Fri, Jan 31, 2025 at 03:03:11PM +0000, Steven Price wrote:
>> On 31/01/2025 14:47, Andrew Lunn wrote:
>>>>> I'm guessing, but in your setup, i assume the value is never written
>>>>> to a register, hence 0 is O.K. e.g. dwmac1000_dma_operation_mode_rx(),
>>>>> the fifosz value is used to determine if flow control can be used, but
>>>>> is otherwise ignored.
>>>>
>>>> I haven't traced the code, but that fits my assumptions too.
>>>
>>> I could probably figure it out using code review, but do you know
>>> which set of DMA operations your hardware uses? A quick look at
>>> dwmac-rk.c i see:
>>>
>>>         /* If the stmmac is not already selected as gmac4,
>>>          * then make sure we fallback to gmac.
>>>          */
>>>         if (!plat_dat->has_gmac4)
>>>                 plat_dat->has_gmac = true;
>>
>> has_gmac4 is false on this board, so has_gmac will be set to true here.
> 
> Thanks. Looking in hwif.c, that means dwmac1000_dma_ops are used.
> 
> dwmac1000_dma_operation_mode_rx() just does a check:
> 
> 	if (rxfifosz < 4096) {
> 		csr6 &= ~DMA_CONTROL_EFC;
> 
> but otherwise does not use the value.
> 
> dwmac1000_dma_operation_mode_tx() appears to completely ignore fifosz.
> 
> So i would say all zero is valid for has_gmac == true, but you might
> gain flow control if a value was passed.
> 
> A quick look at dwmac100_dma_operation_mode_tx() suggests fifosz is
> also ignored, and dwmac100_dma_operation_mode_rx() does not exist. So
> all 0 is also valid for gmac == false, gmac4 == false, and xgmac ==
> false.
> 
> dwmac4_dma_rx_chan_op_mode() does use the value to determine mtl_rx_op
> which gets written to a register. So gmac4 == true looks to need
> values. dwxgmac2_dma_rx_mode() is the same, so xgmac = true also need
> valid values.
> 
> Could you cook up a fix based on this?

The below works for me, I haven't got the hardware to actually test the 
gmac4/xgmac paths:

----8<----
From 1ff2f1d5c35d95b38cdec02a283b039befdff0a4 Mon Sep 17 00:00:00 2001
From: Steven Price <steven.price@arm.com>
Date: Fri, 31 Jan 2025 15:45:50 +0000
Subject: [PATCH] net: stmmac: Allow zero for [tr]x_fifo_size

Commit 8865d22656b4 ("net: stmmac: Specify hardware capability value
when FIFO size isn't specified") modified the behaviour to bail out if
both the FIFO size and the hardware capability were both set to zero.
However devices where has_gmac4 and has_xgmac are both false don't use
the fifo size and that commit breaks platforms for which these values
were zero.

Only warn and error out when (has_gmac4 || has_xgmac) where the values
are used and zero would cause problems, otherwise continue with the zero
values.

Fixes: 8865d22656b4 ("net: stmmac: Specify hardware capability value when FIFO size isn't specified")
Signed-off-by: Steven Price <steven.price@arm.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d04543e5697b..821404beb629 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7222,7 +7222,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
 	if (!priv->plat->rx_fifo_size) {
 		if (priv->dma_cap.rx_fifo_size) {
 			priv->plat->rx_fifo_size = priv->dma_cap.rx_fifo_size;
-		} else {
+		} else if (priv->plat->has_gmac4 || priv->plat->has_xgmac) {
 			dev_err(priv->device, "Can't specify Rx FIFO size\n");
 			return -ENODEV;
 		}
@@ -7236,7 +7236,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
 	if (!priv->plat->tx_fifo_size) {
 		if (priv->dma_cap.tx_fifo_size) {
 			priv->plat->tx_fifo_size = priv->dma_cap.tx_fifo_size;
-		} else {
+		} else if (priv->plat->has_gmac4 || priv->plat->has_xgmac) {
 			dev_err(priv->device, "Can't specify Tx FIFO size\n");
 			return -ENODEV;
 		}
-- 
2.39.5



  reply	other threads:[~2025-01-31 15:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27  1:38 [PATCH net v4 0/3] Limit devicetree parameters to hardware capability Kunihiko Hayashi
2025-01-27  1:38 ` [PATCH net v4 1/3] net: stmmac: Limit the number of MTL queues " Kunihiko Hayashi
2025-01-27 18:07   ` Yanteng Si
2025-01-27  1:38 ` [PATCH net v4 2/3] net: stmmac: Limit FIFO size by " Kunihiko Hayashi
2025-01-27 18:11   ` Yanteng Si
2025-01-27  1:38 ` [PATCH net v4 3/3] net: stmmac: Specify hardware capability value when FIFO size isn't specified Kunihiko Hayashi
2025-01-27 18:24   ` Yanteng Si
2025-01-31  9:46   ` Steven Price
2025-01-31 14:15     ` Andrew Lunn
2025-01-31 14:33       ` Steven Price
2025-01-31 14:47         ` Andrew Lunn
2025-01-31 15:03           ` Steven Price
2025-01-31 15:29             ` Andrew Lunn
2025-01-31 15:54               ` Steven Price [this message]
2025-01-31 16:07                 ` Andrew Lunn
2025-02-01 12:10                 ` Xi Ruoyao
2025-02-01 21:03                 ` Andrew Lunn
2025-02-01 19:14   ` Guenter Roeck
2025-02-01 19:21     ` Andrew Lunn
2025-02-01 20:25       ` Guenter Roeck
2025-02-01 20:35     ` Russell King (Oracle)
2025-02-01 22:02       ` Guenter Roeck
2025-02-03  2:45       ` Kunihiko Hayashi
2025-02-03  9:23         ` Russell King (Oracle)
2025-02-03 11:32           ` Kunihiko Hayashi
2025-02-03 11:55             ` Kunihiko Hayashi
2025-01-28 12:20 ` [PATCH net v4 0/3] Limit devicetree parameters to hardware capability patchwork-bot+netdevbpf

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=915713e1-b67f-4eae-82c6-8dceae8f97a7@arm.com \
    --to=steven.price@arm.com \
    --cc=0x1207@gmail.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=si.yanteng@linux.dev \
    /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