[PATCH net-next 0/7] net: stmmac: fixes and new features

[PATCH net-next 0/7] net: stmmac: fixes and new features

[Konrad Leszczynski]

This series starts with three fixes addressing KASAN panic on ethtool
usage, Enhanced Descriptor printing and flow stop on TC block setup when
interface down.
Everything that follows adds new features such as ARP Offload support,
VLAN protocol detection and TC flower filter support.

Karol Jurczenia (4):
  net: stmmac: check if interface is running before TC block setup
  net: stmmac: enable ARP Offload on mac_link_up()
  net: stmmac: set TE/RE bits for ARP Offload when interface down
  net: stmmac: add TC flower filter support for IP EtherType

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

Piotr Warpechowski (2):
  net: stmmac: correct Tx descriptors debugfs prints
  net: stmmac: enhance VLAN protocol detection for GRO

 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
 .../ethernet/stmicro/stmmac/stmmac_ethtool.c  |  2 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 68 +++++++++++++++----
 .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 +++++-
 include/linux/stmmac.h                        |  1 +
 5 files changed, 76 insertions(+), 15 deletions(-)

-- 
2.34.1

[PATCH net-next 1/7] 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]

Reviewed-by: Sebastian Basierski <sebastian.basierski@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 f702f7b7bf9f..219a2df578ae 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -795,7 +795,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

Re: [PATCH net-next 1/7] net: stmmac: replace memcpy with strscpy in ethtool

[Simon Horman]

+ Kees

On Tue, Aug 26, 2025 at 01:32:41PM +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
> 
> [  +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]
> 
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>

Hi Konrad,

As mentioned by Vadim elsewhere, as this is a fix it should
be part of a separate series targeted at net.

And it should have a Fixes tag.

Also, as a follow-up for net-next, it might be nice
to move stmmac_get_strings() to use an appropriate combination
of ethtool_puts() and ethtool_cpu().

See: commit 151e13ece86d ("net: ethtool: Adjust exactly ETH_GSTRING_LEN-long stats to use memcpy")

The code change itself looks good to me.

> ---
>  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 f702f7b7bf9f..219a2df578ae 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -795,7 +795,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-next 2/7] 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.

Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Signed-off-by: Piotr Warpechowski <piotr.warpechowski@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 b948df1bff9a..bda1a83607c0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6349,14 +6349,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++;
+		}
 	}
 }
 
@@ -6396,7 +6407,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-next 3/7] 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.

Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@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 bda1a83607c0..9cf7f85c10b6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6245,6 +6245,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

[PATCH net-next 4/7] net: stmmac: enable ARP Offload on mac_link_up()

[Konrad Leszczynski]

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

Add Address Resolution Protocol (ARP) Offload support in
stmmac_mac_link_up() to enable ARP Offload beside the selftests.

Introduce STMMAC_FLAG_ARP_OFFLOAD_EN flag, which is used to enable the
feature with the stmmac_set_arp_offload().

Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c   | 17 +++++++++++++++++
 include/linux/stmmac.h                          |  1 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9cf7f85c10b6..e000dc7f0349 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -39,6 +39,7 @@
 #include <linux/phylink.h>
 #include <linux/udp.h>
 #include <linux/bpf_trace.h>
+#include <linux/inetdevice.h>
 #include <net/page_pool/helpers.h>
 #include <net/pkt_cls.h>
 #include <net/xdp_sock_drv.h>
