[PATCH net 0/3] net: stmmac: Misc fixes

[PATCH net 0/3] net: stmmac: Misc fixes

[Jose Abreu]

Some misc fixes for stmmac targeting -net.

Cc: Joao Pinto <jpinto@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>

Jose Abreu (3):
  net: stmmac: Fallback to Platform Data clock in Watchdog conversion
  net: stmmac: Send TSO packets always from Queue 0
  net: stmmac: Disable EEE mode earlier in XMIT callback

 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 14 ++++++++++----
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c    | 17 +++++++++++++----
 include/linux/stmmac.h                               |  1 +
 3 files changed, 24 insertions(+), 8 deletions(-)

-- 
2.7.4

Re: [PATCH net 0/3] net: stmmac: Misc fixes

[Corentin Labbe]

On Wed, Jan 30, 2019 at 03:54:18PM +0100, Jose Abreu wrote:
> Some misc fixes for stmmac targeting -net.
> 
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> 
> Jose Abreu (3):
>   net: stmmac: Fallback to Platform Data clock in Watchdog conversion
>   net: stmmac: Send TSO packets always from Queue 0
>   net: stmmac: Disable EEE mode earlier in XMIT callback
> 
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 14 ++++++++++----
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c    | 17 +++++++++++++----
>  include/linux/stmmac.h                               |  1 +
>  3 files changed, 24 insertions(+), 8 deletions(-)
> 
> -- 
> 2.7.4
> 

Hello

Could you CC linux-kernel@vger.kernel.org when you send patch. (as asked by get_maintainer.pl)
By avoiding it, your patchset is not stored on lore nor is handled by all checkbots reading lkml.

Thanks
Regards

Re: [PATCH net 0/3] net: stmmac: Misc fixes

[David Miller]

From: Jose Abreu <jose.abreu@synopsys.com>
Date: Wed, 30 Jan 2019 15:54:18 +0100

> Some misc fixes for stmmac targeting -net.

Series applied.

Re: [PATCH net 0/3] net: stmmac: Misc fixes

[Niklas Cassel]

On Wed, Jan 30, 2019 at 03:54:18PM +0100, Jose Abreu wrote:
> 
> Some misc fixes for stmmac targeting -net.
> 
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> 
> Jose Abreu (3):
>   net: stmmac: Fallback to Platform Data clock in Watchdog conversion
>   net: stmmac: Send TSO packets always from Queue 0
>   net: stmmac: Disable EEE mode earlier in XMIT callback

Hello Jose,

Thanks for your great work of improving the stmmac driver.

Unfortunately, I'm seeing that a lot of important stmmac fixes
aren't getting backported to stable kernels.


I think that the problem is that a lot of stmmac commit messages do
not clearly indicate what happens if these patches are not included.

See netdev FAQ:

Q: I have created a network patch and I think it should be backported to
   stable.  Should I add a "Cc: stable@vger.kernel.org" like the references
   in the kernel's Documentation/ directory say?

A: No.  See above answer.  In short, if you think it really belongs in
   stable, then ensure you write a decent commit log that describes who
   gets impacted by the bugfix and how it manifests itself, and when the
   bug was introduced.  If you do that properly, then the commit will
   get handled appropriately and most likely get put in the patchworks
   stable queue if it really warrants it.



Could you please tell me what happens if I don't include
"net: stmmac: Disable EEE mode earlier in XMIT callback" ?


likewise if I don't include "net: stmmac: Send TSO packets always from
Queue 0" ?

I assume that I will get a TX timeout if I try to send a TSO packet
from a queue that does not support it?

Also, we already define the TX queues in the snps,mtl-tx-config:
Documentation/devicetree/bindings/net/stmmac.txt

Wouldn't it be possible to add a snps,tso-capable property for each tx
queue node that supports tso?


Kind regards,
Niklas

