* Re: [PATCH] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Andrew Lunn @ 2026-07-14 21:43 UTC (permalink / raw)
To: Kyle Switch
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, jianmin.wang, ming.xu, xiaolin.xu, jie.han
In-Reply-To: <20260714111203.3852126-1-kyle.switch@motor-comm.com>
On Tue, Jul 14, 2026 at 07:12:03PM +0800, Kyle Switch wrote:
> Add a driver for motorcomm yt8824 quad 2.5G ethernet phy, supports
> 2.5G/1000M/100M/10M speed.
Please take a read of:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
and set the Subject line correctly.
> +#define REG_MII_MMD_CTRL 0x0D
> +#define REG_MII_MMD_DATA 0x0E
include/uapi/linux/mii.h
#define MII_MMD_CTRL 0x0d /* MMD Access Control Register */
#define MII_MMD_DATA 0x0e /* MMD Access Data Register */
Please don't repeat something which already exists. But i also wounder
why you need these.
> +static int ytphy_write_mmd(struct phy_device *phydev,
> + u16 device, u16 reg,
> + u16 value)
> +{
> + int ret;
> +
> + ret = __phy_write(phydev, REG_MII_MMD_CTRL, device);
> + if (ret)
> + return ret;
> + ret = __phy_write(phydev, REG_MII_MMD_DATA, reg);
> + if (ret)
> + return ret;
> + ret = __phy_write(phydev, REG_MII_MMD_CTRL, device | 0x4000);
> + if (ret)
> + return ret;
> + ret = __phy_write(phydev, REG_MII_MMD_DATA, value);
> +
> + return ret;
> +}
Why are you reinventing these functions when they already exist?
> +
> /**
> * ytphy_get_wol() - report whether wake-on-lan is enabled
> * @phydev: a pointer to a &struct phy_device
> @@ -3059,99 +3187,1620 @@ static int yt8821_resume(struct phy_device *phydev)
> return yt8821_modify_utp_fiber_bmcr(phydev, BMCR_PDOWN, 0);
> }
>
> -static struct phy_driver motorcomm_phy_drvs[] = {
> - {
> - PHY_ID_MATCH_EXACT(PHY_ID_YT8511),
> - .name = "YT8511 Gigabit Ethernet",
> - .config_init = yt8511_config_init,
> - .suspend = genphy_suspend,
> - .resume = genphy_resume,
> - .read_page = yt8511_read_page,
> - .write_page = yt8511_write_page,
> - },
> - {
> - PHY_ID_MATCH_EXACT(PHY_ID_YT8521),
> - .name = "YT8521 Gigabit Ethernet",
> - .get_features = yt8521_get_features,
> - .probe = yt8521_probe,
Why are these all stoppering? diff would not remove them unless
something is changing.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Andrew Lunn @ 2026-07-14 21:46 UTC (permalink / raw)
To: Kyle Switch
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, jianmin.wang, ming.xu, xiaolin.xu, jie.han
In-Reply-To: <20260714111203.3852126-1-kyle.switch@motor-comm.com>
> +static inline int ytphy_top_write(struct phy_device *phydev, u32 regnum,
> + u16 val)
> +{
> + struct yt8521_priv *priv = phydev->priv;
> + struct mii_bus *bus = phydev->mdio.bus;
> +
> + return bus->write(bus, priv->top_phy_addr, regnum, val);
> +}
Please could you explain the architecture in detail. It seems like you
are accessing registers of some other device on the bus.
Maybe you need to use the code in phy_package.c?
Andrew
^ permalink raw reply
* Re: [PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL
From: Andrew Lunn @ 2026-07-14 22:04 UTC (permalink / raw)
To: Michael Walle
Cc: Russell King, Heiner Kallweit, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260714125008.2466023-1-mwalle@kernel.org>
On Tue, Jul 14, 2026 at 02:49:34PM +0200, Michael Walle wrote:
> The FCLF8521P2BTL is marketed as a drop in replacement for fiber
> modules using 1000Base-X autoneg towards the host as default. See the
> referenced application note, esp. question #11. Drop the 1000baseT
> capability, so 1000Base-X will eventually be used.
>
> This is esp. important if the TX_DISABLE pin is not connected on a
> board. Usually, pin is used as a reset line to the PHY on the copper
> SFP. If a bootloader expects the default mode and doesn't do any
> reconfiguration of the SFP module, a link might not be established.
>
> Link: https://www.coherent.com/resources/application-note/networking/1000base-t-sfp-faq-an-2036.pdf
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> I'm not sure, this is the correct place for the fix, nor if it goes in
> the right direction. There is a comment in
>
> /*
> * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
> * negotiation enabled, but some may be in 1000base-X - which is for the
> * PHY driver to determine.
> */
The reason Cisco SGMII is used is so you can support 10Mbps and
100Mbps, as well as 1G. If all you can do ix 1000BaseX, supporting
10/100 becomes harder. If the PHY is clever enough, it can send pause
frames to slow down the MAC. But that requires the PHY actually
converting the bitstream from the MAC back into packets, performing
packet buffering, and then creating the new bitstream at a lower
rate. Some multi-gigi PHYs do this, especially if they implement
MACSEC, but few 1G PHYs do.
Normally, if the PHY is in 1000BaseX, the PHY driver will try to
reconfigure it to SGMII. However, There are some SFPs which are stuck
in 1000BaseX, and there is no access to the PHY registers, so there is
nothing we can do.
Looking at the link you provided, this SFP has a Marvell 88E1111, and
its registers are available. So the Marvell PHY driver should
reconfigure it into SGMII mode.
Maybe look at the marvell PHY driver, and snoop what it does when it
configures the PHY.
Andrew
^ permalink raw reply
* Re: [PATCH net] net: rnpgbe: Pass an expression directly in rnpgbe_rm_adapter()
From: Andrew Lunn @ 2026-07-14 22:20 UTC (permalink / raw)
To: Markus Elfring
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, MD Danish Anwar, Michael Grzeschik, Paolo Abeni,
Uwe Kleine-König, Vadim Fedorenko, Yibo Dong, LKML,
kernel-janitors
In-Reply-To: <7958e26e-a4f9-48ee-8d79-3797016944c5@web.de>
On Sun, Jul 12, 2026 at 08:35:21PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 12 Jul 2026 20:25:10 +0200
>
> The address of a data structure member was determined before
> a corresponding null pointer check in the implementation of
> the function “rnpgbe_rm_adapter”.
Please can you show the path taken that mucse is actually NULL.
I tend to agree, that the correct change is to remove the NULL pointer
test.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next] net: mdio: Kconfig: Group mdio controller drivers in a submenu
From: Andrew Lunn @ 2026-07-14 22:24 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit, netdev, linux-kernel,
thomas.petazzoni
In-Reply-To: <20260712201739.260742-1-maxime.chevallier@bootlin.com>
On Sun, Jul 12, 2026 at 10:17:27PM +0200, Maxime Chevallier wrote:
> Currently in menuconfig, all individual drivers for MDIO bus controllers
> are directly listed under Device drivers -> Network device support.
>
> Let's group them altogether in a submenu, while keeping the dependency
> on PHYLIB.
>
> All options under the new submenu match the drivers and infrastructure
> listed under drivers/net/mdio/Kconfig.
>
> No intended functional change besides the menuconfig ordering.
Looks good to me.
Maybe also move the MDIO MUX drivers into a submenu? There are nearly
as many muxes and MDIO drivers.
Andrew
^ permalink raw reply
* Re: [PATCH nf v2] netfilter: ip6tables: set hotdrop for malformed extension header matches
From: kernel test robot @ 2026-07-14 22:26 UTC (permalink / raw)
To: Zhixing Chen, Florian Westphal, Pablo Neira Ayuso, Phil Sutter
Cc: oe-kbuild-all, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netfilter-devel, coreteam, netdev,
Zhixing Chen
In-Reply-To: <20260714032124.7042-1-running910@gmail.com>
Hi Zhixing,
kernel test robot noticed the following build warnings:
[auto build test WARNING on netfilter-nf/main]
[also build test WARNING on nf-next/main linus/master v7.2-rc3 next-20260713]
[cannot apply to linux-review/Zhixing-Chen/netfilter-ip6tables-set-hotdrop-for-malformed-extension-header-matches/20260709-143240 horms-ipvs/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Zhixing-Chen/netfilter-ip6tables-set-hotdrop-for-malformed-extension-header-matches/20260714-114506
base: https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git main
patch link: https://lore.kernel.org/r/20260714032124.7042-1-running910%40gmail.com
patch subject: [PATCH nf v2] netfilter: ip6tables: set hotdrop for malformed extension header matches
config: openrisc-allmodconfig (https://download.01.org/0day-ci/archive/20260715/202607150533.nQvx3zgH-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260715/202607150533.nQvx3zgH-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/202607150533.nQvx3zgH-lkp@intel.com/
All warnings (new ones prefixed by >>):
net/ipv6/netfilter/ip6t_ipv6header.c: In function 'ipv6header_mt6':
>> net/ipv6/netfilter/ip6t_ipv6header.c:31:13: warning: variable 'len' set but not used [-Wunused-but-set-variable=]
31 | int len;
| ^~~
vim +/len +31 net/ipv6/netfilter/ip6t_ipv6header.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 25
1d93a9cbad608f Jan Engelhardt 2007-07-07 26 static bool
62fc8051083a33 Jan Engelhardt 2009-07-07 27 ipv6header_mt6(const struct sk_buff *skb, struct xt_action_param *par)
^1da177e4c3f41 Linus Torvalds 2005-04-16 28 {
f7108a20dee44e Jan Engelhardt 2008-10-08 29 const struct ip6t_ipv6header_info *info = par->matchinfo;
^1da177e4c3f41 Linus Torvalds 2005-04-16 30 unsigned int temp;
^1da177e4c3f41 Linus Torvalds 2005-04-16 @31 int len;
^1da177e4c3f41 Linus Torvalds 2005-04-16 32 u8 nexthdr;
^1da177e4c3f41 Linus Torvalds 2005-04-16 33 unsigned int ptr;
^1da177e4c3f41 Linus Torvalds 2005-04-16 34
^1da177e4c3f41 Linus Torvalds 2005-04-16 35 /* Make sure this isn't an evil packet */
^1da177e4c3f41 Linus Torvalds 2005-04-16 36
^1da177e4c3f41 Linus Torvalds 2005-04-16 37 /* type of the 1st exthdr */
0660e03f6b18f1 Arnaldo Carvalho de Melo 2007-04-25 38 nexthdr = ipv6_hdr(skb)->nexthdr;
^1da177e4c3f41 Linus Torvalds 2005-04-16 39 /* pointer to the 1st exthdr */
^1da177e4c3f41 Linus Torvalds 2005-04-16 40 ptr = sizeof(struct ipv6hdr);
^1da177e4c3f41 Linus Torvalds 2005-04-16 41 /* available length */
^1da177e4c3f41 Linus Torvalds 2005-04-16 42 len = skb->len - ptr;
^1da177e4c3f41 Linus Torvalds 2005-04-16 43 temp = 0;
^1da177e4c3f41 Linus Torvalds 2005-04-16 44
44dde23698a7a8 Jeremy Sowden 2019-09-13 45 while (nf_ip6_ext_hdr(nexthdr)) {
3cf93c96af7adf Jan Engelhardt 2008-04-14 46 const struct ipv6_opt_hdr *hp;
3cf93c96af7adf Jan Engelhardt 2008-04-14 47 struct ipv6_opt_hdr _hdr;
^1da177e4c3f41 Linus Torvalds 2005-04-16 48 int hdrlen;
^1da177e4c3f41 Linus Torvalds 2005-04-16 49
^1da177e4c3f41 Linus Torvalds 2005-04-16 50 /* No more exthdr -> evaluate */
^1da177e4c3f41 Linus Torvalds 2005-04-16 51 if (nexthdr == NEXTHDR_NONE) {
^1da177e4c3f41 Linus Torvalds 2005-04-16 52 temp |= MASK_NONE;
^1da177e4c3f41 Linus Torvalds 2005-04-16 53 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 54 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 55 /* ESP -> evaluate */
^1da177e4c3f41 Linus Torvalds 2005-04-16 56 if (nexthdr == NEXTHDR_ESP) {
^1da177e4c3f41 Linus Torvalds 2005-04-16 57 temp |= MASK_ESP;
^1da177e4c3f41 Linus Torvalds 2005-04-16 58 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 59 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 60
^1da177e4c3f41 Linus Torvalds 2005-04-16 61 hp = skb_header_pointer(skb, ptr, sizeof(_hdr), &_hdr);
70c0eb1ca016f7 Florian Westphal 2018-09-04 62 if (!hp) {
70c0eb1ca016f7 Florian Westphal 2018-09-04 63 par->hotdrop = true;
70c0eb1ca016f7 Florian Westphal 2018-09-04 64 return false;
70c0eb1ca016f7 Florian Westphal 2018-09-04 65 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 66
^1da177e4c3f41 Linus Torvalds 2005-04-16 67 /* Calculate the header length */
7c4e36bc172ae1 Jan Engelhardt 2007-07-07 68 if (nexthdr == NEXTHDR_FRAGMENT)
^1da177e4c3f41 Linus Torvalds 2005-04-16 69 hdrlen = 8;
7c4e36bc172ae1 Jan Engelhardt 2007-07-07 70 else if (nexthdr == NEXTHDR_AUTH)
416e8126a2672f yangxingwu 2019-07-10 71 hdrlen = ipv6_authlen(hp);
^1da177e4c3f41 Linus Torvalds 2005-04-16 72 else
^1da177e4c3f41 Linus Torvalds 2005-04-16 73 hdrlen = ipv6_optlen(hp);
^1da177e4c3f41 Linus Torvalds 2005-04-16 74
^1da177e4c3f41 Linus Torvalds 2005-04-16 75 /* set the flag */
^1da177e4c3f41 Linus Torvalds 2005-04-16 76 switch (nexthdr) {
^1da177e4c3f41 Linus Torvalds 2005-04-16 77 case NEXTHDR_HOP:
^1da177e4c3f41 Linus Torvalds 2005-04-16 78 temp |= MASK_HOPOPTS;
^1da177e4c3f41 Linus Torvalds 2005-04-16 79 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 80 case NEXTHDR_ROUTING:
^1da177e4c3f41 Linus Torvalds 2005-04-16 81 temp |= MASK_ROUTING;
^1da177e4c3f41 Linus Torvalds 2005-04-16 82 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 83 case NEXTHDR_FRAGMENT:
^1da177e4c3f41 Linus Torvalds 2005-04-16 84 temp |= MASK_FRAGMENT;
^1da177e4c3f41 Linus Torvalds 2005-04-16 85 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 86 case NEXTHDR_AUTH:
^1da177e4c3f41 Linus Torvalds 2005-04-16 87 temp |= MASK_AH;
^1da177e4c3f41 Linus Torvalds 2005-04-16 88 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 89 case NEXTHDR_DEST:
^1da177e4c3f41 Linus Torvalds 2005-04-16 90 temp |= MASK_DSTOPTS;
^1da177e4c3f41 Linus Torvalds 2005-04-16 91 break;
^1da177e4c3f41 Linus Torvalds 2005-04-16 92 default:
1d93a9cbad608f Jan Engelhardt 2007-07-07 93 return false;
^1da177e4c3f41 Linus Torvalds 2005-04-16 94 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 95
^1da177e4c3f41 Linus Torvalds 2005-04-16 96 nexthdr = hp->nexthdr;
^1da177e4c3f41 Linus Torvalds 2005-04-16 97 len -= hdrlen;
^1da177e4c3f41 Linus Torvalds 2005-04-16 98 ptr += hdrlen;
aebe9616a67760 Zhixing Chen 2026-07-14 99 if (ptr > skb->len) {
aebe9616a67760 Zhixing Chen 2026-07-14 100 par->hotdrop = true;
aebe9616a67760 Zhixing Chen 2026-07-14 101 return false;
aebe9616a67760 Zhixing Chen 2026-07-14 102 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 103 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 104
7c4e36bc172ae1 Jan Engelhardt 2007-07-07 105 if (nexthdr != NEXTHDR_NONE && nexthdr != NEXTHDR_ESP)
^1da177e4c3f41 Linus Torvalds 2005-04-16 106 temp |= MASK_PROTO;
^1da177e4c3f41 Linus Torvalds 2005-04-16 107
^1da177e4c3f41 Linus Torvalds 2005-04-16 108 if (info->modeflag)
^1da177e4c3f41 Linus Torvalds 2005-04-16 109 return !((temp ^ info->matchflags ^ info->invflags)
^1da177e4c3f41 Linus Torvalds 2005-04-16 110 & info->matchflags);
^1da177e4c3f41 Linus Torvalds 2005-04-16 111 else {
^1da177e4c3f41 Linus Torvalds 2005-04-16 112 if (info->invflags)
^1da177e4c3f41 Linus Torvalds 2005-04-16 113 return temp != info->matchflags;
^1da177e4c3f41 Linus Torvalds 2005-04-16 114 else
^1da177e4c3f41 Linus Torvalds 2005-04-16 115 return temp == info->matchflags;
^1da177e4c3f41 Linus Torvalds 2005-04-16 116 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 117 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 118
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net 0/2] net/mlx5e: fix NULL derefs when RX queue mapping outlives channel reconfig
From: Rishikesh Jethwani @ 2026-07-14 22:29 UTC (permalink / raw)
To: netdev
Cc: john.fastabend, kuba, sd, davem, pabeni, edumazet, leon,
nils.juenemann, Rishikesh Jethwani
Hi all,
This series fixes two related NULL derefs in mlx5e's kTLS RX offload that
surface when a channel-count reduction (e.g. ethtool -L combined N) leaves
sockets carrying a queue index that is no longer valid
Patch 1: reject stale RX queue mapping on RX offload setup
Patch 2: guard RX resync against stale channel index
Not addressed in this series:
- Torn reads of `priv->channels` during the struct-copy publish in
`mlx5e_switch_priv_channels()`. A reader on another CPU can still
briefly observe `{new c, old num}`, so bounds-checking against a
stale `num` can pass while dereferencing the new smaller array.
Closing that window likely needs proper synchronization,
such as RCU pointer, which is a larger change and better handled
in a separate series.
- Re-homing existing offloaded sockets across a channel shrink so
`priv_rx->rxq` remains valid. Patch 2 makes this failure mode graceful
by preventing the dereference, but the offload remains functionally
broken until the socket is torn down and re-added. That looks like a
broader design question for the mlx5 maintainers.
Rishikesh Jethwani (2):
net/mlx5e: kTLS: reject stale RX queue mapping on RX offload setup
net/mlx5e: kTLS: guard RX resync against stale channel index
.../mellanox/mlx5/core/en_accel/ktls_rx.c | 24 ++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 1/2] net/mlx5e: kTLS: reject stale RX queue mapping on RX offload setup
From: Rishikesh Jethwani @ 2026-07-14 22:29 UTC (permalink / raw)
To: netdev
Cc: john.fastabend, kuba, sd, davem, pabeni, edumazet, leon,
nils.juenemann, Rishikesh Jethwani
In-Reply-To: <20260714222915.2334949-1-rjethwani@purestorage.com>
mlx5e_ktls_sk_get_rxq() treats only the -1 sentinel from
sk_rx_queue_get() as special and returns all other values unchanged.
After 'ethtool -L <dev> combined N' reduces the number of channels, a
socket can retain an sk_rx_queue_mapping from the previous
configuration that is no longer valid for the current
priv->channels.num. If TLS RX offload is then enabled for that socket,
mlx5e_ktls_add_rx() uses the stale queue index and can access a
channel outside the current array.
Preserve the existing -1 -> 0 fallback for sockets that do not yet
have a recorded RX queue, but reject queue indices that are outside
the current channel range and fail setup with -EINVAL instead. Wire
the failure through the existing err_create_tir unwind so resources
allocated earlier in mlx5e_ktls_add_rx() are released cleanly.
This addresses stale queue mappings during RX offload setup. Existing
offloaded sockets whose channel disappears after reconfiguration are
handled separately in the resync path.
Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
Link: https://lore.kernel.org/netdev/20260627210635.89769-1-nils.juenemann@gmail.com/
Reported-by: Nils Juenemann <nils.juenemann@gmail.com>
Tested-by: Nils Juenemann <nils.juenemann@gmail.com>
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
.../ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index bca45679e201..232e998a8f24 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
@@ -620,12 +620,15 @@ void mlx5e_ktls_handle_ctx_completion(struct mlx5e_icosq_wqe_info *wi)
queue_work(rule->priv->tls->rx_wq, &rule->work);
}
-static int mlx5e_ktls_sk_get_rxq(struct sock *sk)
+static int mlx5e_ktls_sk_get_rxq(struct mlx5e_priv *priv, struct sock *sk)
{
int rxq = sk_rx_queue_get(sk);
if (unlikely(rxq == -1))
- rxq = 0;
+ return 0;
+
+ if (unlikely(rxq >= priv->channels.num))
+ return -EINVAL;
return rxq;
}
@@ -673,7 +676,11 @@ int mlx5e_ktls_add_rx(struct net_device *netdev, struct sock *sk,
INIT_LIST_HEAD(&priv_rx->list);
spin_lock_init(&priv_rx->lock);
- rxq = mlx5e_ktls_sk_get_rxq(sk);
+ rxq = mlx5e_ktls_sk_get_rxq(priv, sk);
+ if (unlikely(rxq < 0)) {
+ err = rxq;
+ goto err_create_tir;
+ }
priv_rx->rxq = rxq;
priv_rx->sk = sk;
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] net/mlx5e: kTLS: guard RX resync against stale channel index
From: Rishikesh Jethwani @ 2026-07-14 22:29 UTC (permalink / raw)
To: netdev
Cc: john.fastabend, kuba, sd, davem, pabeni, edumazet, leon,
nils.juenemann, Rishikesh Jethwani
In-Reply-To: <20260714222915.2334949-1-rjethwani@purestorage.com>
An RX offloaded socket stores its channel index in priv_rx->rxq when
offload is enabled. If the channel count later shrinks, e.g. via
'ethtool -L <dev> combined N', existing offloaded sockets can still
carry a queue index from the old channel layout.
The kTLS RX resync paths index priv->channels.c[priv_rx->rxq] directly
in both resync_handle_work() and mlx5e_ktls_rx_resync(). After channel
reduction, a stale priv_rx->rxq can be out of range for the current
priv->channels.num and lead to invalid channel access.
Guard both resync sites with a bounds check on priv_rx->rxq and bail out
gracefully when the stored queue no longer exists. Account the skipped
request and, in the workqueue path, cancel the async resync request and
drop the reference taken when the work item was queued.
This complements the previous add-path fix, which rejects stale RXQ
mappings during offload setup. Existing offloaded sockets still need
protection in the resync callbacks after a channel-count reduction.
Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
Link: https://lore.kernel.org/netdev/20260627210635.89769-1-nils.juenemann@gmail.com/
Reported-by: Nils Juenemann <nils.juenemann@gmail.com>
Tested-by: Nils Juenemann <nils.juenemann@gmail.com>
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
.../ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index 232e998a8f24..c0676148a36e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
@@ -343,6 +343,13 @@ static void resync_handle_work(struct work_struct *work)
return;
}
+ if (unlikely(priv_rx->rxq >= resync->priv->channels.num)) {
+ priv_rx->rq_stats->tls_resync_req_skip++;
+ tls_offload_rx_resync_async_request_cancel(&resync->core);
+ mlx5e_ktls_priv_rx_put(priv_rx);
+ return;
+ }
+
c = resync->priv->channels.c[priv_rx->rxq];
sq = c->async_icosq;
@@ -568,6 +575,10 @@ void mlx5e_ktls_rx_resync(struct net_device *netdev, struct sock *sk,
resync->seq = seq;
priv = netdev_priv(netdev);
+ if (unlikely(priv_rx->rxq >= priv->channels.num)) {
+ priv_rx->rq_stats->tls_resync_req_skip++;
+ return;
+ }
c = priv->channels.c[priv_rx->rxq];
resync_handle_seq_match(priv_rx, c);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL
From: Michael Walle @ 2026-07-14 22:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King, Heiner Kallweit, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <c62c33be-0082-4e4a-8f13-2e14e851e975@lunn.ch>
Hi Andrew,
On Wed Jul 15, 2026 at 12:04 AM CEST, Andrew Lunn wrote:
> On Tue, Jul 14, 2026 at 02:49:34PM +0200, Michael Walle wrote:
>> The FCLF8521P2BTL is marketed as a drop in replacement for fiber
>> modules using 1000Base-X autoneg towards the host as default. See the
>> referenced application note, esp. question #11. Drop the 1000baseT
>> capability, so 1000Base-X will eventually be used.
>>
>> This is esp. important if the TX_DISABLE pin is not connected on a
>> board. Usually, pin is used as a reset line to the PHY on the copper
>> SFP. If a bootloader expects the default mode and doesn't do any
>> reconfiguration of the SFP module, a link might not be established.
>>
>> Link: https://www.coherent.com/resources/application-note/networking/1000base-t-sfp-faq-an-2036.pdf
>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>> ---
>> I'm not sure, this is the correct place for the fix, nor if it goes in
>> the right direction. There is a comment in
>>
>> /*
>> * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
>> * negotiation enabled, but some may be in 1000base-X - which is for the
>> * PHY driver to determine.
>> */
>
> The reason Cisco SGMII is used is so you can support 10Mbps and
> 100Mbps, as well as 1G. If all you can do ix 1000BaseX, supporting
> 10/100 becomes harder. If the PHY is clever enough, it can send pause
> frames to slow down the MAC. But that requires the PHY actually
> converting the bitstream from the MAC back into packets, performing
> packet buffering, and then creating the new bitstream at a lower
> rate. Some multi-gigi PHYs do this, especially if they implement
> MACSEC, but few 1G PHYs do.
>
> Normally, if the PHY is in 1000BaseX, the PHY driver will try to
> reconfigure it to SGMII. However, There are some SFPs which are stuck
> in 1000BaseX, and there is no access to the PHY registers, so there is
> nothing we can do.
>
> Looking at the link you provided, this SFP has a Marvell 88E1111, and
> its registers are available. So the Marvell PHY driver should
> reconfigure it into SGMII mode.
I figured that, but have a look at the commit message, the problem
is the non-existent TX_DISABLE line. So if linux would reconfigure
the PHY, the bootloader won't be able to use it anymore if it's not
doing a hardware reset (or reconfigure it on it's own).
I don't know what's the netdev position on that issue. You could
blame it on bad hardware. Or we could just reconfigure it if the
DT has a gpio phandle for the TX_DISABLE line, though that doesn't
mean that it is actually used to reset the module on a board reset,
or that the bootloader will do a reset.
-michael
>
> Maybe look at the marvell PHY driver, and snoop what it does when it
> configures the PHY.
>
> Andrew
^ permalink raw reply
* Re: [RFC PATCH 06/10] net: pcs: xpcs: improve SGMII AN state handling for Rockchip RK3568
From: Andrew Lunn @ 2026-07-14 22:44 UTC (permalink / raw)
To: Coia Prant
Cc: kuba, davem, edumazet, pabeni, andrew+netdev, robh, krzk+dt,
heiko, netdev, linux-rockchip, devicetree, linux-arm-kernel,
linux-phy
In-Reply-To: <20260714191341.690906-7-coiaprant@gmail.com>
On Wed, Jul 15, 2026 at 03:08:34AM +0800, Coia Prant wrote:
> Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
You do not appear to Cc: the Wangxun NIC people. It would be good to
have there comments on this change.
> Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> Signed-off-by: Coia Prant <coiaprant@gmail.com>
Please don't mix fixed and new code. Is this a real fix? Should it be
back ported to stable?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: macb: add support for 1000BASE-X autonegotiation to PCS
From: Andrew Lunn @ 2026-07-14 22:49 UTC (permalink / raw)
To: Nathan Whitehorn; +Cc: netdev
In-Reply-To: <20260714200904.70428-1-nwhitehorn@pa.msu.edu>
On Tue, Jul 14, 2026 at 04:09:04PM -0400, Nathan Whitehorn wrote:
> The current PCS code unconditionally uses SGMII autonegotiation, though
> the hardware supports both SGMII and 1000BASE-X modes. Decouple the
> choice of PCS enablement from use of the SGMII mode when running at
> gigabit rates and announce to phylink that 1000BASE-X is a supported
> operating mode. This enables direct attachment of the PCS to e.g. an
> SFP.
linux$ ./scripts/get_maintainer.pl drivers/net/ethernet/cadence/macb_main.c
"Théo Lebrun" <theo.lebrun@bootlin.com> (maintainer:ATMEL MACB ETHERNET DRIVER)
Conor Dooley <conor.dooley@microchip.com> (reviewer:ATMEL MACB ETHERNET DRIVER)
Andrew Lunn <andrew+netdev@lunn.ch> (maintainer:NETWORKING DRIVERS)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <edumazet@google.com> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <kuba@kernel.org> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <pabeni@redhat.com> (maintainer:NETWORKING DRIVERS)
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-kernel@vger.kernel.org (open list)
You did not Cc: the two developers who know the most about this
hardware.
https://docs.kernel.org/process/submitting-patches.html
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH iwl-next] idpf: add flow-based XDP fallback for FWs without Tx FIFO support
From: YiFei Zhu @ 2026-07-14 22:54 UTC (permalink / raw)
To: aleksander.lobakin
Cc: andrew+netdev, anthony.l.nguyen, davem, edumazet, horms,
intel-wired-lan, kuba, linux-kernel, netdev,
nxne.cnse.osdt.itp.upstreaming, pabeni, przemyslaw.kitszel,
YiFei Zhu
In-Reply-To: <20260708151327.1091570-1-aleksander.lobakin@intel.com>
> From the first days of XDP implementation in idpf, it relied and
> worked solely on top of the queue-based scheduling Tx mode, which
> basically means simple FIFO. However, turned out not every firmware
> supports this mode and XDP doesn't work there at all.
>
> Since the flow-based scheduling Tx mode is mandatory and supported
> by every FW, introduce a simple fallback guarded by a static key
> to not hurt the more performant mode. The FB mode generates a
> completion for each Tx descriptor and never guarantees that there
> won't be any out-of-order completions. Serialize that using a
> bitmap of completed descriptors and report contiguous blocks of
> free bits to match XDP and XSk expectations and avoid further
> code complication.
>
> The usage of a bitmap on hotpath might sound scary, but this
> fallback is able to reach around 70% of the QB mode's performance,
> which is comparable to what ice gives us. The main bottlenecks are
> unlikely()s and one completion per each descriptor, while in the QB
> mode we have one completion per batch (which might contain 64 or
> even 128 frames), plus the size of the completion descriptor is
> 8 bytes in this mode (4 bytes in the QB mode), which means a lot
> of additional PCI traffic.
>
> bloat-o-meter shows .text increase in about 2 Kb without adding new
> functions or uninlining any of the existing ones. I played a bunch
> with inlining and uninlining certain pieces or the whole fallback,
> but the compiler collapses and optimizes libeth templates so hardly
> so that each additional external call only makes things worse.
>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Tested-by: YiFei Zhu <zhuyifei@google.com>
^ permalink raw reply
* Re: [PATCH net-next v2 02/12] ax88179_178a: Add HW support for AX179A-based chips
From: Andrew Lunn @ 2026-07-14 22:58 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <20260708-ax88179a-v2-2-0800fedb2e16@birger-koblitz.de>
> + /* Initialize MII structure */
> + dev->mii.dev = dev->net;
> + dev->mii.mdio_read = ax88179_mdio_read;
> + dev->mii.mdio_write = ax88179_mdio_write;
> + dev->mii.phy_id_mask = 0xff;
> + dev->mii.reg_num_mask = 0xff;
> + dev->mii.phy_id = 0x03;
> + if (!ax179_data->is_ax88772d)
> + dev->mii.supports_gmii = 1;
O.K, so you are keeping going.
I still think mii has to die, and you need to swap to phylink.
It is a bit ugly, but there is a way around the PHYs having a totally
different API, despite the same ID register values.
Some generation of Marvel Ethernet switches set the OUI part of the
PHY ID register, but left the product part as 0. They even documented
this was intentional. We worked around it by trapping reads to
registers 2 and 3, and filling in the missing information, using an ID
from the marvel range which was not in use. We could then make the
Marvell PHY driver do the right thing.
You can do the same here. Intercept the reads to registers 2 and 3,
and return a different ID. You can then extend the PHY driver.
Andrew
^ permalink raw reply
* Re: [RFC PATCH 06/10] net: pcs: xpcs: improve SGMII AN state handling for Rockchip RK3568
From: Coia Prant @ 2026-07-14 23:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: kuba, davem, edumazet, pabeni, andrew+netdev, robh, krzk+dt,
heiko, netdev, linux-rockchip, devicetree, linux-arm-kernel,
linux-phy, Jiawen Wu, Mengyuan Lou
In-Reply-To: <464cbdf3-2e9e-43ea-b30a-75b3d1b8a188@lunn.ch>
Andrew Lunn <andrew@lunn.ch> 于2026年7月15日周三 06:44写道：
>
> On Wed, Jul 15, 2026 at 03:08:34AM +0800, Coia Prant wrote:
> > Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
>
> You do not appear to Cc: the Wangxun NIC people. It would be good to
> have there comments on this change.
I apologize; the output from get_maintainer.pl is very long. I’ve
heard that having too many recipients can cause the PATCH to be
rejected by the LKML mail server.
I have added Wangxun maintainer (Jiawen Wu <jiawenwu@trustnetic.com>
and Mengyuan Lou <mengyuanlou@net-swift.com>) to the CC list.
> > Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > Signed-off-by: Coia Prant <coiaprant@gmail.com>
>
> Please don't mix fixed and new code. Is this a real fix? Should it be
> back ported to stable?
I am not sure if this is a specific characteristic of Wangxun NICs, as
I do not have any available for testing.
The behavior of the Rockchip DW XPCS IP core matches what is described
in the commit message (even though phylink brings the link to down
based on the phydev link status).
This appears to be a bug (at least on Rockchip platforms) or Wangxun
NICs features.
However, I cannot confirm whether Wangxun NICs behave the same way.
Therefore, I have kept their code as is for now.
Could a Wangxun NICs maintainer provide some feedback based on testing?
If we can confirm that this is indeed a bug, I can submit a separate fix.
I would greatly appreciate it.
Thanks.
^ permalink raw reply
* [PATCH net v3 0/3] net: dsa: mv88e6xxx: 6141/6341 workarounds
From: Luke Howard @ 2026-07-14 23:29 UTC (permalink / raw)
To: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Andrew Lunn,
Richard Cochran
Cc: Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel,
Luke Howard
This patch series addresses three issues I found with the 88E6341
switch, which likely also apply to the 88E6141 (which is the same
chip without AVB/TSN support).
The first was a genuine bug, which assumed the chip did not have
a dedicated ATU FID register (it does).
The second is an issue I noticed with hash collisions in the ATU
on the 6341 when using multiple FIDs. Different algorithms could
be selected using devlink, but the FDB was not flushed which
resulted in a corrupted FDB. (There is an outstanding question
as to whether this should only be allowed when all user ports
are administratively down; this is not addressed in this revision.)
The third is an issue (not originally included in the first two
revisions of this patch series) where flushing a FDB entry would
instead move it to port 3.
Signed-off-by: Luke Howard <lukeh@padl.com>
---
Changes in v3:
- Don't reorder mv88e6xxx_info to optimize alignment; just add
atu_fid_reg
- Don't clip ATU Move ToPort delete sentinel (flushing learned
FDB entries was broken)
- Link to v2: https://patch.msgid.link/20260710-mv88e6x41-fixes-v2-0-e23654c65aa0@padl.com
Changes in v2:
- Rather than special casing ATU hash algorithm for the 6341, simply
ensure the ATU is flushed when changing it via devlink.
- Retartget net instead of net-next, as this is a bugfix
- Link to v1: https://patch.msgid.link/20260703-mv88e6x41-fixes-v1-0-fbd3a1bf8965@padl.com
To: Andrew Lunn <andrew@lunn.ch>
To: Vladimir Oltean <olteanv@gmail.com>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Richard Cochran <richardcochran@gmail.com>
To: Vivien Didelot <vivien.didelot@gmail.com>
To: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Luke Howard (3):
net: dsa: mv88e6xxx: write the ATU FID register on 88E6141/88E6341
net: dsa: mv88e6xxx: flush the ATU when the hash algorithm changes
net: dsa: mv88e6xxx: don't clip ATU Move ToPort delete sentinel
drivers/net/dsa/mv88e6xxx/chip.c | 29 ++++++++++++++++++++++++++++-
drivers/net/dsa/mv88e6xxx/chip.h | 5 +++++
drivers/net/dsa/mv88e6xxx/devlink.c | 6 ++++++
drivers/net/dsa/mv88e6xxx/global1_atu.c | 11 ++++++++---
4 files changed, 47 insertions(+), 4 deletions(-)
---
base-commit: f6f3b36c15ed44de1fbb44e645e4fae8c4a4453e
change-id: 20260624-mv88e6x41-fixes-d4c84f955ebc
Best regards,
--
Luke Howard <lukeh@padl.com>
^ permalink raw reply
* [PATCH net v3 2/3] net: dsa: mv88e6xxx: flush the ATU when the hash algorithm changes
From: Luke Howard @ 2026-07-14 23:29 UTC (permalink / raw)
To: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Andrew Lunn,
Richard Cochran
Cc: Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel,
Luke Howard
In-Reply-To: <20260715-mv88e6x41-fixes-v3-0-9a8702b27ecc@padl.com>
Changing the ATU hash algorithm invalidates existing entries: those
loaded under the previous algorithm end up in different bins and read
back corrupted.
Flush the ATU whenever the hash algorithm is changed through devlink
and reload the default broadcast entries. Per-VLAN ATU entries and
any static addresses are not replayed, so the hash must be selected
before the FDB or MDB are configured.
Fixes: 23e8b470c778 ("net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Luke Howard <lukeh@padl.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
drivers/net/dsa/mv88e6xxx/chip.h | 2 ++
drivers/net/dsa/mv88e6xxx/devlink.c | 6 ++++++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 7938e50900ca8..6faae74de04a9 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2523,7 +2523,7 @@ static int mv88e6xxx_port_add_broadcast(struct mv88e6xxx_chip *chip, int port,
return mv88e6xxx_port_db_load_purge(chip, port, broadcast, vid, state);
}
-static int mv88e6xxx_broadcast_setup(struct mv88e6xxx_chip *chip, u16 vid)
+int mv88e6xxx_broadcast_setup(struct mv88e6xxx_chip *chip, u16 vid)
{
int port;
int err;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index f1db12b7629bd..abbb446b73456 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -893,4 +893,6 @@ int mv88e6xxx_vtu_walk(struct mv88e6xxx_chip *chip,
void *priv),
void *priv);
+int mv88e6xxx_broadcast_setup(struct mv88e6xxx_chip *chip, u16 vid);
+
#endif /* _MV88E6XXX_CHIP_H */
diff --git a/drivers/net/dsa/mv88e6xxx/devlink.c b/drivers/net/dsa/mv88e6xxx/devlink.c
index 6f034841883c6..5168335f52289 100644
--- a/drivers/net/dsa/mv88e6xxx/devlink.c
+++ b/drivers/net/dsa/mv88e6xxx/devlink.c
@@ -61,6 +61,12 @@ int mv88e6xxx_devlink_param_set(struct dsa_switch *ds, u32 id,
switch (id) {
case MV88E6XXX_DEVLINK_PARAM_ID_ATU_HASH:
err = mv88e6xxx_atu_set_hash(chip, ctx->val.vu8);
+ if (err)
+ break;
+ err = mv88e6xxx_g1_atu_flush(chip, 0, true);
+ if (err)
+ break;
+ err = mv88e6xxx_broadcast_setup(chip, 0);
break;
default:
err = -EOPNOTSUPP;
--
2.43.0
^ permalink raw reply related
* [PATCH net v3 1/3] net: dsa: mv88e6xxx: write the ATU FID register on 88E6141/88E6341
From: Luke Howard @ 2026-07-14 23:29 UTC (permalink / raw)
To: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Andrew Lunn,
Richard Cochran
Cc: Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel,
Luke Howard
In-Reply-To: <20260715-mv88e6x41-fixes-v3-0-9a8702b27ecc@padl.com>
The driver decided whether a device has a dedicated ATU FID register
from its database count, taking the register path only when there were
more than 256 databases. The 88E6141/88E6341 have 256 databases but do
have the register, so they fell back to the legacy path and the FID
register was never written. Every FDB entry was then loaded into FID 0,
breaking VLAN aware bridging.
The number of databases does not imply whether the register is present.
Add an explicit atu_fid_reg flag, set it on every device that has the
register (all that previously matched the >256 heuristic, plus the
88E6141/88E6341), and key the register access off the flag instead of
the database count.
Fixes: a75961d0ebfd ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Luke Howard <lukeh@padl.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 27 +++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/chip.h | 3 +++
drivers/net/dsa/mv88e6xxx/global1_atu.c | 4 ++--
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 80b877c74513d..7938e50900ca8 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -5747,6 +5747,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6097,
.name = "Marvell 88E6085",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 10,
.num_internal_phys = 5,
@@ -5792,6 +5793,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6097,
.name = "Marvell 88E6097/88E6097F",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 11,
.num_internal_phys = 8,
@@ -5817,6 +5819,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6123",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 1024,
.num_ports = 3,
.num_internal_phys = 5,
@@ -5863,6 +5866,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6341,
.name = "Marvell 88E6141",
.num_databases = 256,
+ .atu_fid_reg = true,
.num_macs = 2048,
.num_ports = 6,
.num_internal_phys = 5,
@@ -5889,6 +5893,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6161",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 1024,
.num_ports = 6,
.num_internal_phys = 5,
@@ -5915,6 +5920,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6165",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 6,
.num_internal_phys = 0,
@@ -5940,6 +5946,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6171",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -5965,6 +5972,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6172",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -5991,6 +5999,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6175",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -6016,6 +6025,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6176",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -6064,6 +6074,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6390,
.name = "Marvell 88E6190",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 16384,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 9,
@@ -6089,6 +6100,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6390,
.name = "Marvell 88E6190X",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 16384,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 9,
@@ -6114,6 +6126,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6390,
.name = "Marvell 88E6191",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 16384,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 9,
@@ -6139,6 +6152,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6393,
.name = "Marvell 88E6191X",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 8,
.internal_phys_offset = 1,
@@ -6164,6 +6178,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6393,
.name = "Marvell 88E6193X",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 8,
.num_tcam_entries = 256,
@@ -6218,6 +6233,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6240",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -6267,6 +6283,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6390,
.name = "Marvell 88E6290",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 9,
.num_gpio = 16,
@@ -6294,6 +6311,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6320,
.name = "Marvell 88E6320",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 2,
@@ -6322,6 +6340,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6320,
.name = "Marvell 88E6321",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 2,
@@ -6350,6 +6369,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6341,
.name = "Marvell 88E6341",
.num_databases = 256,
+ .atu_fid_reg = true,
.num_macs = 2048,
.num_internal_phys = 5,
.num_ports = 6,
@@ -6377,6 +6397,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6350",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -6402,6 +6423,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6351",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -6427,6 +6449,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6352",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 8192,
.num_ports = 7,
.num_internal_phys = 5,
@@ -6453,6 +6476,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6393,
.name = "Marvell 88E6361",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 16384,
.num_ports = 11,
/* Ports 1, 2 and 8 are not routed */
@@ -6480,6 +6504,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6390,
.name = "Marvell 88E6390",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 16384,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 9,
@@ -6508,6 +6533,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6390,
.name = "Marvell 88E6390X",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_macs = 16384,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 9,
@@ -6535,6 +6561,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6393,
.name = "Marvell 88E6393X",
.num_databases = 4096,
+ .atu_fid_reg = true,
.num_ports = 11, /* 10 + Z80 */
.num_internal_phys = 8,
.num_tcam_entries = 256,
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index e966e7c4cc5de..f1db12b7629bd 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -176,6 +176,9 @@ struct mv88e6xxx_info {
/* Supports PTP */
bool ptp_support;
+ /* Has a dedicated ATU FID register. */
+ bool atu_fid_reg;
+
/* Internal PHY start index. 0 means that internal PHYs range starts at
* port 0, 1 means internal PHYs range starts at port 1, etc
*/
diff --git a/drivers/net/dsa/mv88e6xxx/global1_atu.c b/drivers/net/dsa/mv88e6xxx/global1_atu.c
index c47f068f56b32..522978f638e2f 100644
--- a/drivers/net/dsa/mv88e6xxx/global1_atu.c
+++ b/drivers/net/dsa/mv88e6xxx/global1_atu.c
@@ -135,7 +135,7 @@ static int mv88e6xxx_g1_atu_op(struct mv88e6xxx_chip *chip, u16 fid, u16 op)
int err;
/* FID bits are dispatched all around gradually as more are supported */
- if (mv88e6xxx_num_databases(chip) > 256) {
+ if (chip->info->atu_fid_reg) {
err = mv88e6xxx_g1_atu_fid_write(chip, fid);
if (err)
return err;
@@ -179,7 +179,7 @@ static int mv88e6xxx_g1_atu_fid_read(struct mv88e6xxx_chip *chip, u16 *fid)
u16 val = 0, upper = 0, op = 0;
int err = -EOPNOTSUPP;
- if (mv88e6xxx_num_databases(chip) > 256) {
+ if (chip->info->atu_fid_reg) {
err = mv88e6xxx_g1_read(chip, MV88E6352_G1_ATU_FID, &val);
val &= 0xfff;
if (err)
--
2.43.0
^ permalink raw reply related
* [PATCH net v3 3/3] net: dsa: mv88e6xxx: don't clip ATU Move ToPort delete sentinel
From: Luke Howard @ 2026-07-14 23:29 UTC (permalink / raw)
To: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Andrew Lunn,
Richard Cochran
Cc: Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel,
Luke Howard
In-Reply-To: <20260715-mv88e6x41-fixes-v3-0-9a8702b27ecc@padl.com>
mv88e6xxx_g1_atu_data_write() masked the port vector, which is correct
for a load operation (where portvec is a bitmap) but wrong for a move,
where the portvec encodes a ToPort/FromPort pair.
An all-ones ToPort value is the sentinel used to delete an entry. Chips
with fewer than eight ports (e.g. 88E6141) clipped this value, turning a
delete into a move (to port 3 on the 6141/6341). Other chips such as
the 7-port 88E6352 were unaffected by chance.
Fix this by moving the mv88e6xxx_port_mask() mask into
mv88e6xxx_g1_atu_loadpurge(), where the portvec always represents a
bitmap; the move path then writes its ToPort/FromPort pair unmasked.
Fixes: e606ca36bbf2 ("net: dsa: mv88e6xxx: rework ATU Remove")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Luke Howard <lukeh@padl.com>
---
drivers/net/dsa/mv88e6xxx/global1_atu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/global1_atu.c b/drivers/net/dsa/mv88e6xxx/global1_atu.c
index 522978f638e2f..6bee943c83575 100644
--- a/drivers/net/dsa/mv88e6xxx/global1_atu.c
+++ b/drivers/net/dsa/mv88e6xxx/global1_atu.c
@@ -239,7 +239,7 @@ static int mv88e6xxx_g1_atu_data_write(struct mv88e6xxx_chip *chip,
if (entry->trunk)
data |= MV88E6XXX_G1_ATU_DATA_TRUNK;
- data |= (entry->portvec & mv88e6xxx_port_mask(chip)) << 4;
+ data |= entry->portvec << 4;
}
return mv88e6xxx_g1_write(chip, MV88E6XXX_G1_ATU_DATA, data);
@@ -326,6 +326,11 @@ int mv88e6xxx_g1_atu_loadpurge(struct mv88e6xxx_chip *chip, u16 fid,
if (err)
return err;
+ /* Mask portvec to a chip's real ports so they cannot spill into
+ * adjacent ATU Data register fields.
+ */
+ entry->portvec &= mv88e6xxx_port_mask(chip);
+
err = mv88e6xxx_g1_atu_data_write(chip, entry);
if (err)
return err;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH iwl] ice: acquire NVM lock around each flash read
From: Tony Nguyen @ 2026-07-14 23:47 UTC (permalink / raw)
To: Robert Malz, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexander Lobakin,
Jacob Keller, Jesse Brandeburg
Cc: intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20260703103245.374800-1-robert.malz@canonical.com>
On 7/3/2026 3:32 AM, Robert Malz wrote:
...
> @@ -92,12 +98,28 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset, u32 *length, u8 *data,
>
> last_cmd = !(bytes_read + read_size < inlen);
>
> + status = ice_acquire_nvm(hw, ICE_RES_READ);
> + if (status)
> + break;
> +
> status = ice_aq_read_nvm(hw, ICE_AQC_NVM_START_POINT,
> offset, read_size,
> data + bytes_read, last_cmd,
> read_shadow_ram, NULL);
Sashiko says:
If this chunk has last_cmd = false, doesn't releasing the NVM lock
immediately
after ice_aq_read_nvm() allow other entities to acquire the lock and issue
their own NVM commands in the middle of our open read sequence?
Also, if ice_acquire_nvm() fails on the next loop iteration, the loop breaks
and we never send a command with last_cmd = true. Will this permanently leak
the sequence state in the firmware?
[TN] I'm seeing conflicting documentation on whether this bit matters
for the read command. I'm working on getting clarification. If it does
matter, we'll likely need to adjust this.
> - if (status)
> + if (status) {
> + /* ice_release_nvm() issues an AQ command that would
> + * overwrite sq_last_status, which some callers
> + * inspect after a failed read. Preserve the read's
> + * AQ error across the release.
> + */
> + aq_err = hw->adminq.sq_last_status;
> +
> + ice_release_nvm(hw);
> + hw->adminq.sq_last_status = aq_err;
Does restoring hw->adminq.sq_last_status here without holding the Admin
Queue
lock risk overwriting the status of a concurrent AdminQ command?
If another thread acquires the lock and sends a command immediately after
ice_release_nvm(hw), this lockless write could corrupt its error status.
[TN] I don't believe the AQ lock will work as desired we can't guarantee
that we will have the lock directly following the release in order to
restore the AQ error. Similar to the NVM lock issue, I think this is a
small window but wanted to bring this here in case others had
thoughts/comments on this.
Thanks,
Tony
> break;
> + }
> +
> + ice_release_nvm(hw);
>
> bytes_read += read_size;
> offset += read_size;
^ permalink raw reply
* Re: [PATCH net v3 1/3] net: dsa: mv88e6xxx: write the ATU FID register on 88E6141/88E6341
From: Andrew Lunn @ 2026-07-15 0:00 UTC (permalink / raw)
To: Luke Howard
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Richard Cochran,
Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260715-mv88e6x41-fixes-v3-1-9a8702b27ecc@padl.com>
On Wed, Jul 15, 2026 at 09:29:41AM +1000, Luke Howard wrote:
> The driver decided whether a device has a dedicated ATU FID register
> from its database count, taking the register path only when there were
> more than 256 databases. The 88E6141/88E6341 have 256 databases but do
> have the register, so they fell back to the legacy path and the FID
> register was never written. Every FDB entry was then loaded into FID 0,
> breaking VLAN aware bridging.
>
> The number of databases does not imply whether the register is present.
> Add an explicit atu_fid_reg flag, set it on every device that has the
> register (all that previously matched the >256 heuristic, plus the
> 88E6141/88E6341), and key the register access off the flag instead of
> the database count.
>
> Fixes: a75961d0ebfd ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Luke Howard <lukeh@padl.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net v3 3/3] net: dsa: mv88e6xxx: don't clip ATU Move ToPort delete sentinel
From: Andrew Lunn @ 2026-07-15 0:02 UTC (permalink / raw)
To: Luke Howard
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Richard Cochran,
Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260715-mv88e6x41-fixes-v3-3-9a8702b27ecc@padl.com>
On Wed, Jul 15, 2026 at 09:29:43AM +1000, Luke Howard wrote:
> mv88e6xxx_g1_atu_data_write() masked the port vector, which is correct
> for a load operation (where portvec is a bitmap) but wrong for a move,
> where the portvec encodes a ToPort/FromPort pair.
>
> An all-ones ToPort value is the sentinel used to delete an entry. Chips
> with fewer than eight ports (e.g. 88E6141) clipped this value, turning a
> delete into a move (to port 3 on the 6141/6341). Other chips such as
> the 7-port 88E6352 were unaffected by chance.
>
> Fix this by moving the mv88e6xxx_port_mask() mask into
> mv88e6xxx_g1_atu_loadpurge(), where the portvec always represents a
> bitmap; the move path then writes its ToPort/FromPort pair unmasked.
>
> Fixes: e606ca36bbf2 ("net: dsa: mv88e6xxx: rework ATU Remove")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Luke Howard <lukeh@padl.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net v3 2/3] net: dsa: mv88e6xxx: flush the ATU when the hash algorithm changes
From: Andrew Lunn @ 2026-07-15 0:08 UTC (permalink / raw)
To: Luke Howard, Jonas Gorski
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Richard Cochran,
Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260715-mv88e6x41-fixes-v3-2-9a8702b27ecc@padl.com>
On Wed, Jul 15, 2026 at 09:29:42AM +1000, Luke Howard wrote:
> Changing the ATU hash algorithm invalidates existing entries: those
> loaded under the previous algorithm end up in different bins and read
> back corrupted.
>
> Flush the ATU whenever the hash algorithm is changed through devlink
> and reload the default broadcast entries. Per-VLAN ATU entries and
> any static addresses are not replayed, so the hash must be selected
> before the FDB or MDB are configured.
Hi Jonas
For v2 you said you thought this was a bit of a foot gun. I suggested
maybe checking all user ports are admin down. What do you think?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net] net: hip04: fix RX buffer leak on build_skb failure
From: Jacob Keller @ 2026-07-15 0:17 UTC (permalink / raw)
To: Fan Wu, netdev
Cc: przemyslaw.kitszel, horms, shenjian15, salil.mehta, dingtianhong,
andrew+netdev, davem, edumazet, kuba, pabeni, linux-kernel,
stable
In-Reply-To: <20260712142729.2057636-1-fanwu01@zju.edu.cn>
On 7/12/2026 7:27 AM, Fan Wu wrote:
> When build_skb() fails in hip04_rx_poll(), the driver jumps to the
> refill path without releasing the current RX buffer and its DMA mapping.
> Installing a replacement buffer then overwrites the slot references and
> leaks both resources.
>
> Keep the current slot intact and return budget so NAPI retries the same
> buffer. Also free a newly allocated RX fragment when dma_map_single()
> fails.
>
> This issue was found by an in-house static analysis tool.
>
> Fixes: 701a0fd52318 ("hip04_eth: fix missing error handle for build_skb failed")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
> ---
>
You say this was found by static analysis. I imagine that build_skb
rarely fails (without some sort of fault injection). That means this is
likely difficult to reproduce in practice. I know we've been trying to
err on the side of increasing the burden of proof on AI-assisted fixes
like this.
Based on a quick search, it does seem that this drivers response of only
logging a debug message is not correct...
> drivers/net/ethernet/hisilicon/hip04_eth.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
> index 18376bcc7..1d03039b4 100644
> --- a/drivers/net/ethernet/hisilicon/hip04_eth.c
> +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
> @@ -594,7 +594,10 @@ static int hip04_rx_poll(struct napi_struct *napi, int budget)
> skb = build_skb(buf, priv->rx_buf_size);
> if (unlikely(!skb)) {
> net_dbg_ratelimited("build_skb failed\n");
> - goto refill;
> + /* Retain the slot; return budget so NAPI retries this buffer.
> + * Refill would overwrite rx_buf[]/rx_phys[] and leak them.
> + */
> + return budget;
> }
>
> dma_unmap_single(priv->dev, priv->rx_phys[priv->rx_head],
> @@ -622,14 +625,15 @@ static int hip04_rx_poll(struct napi_struct *napi, int budget)
> rx++;
> }
>
> -refill:
> buf = netdev_alloc_frag(priv->rx_buf_size);
> if (!buf)
> goto done;
> phys = dma_map_single(priv->dev, buf,
> RX_BUF_SIZE, DMA_FROM_DEVICE);
> - if (dma_mapping_error(priv->dev, phys))
> + if (dma_mapping_error(priv->dev, phys)) {
> + skb_free_frag(buf);
> goto done;
> + }
> priv->rx_buf[priv->rx_head] = buf;
> priv->rx_phys[priv->rx_head] = phys;
> hip04_set_recv_desc(priv, phys);
>
>
^ permalink raw reply
* Re: [PATCH net-next v2] net: libwx: disable TX VLAN offload for packets with >2 VLAN tags
From: Jacob Keller @ 2026-07-15 0:26 UTC (permalink / raw)
To: Jiawen Wu, netdev
Cc: Duanqiang Wen, Mengyuan Lou, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kees Cook, Przemek Kitszel
In-Reply-To: <069DF89AA8029189+20260713060441.276612-1-jiawenwu@trustnetic.com>
On 7/12/2026 11:04 PM, Jiawen Wu wrote:
> The current hardware does not support TX VLAN offload for packets with
> three or more VLAN tags. When such packets are transmitted with hardware
> VLAN offload enabled, the hardware may malfunction or produce corrupted
> frames.
>
> Add a check in wx_features_check() to parse the VLAN depth of the
> skb. If more than two VLAN tags are detected (including both the
> hardware tag and in-band tags), strip NETIF_F_HW_VLAN_CTAG_TX and
> NETIF_F_HW_VLAN_STAG_TX from the feature set. This forces the
> kernel networking stack to handle VLAN insertion in software for
> these specific packets, ensuring correct transmission.
>
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Is there a reason this was targeted at net-next instead of as a bug fix
to net with a Fixes tag to the commit which first introduced VLAN tagging?
Thanks,
Jake
> ---
> v2:
> - Remove redundant 'parse_depth'.
> - Optimize the loop.
>
> v1: https://lore.kernel.org/all/C1BF77C0E073A40C+20260710071831.210196-1-jiawenwu@trustnetic.com
> ---
> drivers/net/ethernet/wangxun/libwx/wx_lib.c | 24 +++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/net/ethernet/wangxun/libwx/wx_lib.c b/drivers/net/ethernet/wangxun/libwx/wx_lib.c
> index 814d88d2aee4..34542b3dc884 100644
> --- a/drivers/net/ethernet/wangxun/libwx/wx_lib.c
> +++ b/drivers/net/ethernet/wangxun/libwx/wx_lib.c
> @@ -3228,6 +3228,30 @@ netdev_features_t wx_features_check(struct sk_buff *skb,
> netdev_features_t features)
> {
> struct wx *wx = netdev_priv(netdev);
> + __be16 type = skb->protocol;
> + u16 vlan_depth = ETH_HLEN;
> + u32 vlan_num = 0;
> +
> + if (skb_vlan_tag_present(skb))
> + vlan_num++;
> +
> + while (eth_type_vlan(type)) {
> + struct vlan_hdr vhdr, *vh;
> +
> + vh = skb_header_pointer(skb, vlan_depth, sizeof(vhdr), &vhdr);
> + if (unlikely(!vh))
> + break;
> +
> + type = vh->h_vlan_encapsulated_proto;
> + vlan_depth += VLAN_HLEN;
> + vlan_num++;
> +
> + if (vlan_num > 2) {
> + features &= ~(NETIF_F_HW_VLAN_CTAG_TX |
> + NETIF_F_HW_VLAN_STAG_TX);
> + break;
> + }
> + }
>
> if (!skb->encapsulation)
> return features;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox