linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: 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>
Cc: 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 09:46:41 +0000	[thread overview]
Message-ID: <07af1102-0fa7-45ad-bcbc-aef0295ceb63@arm.com> (raw)
In-Reply-To: <20250127013820.2941044-4-hayashi.kunihiko@socionext.com>

On 27/01/2025 01:38, Kunihiko Hayashi wrote:
> When Tx/Rx FIFO size is not specified in advance, the driver checks if
> the value is zero and sets the hardware capability value in functions
> where that value is used.
> 
> Consolidate the check and settings into function stmmac_hw_init() and
> remove redundant other statements.
> 
> If FIFO size is zero and the hardware capability also doesn't have upper
> limit values, return with an error message.

This patch breaks my Firefly RK3288 board. It appears that all of the 
following are true:

 * priv->plat->rx_fifo_size == 0
 * priv->dma_cap.rx_fifo_size == 0
 * priv->plat->tx_fifo_size == 0
 * priv->dma_cap.tx_fifo_size == 0

Simply removing the "return -ENODEV" lines gets this platform working 
again (and AFAICT matches the behaviour before this patch was applied).
I'm not sure whether this points to another bug causing these to 
all be zero or if this is just an oversight. The below patch gets my 
board working:

-----8<-----
From 5097d29181f320875d29da8fc24e6d3ae44db581 Mon Sep 17 00:00:00 2001
From: Steven Price <steven.price@arm.com>
Date: Fri, 31 Jan 2025 09:32:17 +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 there are platforms out there (e.g. RK3288) where this is the
case which this breaks.

Remove the error return and use the dma_cap value as is.

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 | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d04543e5697b..41c837c91811 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7220,12 +7220,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 {
-			dev_err(priv->device, "Can't specify Rx FIFO size\n");
-			return -ENODEV;
-		}
+		priv->plat->rx_fifo_size = priv->dma_cap.rx_fifo_size;
 	} else if (priv->dma_cap.rx_fifo_size &&
 		   priv->plat->rx_fifo_size > priv->dma_cap.rx_fifo_size) {
 		dev_warn(priv->device,
@@ -7234,12 +7229,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
 		priv->plat->rx_fifo_size = priv->dma_cap.rx_fifo_size;
 	}
 	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 {
-			dev_err(priv->device, "Can't specify Tx FIFO size\n");
-			return -ENODEV;
-		}
+		priv->plat->tx_fifo_size = priv->dma_cap.tx_fifo_size;
 	} else if (priv->dma_cap.tx_fifo_size &&
 		   priv->plat->tx_fifo_size > priv->dma_cap.tx_fifo_size) {
 		dev_warn(priv->device,
-- 
2.39.5




  parent reply	other threads:[~2025-01-31  9:48 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 [this message]
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
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=07af1102-0fa7-45ad-bcbc-aef0295ceb63@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=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;
as well as URLs for NNTP newsgroup(s).