> 
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 14 ++++++++++----
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c    | 17 +++++++++++++----
>  include/linux/stmmac.h                               |  1 +
>  3 files changed, 24 insertions(+), 8 deletions(-)
> 
> -- 
> 2.7.4
> 

Re: [PATCH net 0/3] net: stmmac: Misc fixes

[Jose Abreu]

Hi Niklas,

On 2/5/2019 10:05 PM, Niklas Cassel wrote:
> On Wed, Jan 30, 2019 at 03:54:18PM +0100, Jose Abreu wrote:
>>
>> Some misc fixes for stmmac targeting -net.
>>
>> Cc: Joao Pinto <jpinto@synopsys.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> Cc: Alexandre Torgue <alexandre.torgue@st.com>
>>
>> Jose Abreu (3):
>>   net: stmmac: Fallback to Platform Data clock in Watchdog conversion
>>   net: stmmac: Send TSO packets always from Queue 0
>>   net: stmmac: Disable EEE mode earlier in XMIT callback
> 
> Hello Jose,
> 
> Thanks for your great work of improving the stmmac driver.
> 
> Unfortunately, I'm seeing that a lot of important stmmac fixes
> aren't getting backported to stable kernels.
> 
> 
> I think that the problem is that a lot of stmmac commit messages do
> not clearly indicate what happens if these patches are not included.
> 
> See netdev FAQ:
> 
> Q: I have created a network patch and I think it should be backported to
>    stable.  Should I add a "Cc: stable@vger.kernel.org" like the references
>    in the kernel's Documentation/ directory say?
> 
> A: No.  See above answer.  In short, if you think it really belongs in
>    stable, then ensure you write a decent commit log that describes who
>    gets impacted by the bugfix and how it manifests itself, and when the
>    bug was introduced.  If you do that properly, then the commit will
>    get handled appropriately and most likely get put in the patchworks
>    stable queue if it really warrants it.

I will try to add a Fixes tag and explain more carefully the next
time. Sorry.

> 
> 
> 
> Could you please tell me what happens if I don't include
> "net: stmmac: Disable EEE mode earlier in XMIT callback" ?

Probably a drop in performance. Not critical though.

> 
> 
> likewise if I don't include "net: stmmac: Send TSO packets always from
> Queue 0" ?

In my tests I get a drop in performance also.

> 
> I assume that I will get a TX timeout if I try to send a TSO packet
> from a queue that does not support it?

No. Packets will still be sent but they will not be TSO packets.

> 
> Also, we already define the TX queues in the snps,mtl-tx-config:
> Documentation/devicetree/bindings/net/stmmac.txt
> 
> Wouldn't it be possible to add a snps,tso-capable property for each tx
> queue node that supports tso?

Yes but that would be more like a -next improvement.

Thanks,
Jose Miguel Abreu

> 
> 
> Kind regards,
> Niklas
> 
>>
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 14 ++++++++++----
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c    | 17 +++++++++++++----
>>  include/linux/stmmac.h                               |  1 +
>>  3 files changed, 24 insertions(+), 8 deletions(-)
>>
>> -- 
>> 2.7.4
>>

[PATCH net 0/3] net: stmmac: misc fixes

[Konrad Leszczynski]

This series adds three fixes addressing KASAN panic on ethtool usage,
Enhanced Descriptor printing and flow stop on TC block setup when
interface down.

Patchset has been created as a result of discussion at [1].

[1] https://lore.kernel.org/netdev/20250826113247.3481273-1-konrad.leszczynski@intel.com/

v1 -> v2:
- add missing Fixes lines
- add missing SoB lines
- removed all non-fix patches. These will be sent in a separate series

Karol Jurczenia (1):
  net: stmmac: check if interface is running before TC block setup

Konrad Leszczynski (1):
  net: stmmac: replace memcpy with strscpy in ethtool