@@ -963,6 +964,8 @@ static void stmmac_mac_link_up(struct phylink_config *config,
 			       bool tx_pause, bool rx_pause)
 {
 	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
+	struct in_device *in_dev;
+	struct in_ifaddr *ifa;
 	unsigned int flow_ctrl;
 	u32 old_ctrl, ctrl;
 	int ret;
@@ -1075,6 +1078,20 @@ static void stmmac_mac_link_up(struct phylink_config *config,
 
 	if (priv->plat->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
 		stmmac_hwtstamp_correct_latency(priv, priv);
+
+	if (priv->plat->flags & STMMAC_FLAG_ARP_OFFLOAD_EN) {
+		in_dev = in_dev_get(priv->dev);
+		if (!in_dev)
+			return;
+
+		ifa = in_dev->ifa_list;
+		if (!ifa)
+			return;
+
+		stmmac_set_arp_offload(priv, priv->hw, true,
+				       ntohl(ifa->ifa_address));
+		in_dev_put(in_dev);
+	}
 }
 
 static void stmmac_mac_disable_tx_lpi(struct phylink_config *config)
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 26ddf95d23f9..aae522f37710 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -185,6 +185,7 @@ struct dwmac4_addrs {
 #define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(11)
 #define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP	BIT(12)
 #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(13)
+#define STMMAC_FLAG_ARP_OFFLOAD_EN		BIT(14)
 
 struct plat_stmmacenet_data {
 	int bus_id;
-- 
2.34.1

Re: [PATCH net-next 4/7] net: stmmac: enable ARP Offload on mac_link_up()

[kernel test robot]

Hi Konrad,

kernel test robot noticed the following build errors:

[auto build test ERROR on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Konrad-Leszczynski/net-stmmac-replace-memcpy-with-strscpy-in-ethtool/20250826-193732
base:   net-next/main
patch link:    https://lore.kernel.org/r/20250826113247.3481273-5-konrad.leszczynski%40intel.com
patch subject: [PATCH net-next 4/7] net: stmmac: enable ARP Offload on mac_link_up()
config: arm-randconfig-004-20250826 (https://download.01.org/0day-ci/archive/20250827/202508270007.sExKFhrN-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 10.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250827/202508270007.sExKFhrN-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202508270007.sExKFhrN-lkp@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "in_dev_finish_destroy" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH net-next 4/7] net: stmmac: enable ARP Offload on mac_link_up()

[Simon Horman]

On Tue, Aug 26, 2025 at 01:32:44PM +0200, Konrad Leszczynski wrote:
> From: Karol Jurczenia <karol.jurczenia@intel.com>
> 
> Add Address Resolution Protocol (ARP) Offload support in
> stmmac_mac_link_up() to enable ARP Offload beside the selftests.
> 
> Introduce STMMAC_FLAG_ARP_OFFLOAD_EN flag, which is used to enable the
> feature with the stmmac_set_arp_offload().
> 
> Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>

Konrad,

AFAIK, as you are posting this patches, your SoB line needs to go here.
(And correspondingly, your Reviewed-by line should be removed.)

...

> @@ -1075,6 +1078,20 @@ static void stmmac_mac_link_up(struct phylink_config *config,
>  
>  	if (priv->plat->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
>  		stmmac_hwtstamp_correct_latency(priv, priv);
> +
> +	if (priv->plat->flags & STMMAC_FLAG_ARP_OFFLOAD_EN) {
> +		in_dev = in_dev_get(priv->dev);
> +		if (!in_dev)
> +			return;
> +
> +		ifa = in_dev->ifa_list;

ifa_list is protected by RCU, so I think the code needs to take that into
account. E.g. by doing the following and making sure that the RCU read lock
is held.

		ifa = rcu_dereference(idev->ifa_list);

Flagged by Sparse.


> +		if (!ifa)
> +			return;
> +
> +		stmmac_set_arp_offload(priv, priv->hw, true,
> +				       ntohl(ifa->ifa_address));
> +		in_dev_put(in_dev);
> +	}
>  }
>  
>  static void stmmac_mac_disable_tx_lpi(struct phylink_config *config)
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 26ddf95d23f9..aae522f37710 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -185,6 +185,7 @@ struct dwmac4_addrs {
>  #define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(11)
>  #define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP	BIT(12)
>  #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(13)
> +#define STMMAC_FLAG_ARP_OFFLOAD_EN		BIT(14)

I see that the following patch in this series also makes use of this bit.
But I don't see any thing (platform) that sets this bit. Perhaps I'm
missing something. But I think that would be best included in the patchset
that adds this bit.

>  
>  struct plat_stmmacenet_data {
>  	int bus_id;
> -- 
> 2.34.1
> 
> 

[PATCH net-next 5/7] net: stmmac: set TE/RE bits for ARP Offload when interface down

[Konrad Leszczynski]

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

When the network interface is brought down and ARP Offload is enabled,
set the TE (Transmitter Enable) and RE (Receiver Enable) bits.

Ensure that the Network Interface Card (NIC) can continue handling ARP
responses in hardware even when the interface is down.

Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e000dc7f0349..3823432b16f1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -949,7 +949,9 @@ static void stmmac_mac_link_down(struct phylink_config *config,
 {
 	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
 
-	stmmac_mac_set(priv, priv->ioaddr, false);
+	if (!(priv->plat->flags & STMMAC_FLAG_ARP_OFFLOAD_EN))
+		stmmac_mac_set(priv, priv->ioaddr, false);
+
 	if (priv->dma_cap.eee)
 		stmmac_set_eee_pls(priv, priv->hw, false);
 
@@ -4178,6 +4180,10 @@ static int stmmac_release(struct net_device *dev)
 	/* Release and free the Rx/Tx resources */
 	free_dma_desc_resources(priv, &priv->dma_conf);
 
+	/* Disable MAC Rx/Tx */
+	stmmac_mac_set(priv, priv->ioaddr, priv->plat->flags &
+					   STMMAC_FLAG_ARP_OFFLOAD_EN);
+
 	/* Powerdown Serdes if there is */
 	if (priv->plat->serdes_powerdown)
 		priv->plat->serdes_powerdown(dev, priv->plat->bsp_priv);
-- 
2.34.1

[PATCH net-next 6/7] net: stmmac: enhance VLAN protocol detection for GRO

[Konrad Leszczynski]

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

Enhance protocol extraction in stmmac_has_ip_ethertype() by introducing
MAC offset parameter and changing:

__vlan_get_protocol() ->  __vlan_get_protocol_offset()

Add correct header length for VLAN tags, which enable Generic Receive
Offload (GRO) in VLAN.

Co-developed-by: Karol Jurczenia <karol.jurczenia@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Signed-off-by: Piotr Warpechowski <piotr.warpechowski@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3823432b16f1..5ef78fb3f900 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4585,13 +4585,14 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
  */
 static bool stmmac_has_ip_ethertype(struct sk_buff *skb)
 {
-	int depth = 0;
+	int depth = 0, hlen;
 	__be16 proto;
 
-	proto = __vlan_get_protocol(skb, eth_header_parse_protocol(skb),
-				    &depth);
+	proto = __vlan_get_protocol_offset(skb, skb->protocol,
+					   skb_mac_offset(skb), &depth);
+	hlen = eth_type_vlan(skb->protocol) ? VLAN_ETH_HLEN : ETH_HLEN;
 
-	return (depth <= ETH_HLEN) &&
+	return (depth <= hlen) &&
 		(proto == htons(ETH_P_IP) || proto == htons(ETH_P_IPV6));
 }
 
-- 
2.34.1

Re: [PATCH net-next 6/7] net: stmmac: enhance VLAN protocol detection for GRO

[Simon Horman]

On Tue, Aug 26, 2025 at 01:32:46PM +0200, Konrad Leszczynski wrote:
> From: Piotr Warpechowski <piotr.warpechowski@intel.com>
> 
> Enhance protocol extraction in stmmac_has_ip_ethertype() by introducing
> MAC offset parameter and changing:
> 
> __vlan_get_protocol() ->  __vlan_get_protocol_offset()
> 
> Add correct header length for VLAN tags, which enable Generic Receive
> Offload (GRO) in VLAN.
> 
> Co-developed-by: Karol Jurczenia <karol.jurczenia@intel.com>
> Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
> Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Signed-off-by: Piotr Warpechowski <piotr.warpechowski@intel.com>

Konrad,

As per my comment on an earlier patch, your SoB line needs to go here.

Otherwise, this looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

...

[PATCH net-next 7/7] net: stmmac: add TC flower filter support for IP EtherType

[Konrad Leszczynski]

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

Add missing Traffic Control (TC) offload for flower filters matching the
IP EtherType (ETH_P_IP).

Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 19 ++++++++++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index cda09cf5dcca..8397f2ac63fc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -206,6 +206,7 @@ enum stmmac_rfs_type {
 	STMMAC_RFS_T_VLAN,
 	STMMAC_RFS_T_LLDP,
 	STMMAC_RFS_T_1588,
+	STMMAC_RFS_T_IP,
 	STMMAC_RFS_T_MAX,
 };
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
index 694d6ee14381..c5577652d6ed 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
@@ -239,6 +239,7 @@ static int tc_rfs_init(struct stmmac_priv *priv)
 	priv->rfs_entries_max[STMMAC_RFS_T_VLAN] = 8;
 	priv->rfs_entries_max[STMMAC_RFS_T_LLDP] = 1;
 	priv->rfs_entries_max[STMMAC_RFS_T_1588] = 1;
+	priv->rfs_entries_max[STMMAC_RFS_T_IP] = 32;
 
 	for (i = 0; i < STMMAC_RFS_T_MAX; i++)
 		priv->rfs_entries_total += priv->rfs_entries_max[i];
@@ -777,6 +778,17 @@ static int tc_add_ethtype_flow(struct stmmac_priv *priv,
 			stmmac_rx_queue_routing(priv, priv->hw,
 						PACKET_PTPQ, tc);
 			break;
+		case ETH_P_IP:
+			if (priv->rfs_entries_cnt[STMMAC_RFS_T_IP] >=
+			    priv->rfs_entries_max[STMMAC_RFS_T_IP])
+				return -ENOENT;
+
+			entry->type = STMMAC_RFS_T_IP;
+			priv->rfs_entries_cnt[STMMAC_RFS_T_IP]++;
+
+			stmmac_rx_queue_routing(priv, priv->hw,
+						PACKET_UPQ, tc);
+			break;
 		default:
 			netdev_err(priv->dev, "EthType(0x%x) is not supported", etype);
 			return -EINVAL;
@@ -800,7 +812,7 @@ static int tc_del_ethtype_flow(struct stmmac_priv *priv,
 
 	if (!entry || !entry->in_use ||
 	    entry->type < STMMAC_RFS_T_LLDP ||
-	    entry->type > STMMAC_RFS_T_1588)
+	    entry->type > STMMAC_RFS_T_IP)
 		return -ENOENT;
 
 	switch (entry->etype) {
@@ -814,6 +826,11 @@ static int tc_del_ethtype_flow(struct stmmac_priv *priv,
 					PACKET_PTPQ, 0);
 		priv->rfs_entries_cnt[STMMAC_RFS_T_1588]--;
 		break;
+	case ETH_P_IP:
+		stmmac_rx_queue_routing(priv, priv->hw,
+					PACKET_UPQ, 0);
+		priv->rfs_entries_cnt[STMMAC_RFS_T_IP]--;
+		break;
 	default:
 		netdev_err(priv->dev, "EthType(0x%x) is not supported",
 			   entry->etype);
-- 
2.34.1

Re: [PATCH net-next 7/7] net: stmmac: add TC flower filter support for IP EtherType

[Simon Horman]

On Tue, Aug 26, 2025 at 01:32:47PM +0200, Konrad Leszczynski wrote:
> From: Karol Jurczenia <karol.jurczenia@intel.com>
> 
> Add missing Traffic Control (TC) offload for flower filters matching the
> IP EtherType (ETH_P_IP).
> 
> Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
> Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>

Konrad,

As per my comment on an earlier patch, your SoB line needs to go here.

Otherwise, this looks good to me.

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net-next 7/7] net: stmmac: add TC flower filter support for IP EtherType

[Konrad Leszczynski]

On 27-Aug-25 21:37, Simon Horman wrote:
> On Tue, Aug 26, 2025 at 01:32:47PM +0200, Konrad Leszczynski wrote:
>> From: Karol Jurczenia <karol.jurczenia@intel.com>
>>
>> Add missing Traffic Control (TC) offload for flower filters matching the
>> IP EtherType (ETH_P_IP).
>>
>> Reviewed-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
>> Reviewed-by: Sebastian Basierski <sebastian.basierski@intel.com>
>> Signed-off-by: Karol Jurczenia <karol.jurczenia@intel.com>
> Konrad,
>
> As per my comment on an earlier patch, your SoB line needs to go here.
>
> Otherwise, this looks good to me.
>
> Reviewed-by: Simon Horman <horms@kernel.org>

Hi Simon, thanks for the review. I'll split the patchset into two to and 
address all your comments.

Re: [PATCH net-next 0/7] net: stmmac: fixes and new features

[Vadim Fedorenko]

On 26/08/2025 12:32, Konrad Leszczynski wrote:
> This series starts with three fixes addressing KASAN panic on ethtool
> usage, Enhanced Descriptor printing and flow stop on TC block setup when
> interface down.
> Everything that follows adds new features such as ARP Offload support,
> VLAN protocol detection and TC flower filter support.

Well, mixing fixes and features in one patchset is not a great idea.
Fixes patches should have Fixes: tags and go to -net tree while features
should go to net-next. It's better to split series into 2 and provide
proper tags for the "fixes" part

Re: [PATCH net-next 0/7] net: stmmac: fixes and new features

[Konrad Leszczynski]

On 26-Aug-25 19:29, Vadim Fedorenko wrote:
> On 26/08/2025 12:32, Konrad Leszczynski wrote:
>> This series starts with three fixes addressing KASAN panic on ethtool
>> usage, Enhanced Descriptor printing and flow stop on TC block setup when
>> interface down.
>> Everything that follows adds new features such as ARP Offload support,
>> VLAN protocol detection and TC flower filter support.
>
> Well, mixing fixes and features in one patchset is not a great idea.
> Fixes patches should have Fixes: tags and go to -net tree while features
> should go to net-next. It's better to split series into 2 and provide
> proper tags for the "fixes" part

Hi Vadim,

Thanks for the review. I've specifically placed the fixes first and the 
features afterwards to not intertwine the patches. I can split them into 
two patchsets if you think that's the best way to go.

Re: [PATCH net-next 0/7] net: stmmac: fixes and new features

[Andrew Lunn]

On Thu, Aug 28, 2025 at 08:47:02AM +0200, Konrad Leszczynski wrote:
> 
> On 26-Aug-25 19:29, Vadim Fedorenko wrote:
> > On 26/08/2025 12:32, Konrad Leszczynski wrote:
> > > This series starts with three fixes addressing KASAN panic on ethtool
> > > usage, Enhanced Descriptor printing and flow stop on TC block setup when
> > > interface down.
> > > Everything that follows adds new features such as ARP Offload support,
> > > VLAN protocol detection and TC flower filter support.
> > 
> > Well, mixing fixes and features in one patchset is not a great idea.
> > Fixes patches should have Fixes: tags and go to -net tree while features
> > should go to net-next. It's better to split series into 2 and provide
> > proper tags for the "fixes" part
> 
> Hi Vadim,
> 
> Thanks for the review. I've specifically placed the fixes first and the
> features afterwards to not intertwine the patches. I can split them into two
> patchsets if you think that's the best way to go.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

You probably need to wait a week between the fixes and new features in
order that net and net-next are synced.

    Andrew

---
pw-bot: cr
	

Re: [PATCH net-next 0/7] net: stmmac: fixes and new features

[Konrad Leszczynski]

On 28-Aug-25 14:25, Andrew Lunn wrote:
> On Thu, Aug 28, 2025 at 08:47:02AM +0200, Konrad Leszczynski wrote:
>> On 26-Aug-25 19:29, Vadim Fedorenko wrote:
>>> On 26/08/2025 12:32, Konrad Leszczynski wrote:
>>>> This series starts with three fixes addressing KASAN panic on ethtool
>>>> usage, Enhanced Descriptor printing and flow stop on TC block setup when
>>>> interface down.
>>>> Everything that follows adds new features such as ARP Offload support,
>>>> VLAN protocol detection and TC flower filter support.
>>> Well, mixing fixes and features in one patchset is not a great idea.
>>> Fixes patches should have Fixes: tags and go to -net tree while features
>>> should go to net-next. It's better to split series into 2 and provide
>>> proper tags for the "fixes" part
>> Hi Vadim,
>>
>> Thanks for the review. I've specifically placed the fixes first and the
>> features afterwards to not intertwine the patches. I can split them into two
>> patchsets if you think that's the best way to go.
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> You probably need to wait a week between the fixes and new features in
> order that net and net-next are synced.
>
>      Andrew
>
> ---
> pw-bot: cr
> 	

Hi Andrew. Thanks for the heads-up. Fixes are new features are 
independent from each other. Should I still wait a week to send out the 
patchset containing the new features?

Konrad

Re: [PATCH net-next 0/7] net: stmmac: fixes and new features

[Vadim Fedorenko]

On 28/08/2025 13:51, Konrad Leszczynski wrote:
> 
> On 28-Aug-25 14:25, Andrew Lunn wrote:
>> On Thu, Aug 28, 2025 at 08:47:02AM +0200, Konrad Leszczynski wrote:
>>> On 26-Aug-25 19:29, Vadim Fedorenko wrote:
>>>> On 26/08/2025 12:32, Konrad Leszczynski wrote:
>>>>> This series starts with three fixes addressing KASAN panic on ethtool
>>>>> usage, Enhanced Descriptor printing and flow stop on TC block setup 
>>>>> when
>>>>> interface down.
>>>>> Everything that follows adds new features such as ARP Offload support,
>>>>> VLAN protocol detection and TC flower filter support.
>>>> Well, mixing fixes and features in one patchset is not a great idea.
>>>> Fixes patches should have Fixes: tags and go to -net tree while 
>>>> features
>>>> should go to net-next. It's better to split series into 2 and provide
>>>> proper tags for the "fixes" part
>>> Hi Vadim,
>>>
>>> Thanks for the review. I've specifically placed the fixes first and the
>>> features afterwards to not intertwine the patches. I can split them 
>>> into two
>>> patchsets if you think that's the best way to go.
>> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>>
>> You probably need to wait a week between the fixes and new features in
>> order that net and net-next are synced.
>>
>>      Andrew
>>
>> ---
>> pw-bot: cr
>>
> 
> Hi Andrew. Thanks for the heads-up. Fixes are new features are 
> independent from each other. Should I still wait a week to send out the 
> patchset containing the new features?

If they are totally independent then there is no reason to wait for a week.
But be sure to base fixes on top of net.git while features on top of
net-next.git and put appropriate prefix in the patch subject.

Re: [PATCH net-next 0/7] net: stmmac: fixes and new features

[Andrew Lunn]

On Thu, Aug 28, 2025 at 02:51:51PM +0200, Konrad Leszczynski wrote:
> 
> On 28-Aug-25 14:25, Andrew Lunn wrote:
> > On Thu, Aug 28, 2025 at 08:47:02AM +0200, Konrad Leszczynski wrote:
> > > On 26-Aug-25 19:29, Vadim Fedorenko wrote:
> > > > On 26/08/2025 12:32, Konrad Leszczynski wrote:
> > > > > This series starts with three fixes addressing KASAN panic on ethtool
> > > > > usage, Enhanced Descriptor printing and flow stop on TC block setup when
> > > > > interface down.
> > > > > Everything that follows adds new features such as ARP Offload support,
> > > > > VLAN protocol detection and TC flower filter support.
> > > > Well, mixing fixes and features in one patchset is not a great idea.
> > > > Fixes patches should have Fixes: tags and go to -net tree while features
> > > > should go to net-next. It's better to split series into 2 and provide
> > > > proper tags for the "fixes" part
> > > Hi Vadim,
> > > 
> > > Thanks for the review. I've specifically placed the fixes first and the
> > > features afterwards to not intertwine the patches. I can split them into two
> > > patchsets if you think that's the best way to go.
> > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> > 
> > You probably need to wait a week between the fixes and new features in
> > order that net and net-next are synced.
> > 
> >      Andrew
> > 
> > ---
> > pw-bot: cr
> > 	
> 
> Hi Andrew. Thanks for the heads-up. Fixes are new features are independent
> from each other. Should I still wait a week to send out the patchset
> containing the new features?

What you want to avoid is causing the netdev Maintainers to resolve
merge conflicts when net-next and net are merged. By waiting a week,
you get to resolve such conflicts.

    Andrew