summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-05-06net/mlx5e: Report TX csum_none netdev statGal Pressman
Report TX csum_none statistic via the netdev queue stats API by mapping the existing csum_none counter to the csum_none field. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Report RX HW-GRO netdev statsGal Pressman
Report RX hardware GRO statistics via the netdev queue stats API by mapping the existing gro_packets, gro_bytes and gro_skbs counters to the hw_gro_wire_packets, hw_gro_wire_bytes and hw_gro_packets fields. Signed-off-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Report hw_gso_packets and hw_gso_bytes netdev statsGal Pressman
Report hardware GSO statistics via the netdev queue stats API by mapping the existing TSO counters to hw_gso_packets and hw_gso_bytes fields. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Count full skb length in TSO byte countersGal Pressman
The tso_bytes and tso_inner_bytes counters currently subtract the header length from skb->len, counting only the payload. This is confusing and doesn't align with the behavior of other _bytes counters in the driver. Report the full skb length to align with this expectation. This also makes our behavior consistent with the netdev stats API and virtio spec definition. Signed-off-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net: rtsn: fix mdio_node leak in rtsn_mdio_alloc()Shitalkumar Gandhi
of_get_child_by_name() takes a reference. The rtsn_reset() and rtsn_change_mode() failure paths jump to out_free_bus and leak mdio_node. Add out_put_node to drop it before falling through. Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN") Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260505123236.406000-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06netdevsim: psp: rcu protect psp_dev referenceDaniel Zahka
There are two issues with the way psp_dev is used in nsim_do_psp(): 1. There is no check for IS_ERR() on the peers psp_dev, before dereferencing. 2. The refcount on this psp_dev can be dropped by nsim_psp_rereg_write() To fix this, we can make netdevsim's reference to its psp_dev an rcu reference, and then nsim_do_psp() can read the fields it needs from an rcu critical section. Fixes: f857478d6206 ("netdevsim: a basic test PSP implementation") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260505-psd-rcu-v1-3-a8f69ec1ab96@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06netdevsim: psp: serialize calls to nsim_psp_uninit()Daniel Zahka
The debugfs write handler, nsim_psp_rereg_write(), can race against nsim_destroy() and against itself, causing nsim_psp_uninit() to run more than once concurrently. Two complementary changes serialize all callers: 1. Delete the psp_rereg debugfs file from nsim_psp_uninit() before doing the actual teardown. debugfs_remove() drains any in-flight writers and prevents new ones from starting. 2. Add a mutex around the body of nsim_psp_rereg_write() so that two concurrent userspace writers cannot both enter the teardown path at once. The teardown work itself is moved into a new __nsim_psp_uninit() that the rereg handler calls under the mutex, while the public nsim_psp_uninit() wraps it with the debugfs_remove()/mutex_destroy() pair so nsim_destroy() doesn't have to know about the psp internals. Fixes: f857478d6206 ("netdevsim: a basic test PSP implementation") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260505-psd-rcu-v1-2-a8f69ec1ab96@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06netdevsim: psp: only call nsim_psp_uninit() on PFsDaniel Zahka
VFs go through nsim_init_netdevsim_vf() which never calls nsim_psp_init(), so ns->psp.dev stays NULL. nsim_psp_uninit() guards with !IS_ERR(ns->psp.dev), so destroying a VF reaches psp_dev_unregister(NULL) and dereferences NULL on the first mutex_lock(&psd->lock): BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:mutex_lock+0x1c/0x30 Call Trace: psp_dev_unregister+0x2a/0x1a0 nsim_psp_uninit+0x1f/0x40 [netdevsim] nsim_destroy+0x61/0x1e0 [netdevsim] __nsim_dev_port_del+0x47/0x90 [netdevsim] nsim_drv_configure_vfs+0xc9/0x130 [netdevsim] nsim_bus_dev_numvfs_store+0x79/0xb0 [netdevsim] Gate nsim_psp_uninit() on nsim_dev_port_is_pf(), matching the pattern already used for nsim_exit_netdevsim() and the bpf/ipsec/macsec/queue teardowns. Reproducer: modprobe netdevsim echo "10 1" > /sys/bus/netdevsim/new_device echo 1 > /sys/bus/netdevsim/devices/netdevsim10/sriov_numvfs devlink dev eswitch set netdevsim/netdevsim10 mode switchdev echo 0 > /sys/bus/netdevsim/devices/netdevsim10/sriov_numvfs Fixes: f857478d6206 ("netdevsim: a basic test PSP implementation") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260505-psd-rcu-v1-1-a8f69ec1ab96@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06rtase: Fix flow control configurationJustin Lai
The hardware has two sets of registers controlling TX/RX flow control. The effective flow control state is determined by the logical OR of these two sets of bits. RTASE_FORCE_TXFLOW_EN and RTASE_FORCE_RXFLOW_EN in RTASE_CPLUS_CMD are the bits used by the driver to control TX/RX flow control according to the ethtool pause configuration. RTASE_TXFLOW_EN and RTASE_RXFLOW_EN in RTASE_GPHY_STD_00 are another set of TX/RX flow control enable bits. Clear them by default so they do not keep flow control enabled independently of the driver setting. With the RTASE_GPHY_STD_00 bits cleared, the effective flow control state is controlled through RTASE_CPLUS_CMD, so the ethtool setting can take effect correctly. Signed-off-by: Justin Lai <justinlai0215@realtek.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260505064121.31286-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06Merge tag 'ovpn-net-20260504' of https://github.com/OpenVPN/ovpn-net-nextJakub Kicinski
Antonio Quartulli says: ==================== Includes changes: * ensure MAC header offset is reset before delivering packet * ensure gro_cells_receive() and dstats_dev_add() are called with BH disabled * reduce ping count in selftest to ensure it completes within timeout * tag 'ovpn-net-20260504' of https://github.com/OpenVPN/ovpn-net-next: selftests: ovpn: reduce ping count in test.sh ovpn: ensure packet delivery happens with BH disabled ovpn: reset MAC header before passing skb up ==================== Link: https://patch.msgid.link/20260504230305.2681646-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06Merge tag 'wireless-next-2026-05-06' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Lots of new content in cfg80211/mac80211, notably - more NAN work, mostly complete now (also hwsim) - more UHR work (e.g. non-primary channel access), this will continue for a while - FTM ranging APIs * tag 'wireless-next-2026-05-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (70 commits) wifi: mac80211: explicitly disable FTM responder on AP stop wifi: iwlwifi: don't blindly start the responder upon BSS_CHANGED_FTM_RESPONDER wifi: mac80211_hwsim: claim HT STBC capability wifi: mac80211_hwsim: enable NAN_DATA interface simulation support wifi: mac80211_hwsim: Support Tx of multicast data on NAN wifi: mac80211_hwsim: Do not declare support for NDPE wifi: mac80211_hwsim: Declare support for secure NAN wifi: mac80211_hwsim: add NAN data path TX/RX support wifi: mac80211_hwsim: set HAS_RATE_CONTROL when using NAN wifi: mac80211_hwsim: implement NAN schedule callbacks wifi: mac80211_hwsim: add NAN PHY capabilities wifi: mac80211_hwsim: add NAN_DATA interface limits wifi: mac80211_hwsim: implement NAN synchronization wifi: mac80211_hwsim: protect tsf_offset using a spinlock wifi: mac80211_hwsim: only RX on NAN when active on a slot wifi: mac80211_hwsim: select NAN TX channel based on current TSF wifi: mac80211_hwsim: limit TX of frames to the NAN DW wifi: cfg80211: don't allow NAN DATA on multi radio devices wifi: mac80211: check AP using NPCA has NPCA capability wifi: mac80211: don't parse full UHR operation from beacons ... ==================== Link: https://patch.msgid.link/20260506111147.224296-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06Merge tag 'wireless-2026-05-06' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Quite a number of fixes now: - mac80211 - remove HT NSS validation to work with broken APs (with a kunit fix now) - remove 'static' that could cause races - check station link lookup before further processing - fix use-after-free due to delete in list iteration - remove AP station on assoc failures to fix crashes - ath12k - fix OF node refcount imbalance - fix queue flush ("REO update") in MLO - fix RCU assert - ath12k: - fix Kconfig with POWER_SEQUENCING - fix WMI buffer leaks on error conditions - don't use uninitialized stack data when processing RSSI events - fix logic for determining the peer ID in the RX path - ath5k: fix a potential stack buffer overwrite - rsi: fix thread lifetime race - brcmfmac: fix potential UAF - nl80211: - stricter permissions/checks for PMK and netns - fix netlink policy vs. code type confusion - cw1200: revert a broken locking change - various fixes to not trust values from firmware * tag 'wireless-2026-05-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (25 commits) wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation wifi: nl80211: require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS wifi: nl80211: fix NL80211_PMSR_FTM_REQ_ATTR_FTMS_PER_BURST usage wifi: mac80211: remove station if connection prep fails wifi: mac80211: use safe list iteration in radar detect work wifi: libertas: notify firmware load wait on disconnect wifi: ath5k: do not access array OOB wifi: ath12k: fix peer_id usage in normal RX path wifi: ath12k: initialize RSSI dBm conversion event state wifi: ath12k: fix leak in some ath12k_wmi_xxx() functions wifi: cw1200: Revert "Fix locking in error paths" wifi: mac80211: tests: mark HT check strict wifi: rsi: fix kthread lifetime race between self-exit and external-stop wifi: mac80211: drop stray 'static' from fast-RX rx_result wifi: mac80211: check ieee80211_rx_data_set_link return in pubsta MLO path wifi: nl80211: require admin perm on SET_PMK / DEL_PMK wifi: libertas: fix integer underflow in process_cmdrequest() wifi: b43legacy: enforce bounds check on firmware key index in RX path wifi: b43: enforce bounds check on firmware key index in b43_rx() wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task ... ==================== Link: https://patch.msgid.link/20260506110325.219675-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06treewide: Explicitly include the x86 CPUID headersAhmed S. Darwish
Modify all CPUID call sites which implicitly include any of the CPUID headers to explicitly include them instead. For KVM's reverse_cpuid.h, just include <asm/cpuid/types.h> since it references the CPUID_EAX..EDX symbols without using the CPUID APIs. Note, this allows removing the inclusion of <asm/cpuid/api.h> from within <asm/processor.h> next. That allows the CPUID API headers to include <asm/processor.h> without introducing a circular dependency. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20260327021645.555257-1-darwi@linutronix.de
2026-05-06wifi: iwlwifi: don't blindly start the responder upon BSS_CHANGED_FTM_RESPONDEREmmanuel Grumbach
mac80211 may just want to stop it, so check the ftm_responder boolean before starting the responder. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260505151241.285da8fbf7f4.I1b6922ca8d06d592356d7a5d190e6118fec1d5b5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: claim HT STBC capabilityJohannes Berg
This is already claimed for VHT and HE, so it doesn't really make sense to not claim it for HT, and this causes sigma-dut failures since it assumes VHT support implies HT support. Link: https://patch.msgid.link/20260506093231.155762-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: enable NAN_DATA interface simulation supportDaniel Gabay
Enable NAN_DATA interface simulation support by adding it to the supported interface types. This completes the NAN Data Path simulation introduced in the previous patches. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.d4bd95959bfa.I450087714bd55189242ab6a72ce6650be36edbcb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: Support Tx of multicast data on NANIlan Peer
Add support for transmitting multicast data frames. These frames can be transmitted when all the peer NDI stations on the interface are available at the current slot. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.0af7e24f0df3.I3c2de3e456ae092c939e6bfd3d30960fbf2fbeaa@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: Do not declare support for NDPEIlan Peer
Do not declare support for NAN Data Path Extension attribute as this is handled by user space and should be set by it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.711c61538c8a.I9796410c0376f50a07259cc611428d76c51f180a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: Declare support for secure NANDaniel Gabay
Advertise NL80211_EXT_FEATURE_SECURE_NAN to indicate support for NAN Pairing, enabling peer authentication and secure data path establishment. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.d3bcc26b4525.I6993cc70c43579694ffd429f1afb971a73db2ae4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: add NAN data path TX/RX supportDaniel Gabay
Implement TX and RX path handling for NAN Data Path (NDP) frames, enabling data communication between NAN peers during scheduled availability windows. TX path: - Select TX channel based on current time slot: use DW channel during Discovery Windows, or FAW channel from local schedule during Further Availability Windows. - Verify peer availability before transmission by checking committed DW schedule or FAW of the peer schedule. RX path: - Extend NAN receive filtering to handle NAN_DATA interface frames. - Accept incoming frames during FAW slots when channel matches local schedule. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.155252ebc72b.Ic210f6c095c6ff372941bc8c77ee9c8c37d0356c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: set HAS_RATE_CONTROL when using NANDaniel Gabay
- NAN switches between bands/channels per its schedule, so mac80211 rate control can't work, set HAS_RATE_CONTROL instead. - Skip rate control checks for NAN interfaces in mac80211_hwsim_sta_rc_update() as it's not relevant. - Move set_rts_threshold stub to HWSIM_COMMON_OPS and return 0 instead of -EOPNOTSUPP to prevent failures in non-MLO tests that set RTS threshold (hwsim ignores the use_rts instruction from mac80211 anyway). Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.216e68be61ac.If9ef94a12cec8dfc55416afaf745d6e5025a5ec9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: implement NAN schedule callbacksDaniel Gabay
Implement mac80211 schedule callbacks for NAN Data Path support: - Track local schedule via BSS_CHANGED_NAN_LOCAL_SCHED, caching the channel for each 16TU time slot. - Copy peer schedule to driver-private storage in nan_peer_sched_changed callback for use in TX availability decisions. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.f3ad9e3dc9d4.I75cf3555b7506d5b8bb30e70a0f3721ab73477cb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: add NAN PHY capabilitiesDaniel Gabay
Add static HT, VHT and HE PHY capabilities to the NAN capabilities structure. These are based on the existing band capability structures and initialization in mac80211_hwsim. The NAN PHY capabilities are used by mac80211 and nl80211 to advertise device capabilities for NAN data interfaces. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.2c94c156f05d.I539fab4adf2eb43bfec27006f7529b926e5208ea@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: add NAN_DATA interface limitsDaniel Gabay
Increase interface limits for NAN_DATA interface. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.587955b23089.I261b782e5c198726b9465815d59ce037f094784d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: implement NAN synchronizationBenjamin Berg
Add all the handling to do NAN synchronization on 2.4 GHz including sending out beacons. With this, the mac80211_hwsim NAN device also works when used in conjunction with an external medium simulation. Note that the TSF sync is not ideal in case of an external medium simulation. This is because the mactime for received frames needs to be estimated and the simulation may not update the timestamp of beacons to the actual time that the frame was transmitted. The implementation has an initial short phase where it scans for clusters. This facilitates cluster joining and avoids creating a new cluster immediately, which would result in two cluster join notifications. It does not scan otherwise and will only see another cluster appearing if a discovery beacon happens to be sent during the 2.4 GHz discovery window (DW). Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.7d21c3cdc565.I98b6c15eadefd6d123658294ef1a0cd3c2ce3054@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: protect tsf_offset using a spinlockBenjamin Berg
To implement NAN synchronization in hwsim, the TSF needs to be adjusted regularly from the RX path. Add a spinlock so that this can be done in a safe manner. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.18f36f264eb9.I0da5477220b896e2177bd521f7d9a8f2595631e6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: only RX on NAN when active on a slotBenjamin Berg
This moves the NAN receive into the main code and changes it so that frame RX only happens when the device is active on the channel. This limits RX to the DW slots as there is currently no datapath. With this the globally stored channel is obsolete, remove it. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.8cf4a67d3436.Ife07cf4ae8a2d59766356398163f7ee8d734bd6a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: select NAN TX channel based on current TSFBenjamin Berg
Move the TX channel selection into the NAN specific file and select the channel based on the current slot. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.c235b5a78b98.I5ec4076a8a9445233dc414c6ecaa39f32f1e9595@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: mac80211_hwsim: limit TX of frames to the NAN DWBenjamin Berg
Frames submitted on the NAN device interface should only be transmitted during one of the discovery windows (DWs). It is assumed that software submits frames from the DW end notifications for the next DW period. Simulate this behaviour by checking that we are currently in a DW before transmitting from ieee80211_hwsim_wake_tx_queue. As frames will be queued up at the start of a DW, wake the management TX queue every time a DW is started. Do so with a randomized offset just to avoid every client transmitting at the same time. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260506064301.f3456f159655.Id6780e2f7f7cab03264299b7d696ba5b1269e451@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-06wifi: rtw89: debug: add BB diagnoseKuan-Chung Chen
Add BB diagnostic to track potential abnormal conditions. Currently, five diagnostic metrics are monitored: 1) Hang detection monitors consecutive absence of TX and RX activity. 2) PD maximum triggers when PD stays at its maximum threshold for a period. 3) No RX occurs when no CCA activity is detected over multiple consecutive cycles. 4) High FA indicates a high false alarm ratio, reflecting severe environmental interference. 5) EDCCA alerts when high EDCCA ratio, signaling a potential TX hang. These metrics are exposed via debugfs diag_bb. Output: [PHY 0] Diag bitmap = 0x0 Event{Hang, PD MAX, No RX, High FA, High EDCCA Ratio} = {0, 0, 0, 0, 0} consecutive_no_tx_cnt=0, consecutive_no_rx_cnt=0 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260429132625.1659182-8-pkshih@realtek.com
2026-05-06wifi: rtw89: debug: add RX statistics in bb_infoKuan-Chung Chen
Expand RX packet statistics including coding type, spatial diversity, and beamforming. These statistics are accumulated per PHY and displayed in bb_info debugfs. RX statistics output: == RX General LDPC: 190, BCC: 0, STBC: 0, SU_NON_BF: 0, SU_BF: 190, MU: 0 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260429132625.1659182-7-pkshih@realtek.com
2026-05-06wifi: rtw89: debug: extend bb_info with TX status and PERKuan-Chung Chen
Enhance bb_info debugfs by adding TX status information to aid debugging and performance analysis. A snapshot of TX-related registers, including PPDU type and subtype, bandwidth, TX power, STBC, etc. The information is collected per PHY during track_work and displayed via bb_info debugfs. TX status output: == TX General EHT_MU_SU DATA BW: 160, TX_SC: 0, TX_PATH_EN: 3, PATH_MAP: 0xe4 TXPWR TMAC: 11, P0: 11, P1: 11 dBm MCS: 9, STBC: 0 Info: [0x0000000b, 0xc1702c30, 0x0ff1e430, 0xc0000000, 0x99000009, 0x40000000] Common ctrl: [0x00000150, 0x40190140] In addition, include the retry ratio from RA reports and display it as PER (packet error rate) in station debug information. PER output: TX rate [0, 0]: HE 2SS MCS-4 GI:0.8 BW:20 (hw_rate=0x324) PER:23 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260429132625.1659182-6-pkshih@realtek.com
2026-05-06wifi: rtw89: debug: add PMAC counter in bb_infoKuan-Chung Chen
PMAC (Pseudo MAC) is a circuit within the baseband that can report various packet-related counters through registers, such as TX ON, TX EN, CCA, FA, CRC, etc. The driver periodically collects per PHY PMAC counters in track_work and exposes them through the bb_info debugfs for easier debugging. The output of PMAC counter: == PMAC TX [CCK_TXEN, CCK_TXON, OFDM_TXEN, OFDM_TXON]: [0, 0, 17, 17] CRC [CCK, OFDM, HT, VHT, HE, EHT, ALL, MPDU] ok: [0, 301, 0, 0, 5, 0, 306, 5] err: [0, 4, 0, 0, 0, 0, 4, 0] CCA [CCK, OFDM]: [0, 353] FA [CCK, OFDM]: [0, 39] CCA spoofing [CCK, OFDM]: [0, 0] CCK SFD: 0, SIG_GG: 0 OFDM Parity: 4, Rate: 2, LSIG_BRK_S: 0, LSIG_BRK_L: 7, SBD: 5 AMPDU miss: 0 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260429132625.1659182-5-pkshih@realtek.com
2026-05-06wifi: rtw89: debug: bb_info entry including TX rate count for WiFi 7 chipsKuan-Chung Chen
Enhance TX performance visibility for WiFi 7 chips by introducing TX rate count tracking. This is critical for debugging and validation. Additionally, introduce a new debugfs bb_info to enable and provide baseband status. Usage of bb_info debugfs: $ echo enable 1 > bb_info // Start logging BB statistics information $ echo mac_id 0 > bb_info // Specify mac_id for TX rate count tracking The output of bb_info: TP TX: 0 [0] Mbps, RX: 0 [0] Mbps Avg packet length: TX=118, RX=136 TF: 0 TX count [0]: Legacy: [0, 0, 0, 0] OFDM: [0, 0, 0, 0, 0, 0, 0, 0] MCS 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] MCS 2SS: [183, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] [PHY 0] == RSSI/RX Rate Beacon: 19 (-41 dBm) RX count: Legacy: [0, 0, 0, 0] OFDM: [0, 0, 0, 0, 0, 0, 0, 0] HT 0: [0, 0, 0, 0, 0, 0, 0, 0] HT 1: [0, 0, 0, 0, 0, 0, 0, 0] VHT 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] VHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] HE 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] HE 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] EHT 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] EHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 185] TX rate [0, 2]: EHT 2SS MCS-0 GI:0.8 FB_G BW:160 (hw_rate=0x420) ==> agg_wait=-1 (1) RX rate [0, 2]: EHT 2SS MCS-13 GI:0.8 BW:160 (hw_rate=0x42d) RSSI: -43 dBm (raw=134, prev=135) [-43, -44] EVM: [38.75, (41.50, 43.00)] SNR: 39 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260429132625.1659182-4-pkshih@realtek.com
2026-05-06wifi: rtw89: phy: support per PHY RX statisticsKuan-Chung Chen
Previously, RX statistics such as beacon RSSI and packet counters were shared across all PHYs. To support MLO, extend the statistics to be maintained per PHY. Update the debugfs output for phy_info and beacon_info to include a "[PHY X]" label for better clarity. The output of phy_info: TP TX: 0 [0] Mbps (lv: 0), RX: 0 [0] Mbps (lv: 0) Avg packet length: TX=0, RX=120 TF: 0 [PHY 0] Beacon: 19 (-45 dBm) RX count: Legacy: [0, 0, 0, 0] ... EHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] The output of beacon_info: [PHY 0] Beacon: 20 raw rssi: 131 hw rate: 4 length: 437 [Beacon info] interval: 100 dtim: 1 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260429132625.1659182-3-pkshih@realtek.com
2026-05-06wifi: rtw89: mlo: rearrange MLSR link decision flowKuan-Chung Chen
The original MLSR link decision refers to RSSI, but it should be based on the premise of an existing link. Otherwise, make a link decision to select a new link from any available band. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260429132625.1659182-2-pkshih@realtek.com
2026-05-06wifi: rtl8xxxu: Detect the maximum supported channel widthBitterblue Smith
Some devices malfunction when connected to a network with 40 MHz channel width, because they don't support that. RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal this (and some other capabilities) to the driver. Get this information from the hardware and advertise 40 MHz support only when the hardware can handle it. We assume the other chips can always handle it. RTL8710BU needs a different way to retrieve this information, which will be implemented some other time. Fixes: dbf9b7bb0edf ("wifi: rtl8xxxu: Enable 40 MHz width by default") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c57de68e-5d57-4c26-898f-8a284bb25381@gmail.com
2026-05-05net: mana: Use kvmalloc for large RX queue and buffer allocationsAditya Garg
The RX path allocations for rxbufs_pre, das_pre, and rxq scale with queue count and queue depth. With high queue counts and depth, these can exceed what kmalloc can reliably provide from physically contiguous memory under fragmentation. Switch these from kmalloc to kvmalloc variants so the allocator transparently falls back to vmalloc when contiguous memory is scarce, and update the corresponding frees to kvfree. Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/20260502074552.23857-3-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net: mana: Use per-queue allocation for tx_qp to reduce allocation sizeAditya Garg
Convert tx_qp from a single contiguous array allocation to per-queue individual allocations. Each mana_tx_qp struct is approximately 35KB. With many queues (e.g., 32/64), the flat array requires a single contiguous allocation that can fail under memory fragmentation. Change mana_tx_qp *tx_qp to mana_tx_qp **tx_qp (array of pointers), allocating each queue's mana_tx_qp individually via kvzalloc. This reduces each allocation to ~35KB and provides vmalloc fallback, avoiding allocation failure due to fragmentation. Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/20260502074552.23857-2-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net/mlx5e: SD, Fix race condition in secondary device probe/removeShay Drory
When utilizing Socket-Direct single netdev functionality the driver resolves the actual auxiliary device using mlx5_sd_get_adev(). However, the current implementation returns the primary ETH auxiliary device without holding the device lock, leading to a potential race condition where the ETH device could be unbound or removed concurrently during probe, suspend, resume, or remove operations.[1] Fix this by introducing mlx5_sd_put_adev() and updating mlx5_sd_get_adev() so that secondaries devices would get a ref and acquire the device lock of the returned auxiliary device. After the lock is acquired, a second devcom check is needed[2]. In addition, update The callers to pair the get operation with the new put operation, ensuring the lock is held while the auxiliary device is being operated on and released afterwards. The "primary" designation is determined once in sd_register(). It's set before devcom is marked ready, and it never changes after that. In Addition, The primary path never locks a secondary: When the primary device invoke mlx5_sd_get_adev(), it sees dev == primary and returns. no additional lock is taken. Therefore lock ordering is always: secondary_lock -> primary_lock. The reverse never happens, so ABBA deadlock is impossible. [1] for example: BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 4 UID: 0 PID: 3945 Comm: bash Not tainted 6.19.0-rc3+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 [mlx5_core] Call Trace: <TASK> mlx5e_remove+0x82/0x12a [mlx5_core] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x140 device_del+0x159/0x3c0 ? devl_param_driverinit_value_get+0x29/0x80 mlx5_rescan_drivers_locked+0x92/0x160 [mlx5_core] mlx5_unregister_device+0x34/0x50 [mlx5_core] mlx5_uninit_one+0x43/0xb0 [mlx5_core] remove_one+0x4e/0xc0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0xe90 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] CPU0 (primary) CPU1 (secondary) ========================================================================== mlx5e_remove() (device_lock held) mlx5e_remove() (2nd device_lock held) mlx5_sd_get_adev() mlx5_devcom_comp_is_ready() => true device_lock(primary) mlx5_sd_get_adev() ==> ret adev _mlx5e_remove() mlx5_sd_cleanup() // mlx5e_remove finished // releasing device_lock //need another check here... mlx5_devcom_comp_is_ready() => false Fixes: 381978d28317 ("net/mlx5e: Create single netdev per SD group") Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504180206.268568-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net/mlx5e: SD, Fix missing cleanup on probe errorShay Drory
When _mlx5e_probe() fails, the preceding successful mlx5_sd_init() is not undone. Auxiliary bus probe failure skips binding, so mlx5e_remove() is never called for that adev and the matching mlx5_sd_cleanup() never runs - leaking the per-dev SD struct. Call mlx5_sd_cleanup() on the probe error path to balance mlx5_sd_init(). A similar gap exists on the resume path: mlx5_sd_init() and mlx5_sd_cleanup() are currently bundled with both probe/remove and suspend/resume, even though only the FW alias state actually needs to follow the suspend/resume lifecycle - the sd struct allocation and devcom membership are software state that should track the full bound lifetime. As a result, a failed resume can leave a still-bound device with sd == NULL, which mlx5_sd_get_adev() can't distinguish from a non-SD device. Fixing this requires sd_suspend/resume APIs which will only destroy FW resources and is left for a follow-up series. Fixes: 381978d28317 ("net/mlx5e: Create single netdev per SD group") Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504180206.268568-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net/mlx5: SD, Keep multi-pf debugfs entries on primaryShay Drory
mlx5_sd_init() creates the "multi-pf" debugfs directory under the primary device debugfs root, but stored the dentry in the calling device's sd struct. When sd_cleanup() run on a different PF, this leads to using the wrong sd->dfs for removing entries, which results in memory leak and an error in when re-creating the SD.[1] Fix it by explicitly storing the debugfs dentry in the primary device sd struct and use it for all per-group files. [1] debugfs: 'multi-pf' already exists in '0000:08:00.1' Fixes: 4375130bf527 ("net/mlx5: SD, Add debugfs") Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504180206.268568-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net/mlx5: SD: Serialize init/cleanupShay Drory
mlx5_sd_init() / mlx5_sd_cleanup() may run from multiple PFs in the same Socket-Direct group. This can cause the SD bring-up/tear-down sequence to be executed more than once or interleaved across PFs. Protect SD init/cleanup with mlx5_devcom_comp_lock() and track the SD group state on the primary device. Skip init if the primary is already UP, and skip cleanup unless the primary is UP. The state check on cleanup is needed because sd_register() drops the devcom comp lock between marking the comp ready and assigning primary_dev on each peer. A concurrent cleanup that acquires the lock in this window would observe devcom_is_ready==true while primary_dev is still NULL (causing mlx5_sd_get_primary() to return NULL) or while the FW alias setup performed by mlx5_sd_init()'s body has not yet run (causing sd_cmd_unset_primary() to dereference a NULL tx_ft). Gate the cleanup body on primary_sd->state == MLX5_SD_STATE_UP, which is set only at the very end of mlx5_sd_init() under the same comp lock - so observing UP guarantees primary_dev, secondaries[], tx_ft, and dfs are all populated. Also bail explicitly if mlx5_sd_get_primary() returns NULL, in case state is checked on a peer whose primary_dev hasn't been assigned yet. In addition, move mlx5_devcom_comp_set_ready(false) from sd_unregister() into the cleanup's locked section, including the !primary and state != UP early-exit paths, so the device cannot unregister and free its struct mlx5_sd while devcom is still marked ready. A concurrent init acquiring the devcom lock will now observe devcom is no longer ready and bail out immediately. Fixes: 381978d28317 ("net/mlx5e: Create single netdev per SD group") Signed-off-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504180206.268568-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net/mlx5e: psp: Hook PSP dev reg/unreg to profile enable/disableCosmin Ratiu
devlink reload while PSP connections are active does: mlx5_unload_one_devl_locked() -> mlx5_detach_device() -> _mlx5e_suspend() -> mlx5e_detach_netdev() -> profile->cleanup_rx -> profile->cleanup_tx -> mlx5e_destroy_mdev_resources() -> mlx5_core_dealloc_pd() fails: ... mlx5_core 0000:08:00.0: mlx5_cmd_out_err:821:(pid 19722): DEALLOC_PD(0x801) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0xef0c8a), err(-22) ... The reason for failure is the existence of TX keys, which are removed by the PSP dev unregistration happening in: profile->cleanup() -> mlx5e_psp_unregister() -> mlx5e_psp_cleanup() -> psp_dev_unregister() ...but this isn't invoked in the devlink reload flow, only when changing the NIC profile (e.g. when transitioning to switchdev mode) or on dev teardown. Move PSP device registration into mlx5e_nic_enable(), and unregistration into the corresponding mlx5e_nic_disable(). These functions are called during netdev attach/detach after RX & TX are set up. This ensures that the keys will be gone by the time the PD is destroyed. Fixes: 89ee2d92f66c ("net/mlx5e: Support PSP offload functionality") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504181100.269334-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net/mlx5e: psp: Expose only a fully initialized priv->pspCosmin Ratiu
Currently, during PSP init, priv->psp is initialized to an incompletely built psp struct. Additionally, on fs init failure priv->psp is reset to NULL. Change this so that only a fully initialized priv->psp is set, which makes the code easier to reason about in failure scenarios. Fixes: af2196f49480 ("net/mlx5e: Implement PSP operations .assoc_add and .assoc_del") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504181100.269334-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net/mlx5e: psp: Fix invalid access on PSP dev registration failCosmin Ratiu
priv->psp->psp is initialized with the PSP device as returned by psp_dev_create(). This could also return an error, in which case a future psp_dev_unregister() will result in unpleasantness. Avoid that by using a local variable and only saving the PSP device when registration succeeds. In case psp_dev_create() fails, priv->psp and steering structs are left in place, but they will be inert. The unchecked access of priv->psp in mlx5e_psp_offload_handle_rx_skb() won't happen because without a PSP device, there can be no SAs added and therefore no packets will be successfully decrypted and be handed off to the SW handler. Fixes: 89ee2d92f66c ("net/mlx5e: Support PSP offload functionality") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504181100.269334-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net: wwan: t7xx: validate port_count against message length in ↵Pavitra Jha
t7xx_port_enum_msg_handler t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as a loop bound over port_msg->data[] without checking that the message buffer contains sufficient data. A modem sending port_count=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes. Add a sizeof(*port_msg) check before accessing the port message header fields to guard against undersized messages. Add a struct_size() check after extracting port_count and before the loop. In t7xx_parse_host_rt_data(), guard the rt_feature header read with a remaining-buffer check before accessing data_len, validate feat_data_len against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset. Pass msg_len from both call sites: skb->len at the DPMAIF path after skb_pull(), and the validated feat_data_len at the handshake path. Fixes: da45d2566a1d ("net: wwan: t7xx: Add control port") Cc: stable@vger.kernel.org Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com> Link: https://patch.msgid.link/20260501110713.145563-1-jhapavitra98@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net: dsa: mv88e6xxx: enable devlink ATU hash param for 6320 familyMarek Behún
Commit 23e8b470c7788 ("net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.") introduced ATU hash algorithm access via devlink, but did not enable it for the 6320 family. Do it now. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://patch.msgid.link/20260504153227.1390546-6-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 familyMarek Behún
Commit 9e5baf9b3636 ("net: dsa: mv88e6xxx: add RMU disable op") did not add the .rmu_disable() method for the 6320 family. Add it now. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://patch.msgid.link/20260504153227.1390546-5-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-05net: dsa: mv88e6xxx: define .pot_clear() for 6321Marek Behún
Commit 9e907d739cc3 ("net: dsa: mv88e6xxx: add POT operation") did not add the .pot_clear() method to the 6321 switch operations structure. Add them now. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://patch.msgid.link/20260504153227.1390546-4-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>