Piotr Warpechowski (1):
  net: stmmac: correct Tx descriptors debugfs prints

 .../ethernet/stmicro/stmmac/stmmac_ethtool.c  |  2 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 34 ++++++++++++++-----
 2 files changed, 27 insertions(+), 9 deletions(-)

-- 
2.34.1

[PATCH net 1/3] net: stmmac: replace memcpy with strscpy in ethtool

[Konrad Leszczynski]

Fix kernel exception by replacing memcpy with strscpy when used with
safety feature strings in ethtool logic.

[  +0.000023] BUG: KASAN: global-out-of-bounds in stmmac_get_strings+0x17d/0x520 [stmmac]
[  +0.000115] Read of size 32 at addr ffffffffc0cfab20 by task ethtool/2571

[  +0.000005] Call Trace:
[  +0.000004]  <TASK>
[  +0.000003]  dump_stack_lvl+0x6c/0x90
[  +0.000016]  print_report+0xce/0x610
[  +0.000011]  ? stmmac_get_strings+0x17d/0x520 [stmmac]
[  +0.000108]  ? kasan_addr_to_slab+0xd/0xa0
[  +0.000008]  ? stmmac_get_strings+0x17d/0x520 [stmmac]
[  +0.000101]  kasan_report+0xd4/0x110
[  +0.000010]  ? stmmac_get_strings+0x17d/0x520 [stmmac]
[  +0.000102]  kasan_check_range+0x3a/0x1c0
[  +0.000010]  __asan_memcpy+0x24/0x70
[  +0.000008]  stmmac_get_strings+0x17d/0x520 [stmmac]

Fixes: 8bf993a5877e8a0a ("net: stmmac: Add support for DWMAC5 and implement Safety Features")
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 77758a7299b4..0433be4bd0c4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -752,7 +752,7 @@ static void stmmac_get_strings(struct net_device *dev, u32 stringset, u8 *data)
 				if (!stmmac_safety_feat_dump(priv,
 							&priv->sstats, i,
 							NULL, &desc)) {
-					memcpy(p, desc, ETH_GSTRING_LEN);
+					strscpy(p, desc, ETH_GSTRING_LEN);
 					p += ETH_GSTRING_LEN;
 				}
 			}
-- 
2.34.1

[PATCH net 2/3] net: stmmac: correct Tx descriptors debugfs prints

[Konrad Leszczynski]

From: Piotr Warpechowski <piotr.warpechowski@intel.com>

It was observed that extended descriptors are not printed out fully and
enhanced descriptors are completely omitted in stmmac_rings_status_show().

Correct printing according to documentation and other existing prints in
the driver.

Fixes: 79a4f4dfa69a8379 ("net: stmmac: reduce dma ring display code duplication")
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Piotr Warpechowski <piotr.warpechowski@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 31 ++++++++++++++-----
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7b16d1207b80..70c3dd88a749 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6351,14 +6351,25 @@ static void sysfs_display_ring(void *head, int size, int extend_desc,
 	desc_size = extend_desc ? sizeof(*ep) : sizeof(*p);
 	for (i = 0; i < size; i++) {
 		dma_addr = dma_phy_addr + i * desc_size;
-		seq_printf(seq, "%d [%pad]: 0x%x 0x%x 0x%x 0x%x\n",
-				i, &dma_addr,
-				le32_to_cpu(p->des0), le32_to_cpu(p->des1),
-				le32_to_cpu(p->des2), le32_to_cpu(p->des3));
-		if (extend_desc)
-			p = &(++ep)->basic;
-		else
+		if (extend_desc) {
+			seq_printf(seq, "%d [%pad]: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n",
+				   i, &dma_addr,
+				   le32_to_cpu(ep->basic.des0),
+				   le32_to_cpu(ep->basic.des1),
+				   le32_to_cpu(ep->basic.des2),
+				   le32_to_cpu(ep->basic.des3),
+				   le32_to_cpu(ep->des4),
+				   le32_to_cpu(ep->des5),
+				   le32_to_cpu(ep->des6),
+				   le32_to_cpu(ep->des7));
+			ep++;
+		} else {
+			seq_printf(seq, "%d [%pad]: 0x%x 0x%x 0x%x 0x%x\n",
+				   i, &dma_addr,
+				   le32_to_cpu(p->des0), le32_to_cpu(p->des1),
+				   le32_to_cpu(p->des2), le32_to_cpu(p->des3));
 			p++;
+		}
 	}
 }
 
