Sean Wang [Thu, 19 Feb 2026 00:39:59 +0000 (18:39 -0600)]
wifi: mt76: mt7921: handle MT7902 irq_map quirk with mutable copy
MT7902 PCIe requires a different wm2_complete_mask value, so introduce a
mutable per-device copy of the default irq_map and override the field
only for this chip. Other devices continue using the shared const
template.
This is a prerequisite patch before enabling MT7902 PCIe support.
Co-developed-by: Xiong Huang <xiong.huang@mediatek.com> Signed-off-by: Xiong Huang <xiong.huang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260219004007.19733-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Thu, 19 Feb 2026 00:39:57 +0000 (18:39 -0600)]
wifi: mt76: connac: use is_connac2() to replace is_mt7921() checks
Unify all per-chip conditionals under the new is_connac2() helper. This
avoids confusion caused by the previous is_mt7921() check, which
implicitly covered multiple connac2 chipsets and no longer reflected its
actual scope. This is a clean-up only change with no functional impact.
StanleyYP Wang [Thu, 12 Feb 2026 09:03:10 +0000 (17:03 +0800)]
wifi: mt76: mt7996: apply calibration-free data from OTP
Before sending the current EEPROM data to the firmware, read the
calibration-free data (FT data) from the efuse and merge it with
the existing EEPROM data.
StanleyYP Wang [Thu, 12 Feb 2026 09:03:08 +0000 (17:03 +0800)]
wifi: mt76: add external EEPROM support for mt799x chipsets
For the MT7992 and MT7990 chipsets, efuse mode is not supported because
there is insufficient space in the efuse to store the calibration data.
Therefore, an additional on-chip EEPROM is added to address this
limitation.
Allen Ye [Thu, 19 Feb 2026 00:30:27 +0000 (16:30 -0800)]
wifi: mt76: fix backoff fields and max_power calculation
The maximum power value may exist in either the data or backoff field.
Previously, backoff power limits were not considered in txpower reporting.
This patch ensures mt76 also considers backoff values in the SKU table.
Also, each RU entry (RU26, RU52, RU106, BW20, ...) in the DTS corresponds
to 10 stream combinations (1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss,
4T2ss, 3T3ss, 4T3ss, 4T4ss).
For beamforming tables:
- In connac2, beamforming entries for BW20~BW160, and OFDM do not include
1T1ss.
- In connac3, beamforming entries for BW20~BW160, and RU include 1T1ss,
but OFDM beamforming does not include 1T1ss.
Non-beamforming and RU entries for both connac2 and connac3 include 1T1ss.
Chad Monroe [Mon, 8 Dec 2025 14:31:32 +0000 (14:31 +0000)]
wifi: mt76: fix deadlock in remain-on-channel
mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel()
while already holding dev->mutex. Since mt76_set_channel() also acquires
dev->mutex, this results in a deadlock.
Use __mt76_set_channel() instead of mt76_set_channel().
Add cancel_delayed_work_sync() for mac_work before acquiring the mutex
in mt76_remain_on_channel() to prevent a secondary deadlock with the
mac_work workqueue.
Sean Wang [Mon, 26 Jan 2026 18:00:13 +0000 (12:00 -0600)]
wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync
roc_abort_sync() can deadlock with roc_work(). roc_work() holds
dev->mt76.mutex, while cancel_work_sync() waits for roc_work()
to finish. If the caller already owns the same mutex, both
sides block and no progress is possible.
This deadlock can occur during station removal when
mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() ->
mt7921_roc_abort_sync() invokes cancel_work_sync() while
roc_work() is still running and holding dev->mt76.mutex.
This avoids the mutex deadlock and preserves exactly-once
work ownership.
Fixes: 352d966126e6 ("wifi: mt76: mt7921: fix a potential association failure upon resuming") Co-developed-by: Quan Zhou <quan.zhou@mediatek.com> Signed-off-by: Quan Zhou <quan.zhou@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260126180013.8167-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Quan Zhou [Fri, 23 Jan 2026 02:16:25 +0000 (10:16 +0800)]
wifi: mt76: mt7921: fix ROC abort flow interruption in mt7921_roc_work
The mt7921_set_roc API may be executed concurrently with mt7921_roc_work,
specifically between the following code paths:
- The check and clear of MT76_STATE_ROC in mt7921_roc_work:
if (!test_and_clear_bit(MT76_STATE_ROC, &phy->mt76->state))
return;
- The execution of ieee80211_iterate_active_interfaces.
This race condition can interrupt the ROC abort flow, resulting in
the ROC process failing to abort as expected.
To address this defect, the modification of MT76_STATE_ROC is now
protected by mt792x_mutex_acquire(phy->dev). This ensures that
changes to the ROC state are properly synchronized, preventing
race conditions and ensuring the ROC abort flow is not interrupted.
Leon Yen [Tue, 20 Jan 2026 16:31:52 +0000 (00:31 +0800)]
wifi: mt76: mt7925: fix tx power setting failure after chip reset
After the chip reset, the procedure to set the tx power will not be
successful because the previous region setting is still remains.
Clear the region setting during MAC initialization and allow it to be
reset to finalize the TX power setting.
Zilin Guan [Fri, 16 Jan 2026 14:49:19 +0000 (14:49 +0000)]
wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()
mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to
be freed eventually by mt76_mcu_skb_send_msg(). However, currently if
an intermediate function fails before sending, the allocated skb is
leaked.
Specifically, mt76_connac_mcu_sta_wed_update() and
mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory
leak in the error path.
Fix this by explicitly freeing the skb in these error paths.
Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on
mt7996_mcu_sta_key_tlv error") made a similar change.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Sean Wang [Tue, 16 Dec 2025 01:38:49 +0000 (19:38 -0600)]
wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync
roc_abort_sync() can deadlock with roc_work(). roc_work() holds
dev->mt76.mutex, while cancel_work_sync() waits for roc_work()
to finish. If the caller already owns the same mutex, both
sides block and no progress is possible.
This deadlock can occur during station removal when
mt76_sta_state() -> mt76_sta_remove() ->
mt7925_mac_sta_remove_link() -> mt7925_mac_link_sta_remove() ->
mt7925_roc_abort_sync() invokes cancel_work_sync() while
roc_work() is still running and holding dev->mt76.mutex.
This avoids the mutex deadlock and preserves exactly-once
work ownership.
Fixes: 45064d19fd3a ("wifi: mt76: mt7925: fix a potential association failure upon resuming") Co-developed-by: Quan Zhou <quan.zhou@mediatek.com> Signed-off-by: Quan Zhou <quan.zhou@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20251216013849.17976-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Michael Lo [Mon, 12 Jan 2026 11:40:07 +0000 (19:40 +0800)]
wifi: mt76: mt7925: Skip scan process during suspend.
We are experiencing command timeouts because an upper layer triggers
an unexpected scan while the system/device is in suspend.
The upper layer should not initiate scans until the NIC has fully resumed.
We want to prevent scans during suspend and avoid timeouts without harming
power management or user experience.
Sean Wang [Tue, 16 Dec 2025 02:20:17 +0000 (20:20 -0600)]
wifi: mt76: mt7925: drop puncturing handling from BSS change path
IEEE80211_CHANCTX_CHANGE_PUNCTURING is a channel context change
flag and should not be checked in the BSS change handler, where
the changed mask represents enum ieee80211_bss_change.
Remove the puncturing handling from the BSS path and rely on
mt7925_change_chanctx() to update puncturing configuration.
Lorenzo Bianconi [Thu, 22 Jan 2026 10:40:00 +0000 (11:40 +0100)]
wifi: mt76: mt7996: Store DMA mapped buffer addresses in mt7996_npu_hw_init()
In order to not always reallocate them during NPU reset, store the DMA
mapped buffer addresses allocated by mt7996_npu_hw_init routine in
mt7996 structure.
Lorenzo Bianconi [Thu, 22 Jan 2026 10:39:58 +0000 (11:39 +0100)]
wifi: mt76: Do not reset idx for NPU tx queues during reset
Do not run reset_q callaback with reset_idx set to true for NPU Tx
queues. This is a preliminary patch to properly manage reset procedure
when NPU offloading is enabled.
Introduce __mt7996_npu_hw_init utility routine in order to run it
holding mt76 mutex and move NPU hw re-initialization before restarting
the NAPIs during device reset.
Lorenzo Bianconi [Thu, 22 Jan 2026 10:39:48 +0000 (11:39 +0100)]
wifi: mt76: mt7996: Fix BAND2 tx queues initialization when NPU is enabled
Fix BAND2 tx queues initialization for MT7990 chipset when NPU is
enabled. This is a preliminary patch to enable NPU offload for MT7996
(Eagle) chipset.
Lorenzo Bianconi [Thu, 22 Jan 2026 10:39:47 +0000 (11:39 +0100)]
wifi: mt76: always enable RRO queues for non-MT7992 chipset
MT7990 NPU binary requires to initialize NPU desc_base after configuring
ring_size. This is a preliminary patch to enable NPU offload for MT7996
(Eagle) chipset.
Lorenzo Bianconi [Thu, 22 Jan 2026 10:39:45 +0000 (11:39 +0100)]
wifi: mt76: mt7996: Fix NPU stop procedure
Move mt7996_npu_hw_stop routine before disabling rx NAPIs in order to
fix NPU stop procedure used during device L1 SER recovery.
Add missing usleep_range in mt7996_npu_hw_stop().
All MT76 rx queues have an associated page_pool even if the queue is not
associated to a NAPI (e.g. WED RRO queues with WED enabled). Destroy the
page_pool running mt76_dma_cleanup routine during module unload.
Moreover returns pages to the page pool if WED is not enabled for WED RRO
queues.
Leon Yen [Thu, 9 Oct 2025 02:01:58 +0000 (10:01 +0800)]
wifi: mt76: mt7921: fix a potential clc buffer length underflow
The buf_len is used to limit the iterations for retrieving the country
power setting and may underflow under certain conditions due to changes
in the power table in CLC.
This underflow leads to an almost infinite loop or an invalid power
setting resulting in driver initialization failure.
Cc: stable@vger.kernel.org Fixes: fa6ad88e023d ("wifi: mt76: mt7921: fix country count limitation for CLC") Signed-off-by: Leon Yen <leon.yen@mediatek.com> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20251009020158.1923429-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
Rory Little [Thu, 4 Sep 2025 00:07:11 +0000 (17:07 -0700)]
wifi: mt76: mt7921: Place upper limit on station AID
Any station configured with an AID over 20 causes a firmware crash.
This situation occurred in our testing using an AP interface on 7922
hardware, with a modified hostapd, sourced from Mediatek's OpenWRT
feeds.
In stock hostapd, station AIDs begin counting at 1, and this
configuration is prevented with an upper limit on associated stations.
However, the modified hostapd began allocation at 65, which caused the
firmware to crash. This fix does not allow these AIDs to work, but will
prevent the firmware crash.
This crash was only seen on IFTYPE_AP interfaces, and the fix does not
appear to have an effect on IFTYPE_STATION behavior.
Alok Tiwari [Mon, 13 Oct 2025 09:08:24 +0000 (02:08 -0700)]
wifi: mt76: mt7996: fix FCS error flag check in RX descriptor
The mt7996 driver currently checks the MT_RXD3_NORMAL_FCS_ERR bit in
rxd1 whereas other Connac3-based drivers(mt7925) correctly check this
bit in rxd3.
Since the MT_RXD3_NORMAL_FCS_ERR bit is defined in the fourth RX
descriptor word (rxd3), update mt7996 to use the proper descriptor
field. This change aligns mt7996 with mt7925 and the rest of the
Connac3 family.
Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251013090826.753992-1-alok.a.tiwari@oracle.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
Ming Yen Hsieh [Thu, 4 Sep 2025 03:06:47 +0000 (11:06 +0800)]
wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi
Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to
avoid a potential kernel panic in scenarios where `vif` might not be
initialized.
Zac Bowling [Tue, 20 Jan 2026 20:10:32 +0000 (12:10 -0800)]
wifi: mt76: fix list corruption in mt76_wcid_cleanup
mt76_wcid_cleanup() was not removing wcid entries from sta_poll_list
before mt76_reset_device() reinitializes the master list. This leaves
stale pointers in wcid->poll_list, causing list corruption when
mt76_wcid_add_poll() later checks list_empty() and tries to add the
entry back.
The fix adds proper cleanup of poll_list in mt76_wcid_cleanup(),
matching how tx_list is already handled. This is similar to what
mt7996_mac_sta_deinit_link() already does correctly.
Fixes list corruption warnings like:
list_add corruption. prev->next should be next (ffffffff...)
Ryder Lee [Wed, 21 Jan 2026 17:41:58 +0000 (09:41 -0800)]
wifi: mt76: mt7996: add support for ERP CTS & HT protection
This patch adds support for handling BSS_CHANGED_ERP_CTS_PROT and
BSS_CHANGED_HT.
With this change, when the Wi-Fi driver needs to adjust its behavior for
compatibility or performance, especially concerning older 11g/n devices,
by enabling or disabling CTS protection frames, often for hidden SSIDs or
to manage legacy clients.
It also introduces debugfs options to manually control protection mode,
allowing users to select betweenno protection, RTS/CTS, and CTS-to-self.
Ryder Lee [Wed, 21 Jan 2026 17:41:57 +0000 (09:41 -0800)]
wifi: mt76: mt7915: fix use_cts_prot support
With this fix, when driver needs to adjust its behavior for compatibility,
especially concerning older 11g/n devices, by enabling or disabling CTS
protection frames, often for hidden SSIDs or to manage legacy clients.
Ryder Lee [Wed, 21 Jan 2026 17:41:56 +0000 (09:41 -0800)]
wifi: mt76: mt7615: fix use_cts_prot support
Driver should not directly write WTBL to prevent overwritten issues.
With this fix, when driver needs to adjust its behavior for compatibility,
especially concerning older 11g/n devices, by enabling or disabling CTS
protection frames, often for hidden SSIDs or to manage legacy clients.
Christian Hewitt [Sat, 27 Dec 2025 11:22:19 +0000 (11:22 +0000)]
wifi: mt7601u: check multiple firmware paths
The linux-firmware repo moved mt7601u.bin from its root folder to
the mediatek sub-folder some time ago, but the driver still tries
to load firmware from the old location. Users might have firmware
in either location so update the driver to check both.
Leon Yen [Mon, 15 Dec 2025 12:22:31 +0000 (20:22 +0800)]
wifi: mt76: mt792x: Fix a potential deadlock in high-load situations
A deadlock may occur between two works, ps_work and mac_work, if their work
functions run simultaneously as they attempt to cancel each other by
calling cancel_delayed_work_sync().
In high-load situations, they are queued but may not have chance to be
executed until the CPUs are released. Once the CPUs are available, there
is a high possibility that the ps_work function and mac_work function will
be executed simultaneously, resulting in a possible deadlock.
This patch replaces cancel_delayed_work_sync() with cancel_delayed_work()
in ps_work to eliminate the deadlock and make the code easier to maintain.
Leon Yen [Thu, 11 Dec 2025 12:38:36 +0000 (20:38 +0800)]
wifi: mt76: mt7925: Fix incorrect MLO mode in firmware control
The selection of MLO mode should depend on the capabilities of the STA
rather than those of the peer AP to avoid compatibility issues with
certain APs, such as Xiaomi BE5000 WiFi7 router.
Sean Wang [Tue, 16 Dec 2025 00:59:30 +0000 (18:59 -0600)]
wifi: mt76: mt7921: Reset ampdu_state state in case of failure in mt76_connac2_tx_check_aggr()
Reset ampdu_state if ieee80211_start_tx_ba_session() fails in
mt76_connac2_tx_check_aggr(), otherwise the driver may incorrectly
assume aggregation is active and skip future BA setup attempts.
wifi: mt76: mt7996: Switch to the secondary link if the default one is removed
Switch to the secondary link if available in mt7996_mac_sta_remove_links
routine if the primary one is removed.
Moreover reset secondary link index for single link scenario.
Quan Zhou [Thu, 27 Nov 2025 07:49:11 +0000 (15:49 +0800)]
wifi: mt76: mt7925: fix AMPDU state handling in mt7925_tx_check_aggr
Previously, the AMPDU state bit for a given TID was set before attempting
to start a BA session, which could result in the AMPDU state being marked
active even if ieee80211_start_tx_ba_session() failed. This patch changes
the logic to only set the AMPDU state bit after successfully starting a BA
session, ensuring proper synchronization between AMPDU state and BA session
status.
This fixes potential issues with aggregation state tracking and improves
compatibility with mac80211 BA session management.
Since some radar specifications maintained by the driver are incorrect
and are now also maintained by the firmware, offload the initialization
procedure to the firmware.
This fixes issues for radar detection rate testings.
StanleyYP Wang [Mon, 15 Dec 2025 06:37:24 +0000 (14:37 +0800)]
wifi: mt76: mt7996: set specific BSSINFO and STAREC commands after channel switch
After channel switch, some tags of BSSINFO (rfch) and STAREC (bfer,
rate_ctrl) commands should also be updated. Otherwise, a BSS might not be
able to transmit with its peer using correct bandwidth.
StanleyYP Wang [Mon, 15 Dec 2025 06:37:23 +0000 (14:37 +0800)]
wifi: mt76: mt7996: fix the behavior of radar detection
RDD_DET_MODE is a firmware command intended for testing and does not
pause TX after radar detection, so remove it from the normal flow;
instead, use the MAC_ENABLE_CTRL firmware command to resume TX after
the radar-triggered channel switch completes.
Paolo Abeni [Thu, 19 Mar 2026 14:30:19 +0000 (15:30 +0100)]
Merge tag 'wireless-next-2026-03-19' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Aside from various small improvements/cleanups, not much:
- cfg80211/mac80211: S1G and UHR improvements
- hwsim: incumbent signal report test support
* tag 'wireless-next-2026-03-19' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (31 commits)
qtnfmac: use alloc_netdev macro for single queue devices
wifi: libertas: don't kill URBs in interrupt context
wifi: libertas: use USB anchors for tracking in-flight URBs
wifi: nl80211: use int for band coming from netlink
wifi: rsi_91x_usb: do not pause rfkill polling when stopping mac80211
wifi: mac80211: fix STA link removal during link removal
wifi: nl80211: reject S1G/60G with HT chantype
wifi: ieee80211: fix definition of EHT-MCS 15 in MRU
wifi: cfg80211: check non-S1G width with S1G chandef
wifi: cfg80211: restrict cfg80211_chandef_create() to only HT-based bands
wifi: mac80211: don't use cfg80211_chandef_create() for default chandef
wifi: mac80211: Remove deleted sta links in ieee80211_ml_reconf_work()
wifi: b43: use register definitions in nphy_op_software_rfkill
wifi: cfg80211: split control freq check from chandef check
wifi: mac80211: always use full chanctx compatible check
wifi: mac80211: refactor chandef tracing macros
wifi: mac80211: validate HE 6 GHz operation when EHT is used
wifi: nl80211: split out UHR operation information
wifi: mwifiex: drop redundant device reference
wifi: rt2x00: drop redundant device reference
...
====================
br_vlan_fill_forward_path_mode() sets DEV_PATH_BR_VLAN_UNTAG_HW when
filling in from brlan.1 towards wlan1. But it should be set to
DEV_PATH_BR_VLAN_UNTAG in this case. Using BR_VLFLAG_ADDED_BY_SWITCHDEV
is not correct. The dsa switchdev adds it as a foreign port.
The same problem for all foreignly added dsa vlans on the bridge.
First add the vlan, trying only native devices.
If this fails, we know this may be a vlan from a foreign device.
Use BR_VLFLAG_TAGGING_BY_SWITCHDEV to make sure DEV_PATH_BR_VLAN_UNTAG_HW
is set only when there if no foreign device involved.
Paolo Abeni [Thu, 19 Mar 2026 11:50:42 +0000 (12:50 +0100)]
Merge tag 'ovpn-net-next-20260317' of https://github.com/OpenVPN/ovpn-net-next
Antonio Quartulli says:
====================
Included features:
* use bitops.h API when possible
* send netlink notification in case of client float event
* implement support for asymmetric peer IDs
* consolidate memory allocations during crypto operations
* add netlink notification check in selftests
* add FW mark check in selftest
* tag 'ovpn-net-next-20260317' of https://github.com/OpenVPN/ovpn-net-next:
ovpn: consolidate crypto allocations in one chunk
selftests: ovpn: add test for the FW mark feature
selftests: ovpn: check asymmetric peer-id
ovpn: add support for asymmetric peer IDs
selftests: ovpn: add notification parsing and matching
ovpn: notify userspace on client float event
ovpn: pktid: use bitops.h API
ovpn: use correct array size to parse nested attributes in ovpn_nl_key_swap_doit
selftests: ovpn: allow compiling ovpn-cli.c with mbedtls3
====================
Qingfang Deng [Tue, 17 Mar 2026 05:41:40 +0000 (13:41 +0800)]
l2tp: ppp: use max L2TP header size for PPP channel hdrlen
chan.hdrlen is read once at channel registration by
ppp_register_net_channel(), and used to set the PPP net device's
hard_header_len. It was set to PPPOL2TP_L2TP_HDR_SIZE_NOSEQ (6), which
is 4 bytes too small if sequence numbers are later enabled via
setsockopt(PPPOL2TP_SO_SENDSEQ), causing unnecessary skb reallocations
on the TX path.
The setsockopt handler attempted to change netdev's hard_header_len by
updating chan.hdrlen, but the PPP layer never re-reads it after the
registration, so the update had no effect.
To avoid the unnecessary reallocations, set chan.hdrlen to
PPPOL2TP_L2TP_HDR_SIZE_SEQ (10) unconditionally at registration and
remove the ineffective update in the setsockopt callback.
The test depends on accepting a packet that is larger than the
advertised window and that does not trigger an immediate ACK.
Previously, the test might still pass even if kernel behavior changed
unexpectedly. Add assertions verifying that the large packet was
accepted and no ACK was sent.
wifi: libertas: don't kill URBs in interrupt context
Serialization for the TX path was enforced by calling
usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before
a previous URB was completed. usb_tx_block() can be called from
interrupt context (e.g. in the HCD giveback path), so we can't always
use it to kill in-flight URBs.
Prevent sleeping during interrupt context by checking the tx_submitted
anchor for existing URBs. We now return -EBUSY, to indicate there's
a pending request.
Reported-by: syzbot+74afbb6355826ffc2239@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=74afbb6355826ffc2239 Fixes: d66676e6ca96 ("wifi: libertas: fix WARNING in usb_tx_block") Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com> Link: https://patch.msgid.link/20260313-libertas-usb-anchors-v1-2-915afbe988d7@igalia.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wifi: libertas: use USB anchors for tracking in-flight URBs
The libertas driver currently handles URB lifecycles manually, which
makes it non-trivial to check if specific URBs are pending or not. Add
anchors for TX/RX URBs, and use those to track in-flight requests.
Johannes Berg [Mon, 16 Mar 2026 11:30:50 +0000 (12:30 +0100)]
wifi: nl80211: use int for band coming from netlink
This was pointed out before, but there are issues with just
removing the <0 check since enum representation isn't fixed,
nla_type() returns int but really can only return small
non-negative values, etc. Now newer versions of sparse are
also starting to warn on it. Just use int for the band var.
Ville Nummela [Wed, 18 Mar 2026 08:19:12 +0000 (10:19 +0200)]
wifi: rsi_91x_usb: do not pause rfkill polling when stopping mac80211
Removing rsi_91x USB adapter could cause rtnetlink to lock up.
When rsi_mac80211_stop is called, wiphy_lock is locked. Call to
wiphy_rfkill_stop_polling would wait until the work queue has
finished, but because the work queue waits for wiphy_lock, that
would never happen.
Moving the call to rsi_disconnect avoids the lock up.
Johannes Berg [Wed, 18 Mar 2026 17:06:22 +0000 (18:06 +0100)]
wifi: mac80211: fix STA link removal during link removal
ieee80211_sta_free_link() only frees the link and doesn't
unhash it, so it can't be used here. Instead this needs
to use ieee80211_sta_remove_link(), which unhashes it. An
argument against it was that it also calls the driver and
that already happened, but calls to the driver removing a
link that's already removed are suppressed, so that's not
actually an issue. Use it to fix the hashtable.
Haiyang Zhang [Tue, 17 Mar 2026 19:18:07 +0000 (12:18 -0700)]
net: mana: Add ethtool counters for RX CQEs in coalesced type
For RX CQEs with type CQE_RX_COALESCED_4, to measure the coalescing
efficiency, add counters to count how many contains 2, 3, 4 packets
respectively.
Also, add a counter for the error case of first packet with length == 0.
Haiyang Zhang [Tue, 17 Mar 2026 19:18:06 +0000 (12:18 -0700)]
net: mana: Add support for RX CQE Coalescing
Our NIC can have up to 4 RX packets on 1 CQE. To support this feature,
check and process the type CQE_RX_COALESCED_4. The default setting is
disabled, to avoid possible regression on latency.
And, add ethtool handler to switch this feature. To turn it on, run:
ethtool -C <nic> rx-cqe-frames 4
To turn it off:
ethtool -C <nic> rx-cqe-frames 1
The rx-cqe-nsec is the time out value in nanoseconds after the first
packet arrival in a coalesced CQE to be sent. It's read-only for this
NIC.
Bobby Eshleman [Tue, 17 Mar 2026 00:56:15 +0000 (17:56 -0700)]
selftests/vsock: auto-detect kernel for guest VMs
When running vmtest.sh inside a nested VM the running kernel may not be
installed on the filesystem at the standard /boot/ or /usr/lib/modules/
paths.
Previously, this would cause vng to fail with "does not exist" since it
could not find the kernel image. Instead, this patch uses --dry-run to
detect if the kernel is available. If not, then we fall back to the
kernel in the kernel source tree. If that fails, then we die.
This way runners, like NIPA, can use vng --run arch/x86/boot/bzImage to
setup an outer VM, and vmtest.sh will still do the right thing setting
up the inner VM.
Due to job control issues in vng, a workaround is used to prevent 'make
kselftest TARGETS=vsock' from hanging until test timeout. A PR has been
placed upstream to solve the issue in vng:
Jakub Kicinski [Thu, 19 Mar 2026 02:08:49 +0000 (19:08 -0700)]
Merge branch 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Tariq Toukan says:
====================
mlx5-next updates 2026-03-17
The following pull-request contains common mlx5 updates
* 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
net/mlx5: Expose MLX5_UMR_ALIGN definition
{net/RDMA}/mlx5: Add LAG demux table API and vport demux rules
net/mlx5: Add VHCA RX flow destination support for FW steering
net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number
net/mlx5: E-switch, modify peer miss rule index to vhca_id
net/mlx5: LAG, use xa_alloc to manage LAG device indices
net/mlx5: LAG, replace pf array with xarray
net/mlx5: Add silent mode set/query and VHCA RX IFC bits
net/mlx5: Add IFC bits for shared headroom pool PBMC support
net/mlx5: Expose TLP emulation capabilities
net/mlx5: Add TLP emulation device capabilities
====================
Eric Biggers [Mon, 16 Mar 2026 22:14:53 +0000 (15:14 -0700)]
qed: Reimplement qed_mcast_bin_from_mac() using library functions
The calculation done by qed_calc_crc32c() is the standard
least-significant-bit-first CRC-32C except it uses
most-significant-bit-first order for the actual CRC variable. That is
equivalent to bit-reflecting the input and output CRC. Replace it with
equivalent calls to the corresponding library functions.
Tested with a simple userspace program which tested that the old and new
implementations of qed_mcast_bin_from_mac() produce the same outputs.
This removes linux/mdio-gpio.h and linux/platform_data/mdio-gpio.h as
they are not needed due to the symbols either being used by the
mdio-gpio module alone or not used at all.
====================
The three defines from the linux/mdio-gpio.h header are only used in the
mdio-gpio module. There's no reason to have them in a public header.
Move them into the driver and remove mdio-gpio.h.
MDIO-based regmap is the last user of config symbol MDIO_BUS.
MDIO access needs a MII bus, which requires PHYLIB for the provider part.
Therefore make REGMAP_MDIO depend on PHYLIB, what allows to remove
config symbol MDIO_BUS.
====================
Heiner Kallweit [Sun, 15 Mar 2026 16:48:43 +0000 (17:48 +0100)]
regmap: mdio: make it depend on PHYLIB
MDIO-based regmap is the last user of config symbol MDIO_BUS.
MDIO access needs a MII bus, which requires PHYLIB for the provider part.
Therefore make REGMAP_MDIO depend on PHYLIB, what allows to remove
config symbol MDIO_BUS in a follow-up patch.
Note: After c5a219395b4e ("regmap: Move selecting for REGMAP_MDIO and
REGMAP_IRQ") switching to "depends on" should be fine, w/o risk
of a circular dependency.
Nimrod Oren [Tue, 17 Mar 2026 10:49:34 +0000 (12:49 +0200)]
net/mlx5e: Add hds-thresh query support via ethtool
Add support for reporting HDS (Header-Data Split) threshold via
ethtool. When applicable, mlx5 hardware splits packets of all sizes with
no configurable threshold, so report both hds-thresh and hds-thresh-max
as 0 (i.e. always split regardless of size).
"make dtbs_check" reports several warnings due to some KSZ8041RNLI PHY
nodes having the "micrel,led-mode" property, while the DT bindings
prohibit this.
Apparently the DT bindings are incorrect, so this patch series fixes
that, after a customary cleanup.
====================
dt-bindings: net: micrel: KSZ8041RNLI supports LED mode
Micrel KSZ8041RNLI supports LED mode, just like KSZ8041.
This fixes (a.o.) the following "make dtbs_check" warning:
arch/arm/boot/dts/renesas/r8a7791-koelsch.dtb: ethernet-phy@1 (ethernet-phy-id0022.1537): False schema does not allow 1
from schema $id: http://devicetree.org/schemas/net/micrel.yaml
projects / thirdparty / kernel / linux.git / log