@@ -6398,7 +6409,11 @@ static int stmmac_rings_status_show(struct seq_file *seq, void *v)
 			seq_printf(seq, "Extended descriptor ring:\n");
 			sysfs_display_ring((void *)tx_q->dma_etx,
 					   priv->dma_conf.dma_tx_size, 1, seq, tx_q->dma_tx_phy);
-		} else if (!(tx_q->tbs & STMMAC_TBS_AVAIL)) {
+		} else if (tx_q->tbs & STMMAC_TBS_AVAIL) {
+			seq_printf(seq, "Enhanced descriptor ring:\n");
+			sysfs_display_ring((void *)tx_q->dma_entx,
+					   priv->dma_conf.dma_tx_size, 1, seq, tx_q->dma_tx_phy);
+		} else {
 			seq_printf(seq, "Descriptor ring:\n");
 			sysfs_display_ring((void *)tx_q->dma_tx,
 					   priv->dma_conf.dma_tx_size, 0, seq, tx_q->dma_tx_phy);
-- 
2.34.1

[PATCH net 3/3] net: stmmac: check if interface is running before TC block setup

[Konrad Leszczynski]

From: Karol Jurczenia <karol.jurczenia@intel.com>

If the interface is down before setting a TC block, the queues are already
disabled and setup cannot proceed.

Fixes: 4dbbe8dde8485b89 ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser")
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 70c3dd88a749..202a157a1c90 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6247,6 +6247,9 @@ static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
 	struct stmmac_priv *priv = cb_priv;
 	int ret = -EOPNOTSUPP;
 
+	if (!netif_running(priv->dev))
+		return -EINVAL;
+
 	if (!tc_cls_can_offload_and_chain0(priv->dev, type_data))
 		return ret;
 
-- 
2.34.1

Re: [PATCH net 1/3] net: stmmac: replace memcpy with strscpy in ethtool

[Vadim Fedorenko]

On 28/08/2025 11:02, Konrad Leszczynski wrote:
> Fix kernel exception by replacing memcpy with strscpy when used with
> safety feature strings in ethtool logic.
> 
> [  +0.000023] BUG: KASAN: global-out-of-bounds in stmmac_get_strings+0x17d/0x520 [stmmac]
> [  +0.000115] Read of size 32 at addr ffffffffc0cfab20 by task ethtool/2571
> 
> [  +0.000005] Call Trace:
> [  +0.000004]  <TASK>
> [  +0.000003]  dump_stack_lvl+0x6c/0x90
> [  +0.000016]  print_report+0xce/0x610
> [  +0.000011]  ? stmmac_get_strings+0x17d/0x520 [stmmac]
> [  +0.000108]  ? kasan_addr_to_slab+0xd/0xa0
> [  +0.000008]  ? stmmac_get_strings+0x17d/0x520 [stmmac]
> [  +0.000101]  kasan_report+0xd4/0x110
> [  +0.000010]  ? stmmac_get_strings+0x17d/0x520 [stmmac]
> [  +0.000102]  kasan_check_range+0x3a/0x1c0
> [  +0.000010]  __asan_memcpy+0x24/0x70
> [  +0.000008]  stmmac_get_strings+0x17d/0x520 [stmmac]
> 
> Fixes: 8bf993a5877e8a0a ("net: stmmac: Add support for DWMAC5 and implement Safety Features")
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
> Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

Re: [PATCH net 2/3] net: stmmac: correct Tx descriptors debugfs prints

[Vadim Fedorenko]

On 28/08/2025 11:02, Konrad Leszczynski wrote:
> From: Piotr Warpechowski <piotr.warpechowski@intel.com>
> 
> It was observed that extended descriptors are not printed out fully and
> enhanced descriptors are completely omitted in stmmac_rings_status_show().
> 
> Correct printing according to documentation and other existing prints in
> the driver.
> 
> Fixes: 79a4f4dfa69a8379 ("net: stmmac: reduce dma ring display code duplication")
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
> Signed-off-by: Piotr Warpechowski <piotr.warpechowski@intel.com>
> Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

Re: [PATCH net 3/3] net: stmmac: check if interface is running before TC block setup

[Vadim Fedorenko]

On 28/08/2025 11:02, Konrad Leszczynski wrote:
> From: Karol Jurczenia <karol.jurczenia@intel.com>
> 
> If the interface is down before setting a TC block, the queues are already
> disabled and setup cannot proceed.
> 
> Fixes: 4dbbe8dde8485b89 ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser")
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
> Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
> Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
> ---
>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 70c3dd88a749..202a157a1c90 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -6247,6 +6247,9 @@ static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
>   	struct stmmac_priv *priv = cb_priv;
>   	int ret = -EOPNOTSUPP;
>   
> +	if (!netif_running(priv->dev))
> +		return -EINVAL;
> +

The check looks valid, but I'm not quite sure of the error code.
Anyways,
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

Re: [PATCH net 1/3] net: stmmac: replace memcpy with strscpy in ethtool

[Jakub Kicinski]

On Thu, 28 Aug 2025 12:02:35 +0200 Konrad Leszczynski wrote:
> Fix kernel exception by replacing memcpy with strscpy when used with
> safety feature strings in ethtool logic.
> 
> [  +0.000023] BUG: KASAN: global-out-of-bounds in stmmac_get_strings+0x17d/0x520 [stmmac]
> [  +0.000115] Read of size 32 at addr ffffffffc0cfab20 by task ethtool/2571

If you hit this with upstream code please mention which string 
is not padded. If this can't happen with upstream platforms --
there is no upstream bug. BTW ethtool_puts() is a better choice.

> Fixes: 8bf993a5877e8a0a ("net: stmmac: Add support for DWMAC5 and implement Safety Features")
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
> Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index 77758a7299b4..0433be4bd0c4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -752,7 +752,7 @@ static void stmmac_get_strings(struct net_device *dev, u32 stringset, u8 *data)
>  				if (!stmmac_safety_feat_dump(priv,
>  							&priv->sstats, i,
>  							NULL, &desc)) {
> -					memcpy(p, desc, ETH_GSTRING_LEN);
> +					strscpy(p, desc, ETH_GSTRING_LEN);
>  					p += ETH_GSTRING_LEN;
>  				}

Re: [PATCH net 2/3] net: stmmac: correct Tx descriptors debugfs prints

[Jakub Kicinski]

On Thu, 28 Aug 2025 12:02:36 +0200 Konrad Leszczynski wrote:
> It was observed that extended descriptors are not printed out fully and
> enhanced descriptors are completely omitted in stmmac_rings_status_show().
> 
> Correct printing according to documentation and other existing prints in
> the driver.
> 
> Fixes: 79a4f4dfa69a8379 ("net: stmmac: reduce dma ring display code duplication")

Sounds like an extension to me, so net-next and no Fixes

Re: [PATCH net 3/3] net: stmmac: check if interface is running before TC block setup

[Jakub Kicinski]

On Thu, 28 Aug 2025 12:02:37 +0200 Konrad Leszczynski wrote:
> If the interface is down before setting a TC block, the queues are already
> disabled and setup cannot proceed.

More context would be useful. What's the user-visible behavior before
and after? Can the device handle installing the filters while down? 
Is it just an issue of us restarting the queues when we shouldn't?
-- 
pw-bot: cr