summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-05-22Merge tag 'wireless-next-2025-05-22' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Lots of new things, notably: * ath12k: monitor mode for WCN7850, better 6 GHz regulatory * brcmfmac: SAE for some Cypress devices * iwlwifi: rework device configuration * mac80211: scan improvements with MLO * mt76: EHT improvements, new device IDs * rtw88: throughput improvements * rtw89: MLO, STA/P2P concurrency improvements, SAR * tag 'wireless-next-2025-05-22' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (389 commits) wifi: mt76: mt7925: add rfkill_poll for hardware rfkill wifi: mt76: support power delta calculation for 5 TX paths wifi: mt76: fix available_antennas setting wifi: mt76: mt7996: fix RX buffer size of MCU event wifi: mt76: mt7996: change max beacon size wifi: mt76: mt7996: fix invalid NSS setting when TX path differs from NSS wifi: mt76: mt7996: drop fragments with multicast or broadcast RA wifi: mt76: mt7996: set EHT max ampdu length capability wifi: mt76: mt7996: fix beamformee SS field wifi: mt76: remove capability of partial bandwidth UL MU-MIMO wifi: mt76: mt7925: add test mode support wifi: mt76: mt7925: extend MCU support for testmode wifi: mt76: mt7925: ensure all MCU commands wait for response wifi: mt76: mt7925: refine the sniffer commnad wifi: mt76: mt7925: prevent multiple scan commands wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() wifi: mt76: mt7925: add RNR scan support for 6GHz wifi: mt76: add mt76_connac_mcu_build_rnr_scan_param routine wifi: mt76: scan: Fix 'mlink' dereferenced before IS_ERR_OR_NULL check ... ==================== Link: https://patch.msgid.link/20250522165501.189958-50-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.15-rc8). Conflicts: 80f2ab46c2ee ("irdma: free iwdev->rf after removing MSI-X") 4bcc063939a5 ("ice, irdma: fix an off by one in error handling code") c24a65b6a27c ("iidc/ice/irdma: Update IDC to support multiple consumers") https://lore.kernel.org/20250513130630.280ee6c5@canb.auug.org.au No extra adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-22net/mlx5e: Convert mlx5 netdevs to instance lockingCosmin Ratiu
This patch convert mlx5 to use the new netdev instance lock in addition to the pre-existing state_lock (and the RTNL). mlx5e_priv.state_lock was already used throughout mlx5 to protect against concurrent state modifications on the same netdev, usually in addition to the RTNL. The new netdev instance lock will eventually replace it, but for now, it is acquired in addition to the existing locks in the order RTNL -> instance lock -> state_lock. All three netdev types handled by mlx5 are converted to the new style of locking, because they share a lot of code related to initializing channels and dealing with NAPI, so it's better to convert all three rather than introduce different assumptions deep in the call stack depending on the type of device. Because of the nature of the call graphs in mlx5, it wasn't possible to incrementally convert parts of the driver to use the new lock, since either all call paths into NAPI have to possess the new lock if the *_locked variants are used, or none of them can have the lock. One area which required extra care is the interaction between closing channels and devlink health reporter tasks. Previously, the recovery tasks were unconditionally acquiring the RTNL, which could lead to deadlocks in these scenarios: T1: mlx5e_close (== .ndo_stop(), has RTNL) -> mlx5e_close_locked -> mlx5e_close_channels -> mlx5e_ptp_close -> mlx5e_ptp_close_queues -> mlx5e_ptp_close_txqsqs -> mlx5e_ptp_close_txqsq -> cancel_work_sync(&ptpsq->report_unhealthy_work) waits for T2: mlx5e_ptpsq_unhealthy_work -> mlx5e_reporter_tx_ptpsq_unhealthy -> mlx5e_health_report -> devlink_health_report -> devlink_health_reporter_recover -> mlx5e_tx_reporter_ptpsq_unhealthy_recover which does: rtnl_lock(); => Deadlock. Another similar instance of this is: T1: mlx5e_close (== .ndo_stop(), has RTNL) -> mlx5e_close_locked -> mlx5e_close_channels -> mlx5e_ptp_close -> mlx5e_ptp_close_queues -> mlx5e_ptp_close_txqsqs -> mlx5e_ptp_close_txqsq -> cancel_work_sync(&sq->recover_work) waits for T2: mlx5e_tx_err_cqe_work -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report -> devlink_health_reporter_recover -> mlx5e_tx_reporter_err_cqe_recover which does: rtnl_lock(); => Another deadlock. Fix that by using the same pattern previously done in mlx5e_tx_timeout_work, where the RTNL was repeatedly tried to be acquired until either: a) it is successfully acquired or b) there's no need for the work to be done any more (channel is being closed). Now, for all three recovery tasks, the instance lock is repeatedly tried to be acquired until successful or the channel/SQ is closed. As a side-effect, drop the !test_bit(MLX5E_STATE_OPENED, &priv->state) check from mlx5e_tx_timeout_work, it's weaker than !test_bit(MLX5E_STATE_CHANNELS_ACTIVE, &priv->state) and unnecessary. Future patches will introduce new call paths (from netdev queue management ops) which can close channels (and call cancel_work_sync on the recovery tasks) without the RTNL lock and only with the netdev instance lock. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1747829342-1018757-6-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-22net/mlx5e: Don't drop RTNL during firmware flashCosmin Ratiu
There's no explanation in the original commit of why that was done, but presumably flashing takes a long time and holding RTNL for so long blocks other interactions with the netdev layer. However, the stack is moving towards netdev instance locking and dropping and reacquiring RTNL in the context of flashing introduces locking ordering issues: RTNL must be acquired before the netdev instance lock and released after it. This patch therefore takes the simpler approach by no longer dropping and reacquiring the RTNL, as soon RTNL for ethtool will be removed, leaving only the instance lock to protect against races. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1747829342-1018757-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-22eth: bnxt: fix deadlock when xdp is attached or detachedTaehee Yoo
When xdp is attached or detached, dev->ndo_bpf() is called by do_setlink(), and it acquires netdev_lock() if needed. Unlike other drivers, the bnxt driver is protected by netdev_lock while xdp is attached/detached because it sets dev->request_ops_lock to true. So, the bnxt_xdp(), that is callback of ->ndo_bpf should not acquire netdev_lock(). But the xdp_features_{set | clear}_redirect_target() was changed to acquire netdev_lock() internally. It causes a deadlock. To fix this problem, bnxt driver should use xdp_features_{set | clear}_redirect_target_locked() instead. Splat looks like: ============================================ WARNING: possible recursive locking detected 6.15.0-rc6+ #1 Not tainted -------------------------------------------- bpftool/1745 is trying to acquire lock: ffff888131b85038 (&dev->lock){+.+.}-{4:4}, at: xdp_features_set_redirect_target+0x1f/0x80 but task is already holding lock: ffff888131b85038 (&dev->lock){+.+.}-{4:4}, at: do_setlink.constprop.0+0x24e/0x35d0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dev->lock); lock(&dev->lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by bpftool/1745: #0: ffffffffa56131c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_setlink+0x1fe/0x570 #1: ffffffffaafa75a0 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_setlink+0x236/0x570 #2: ffff888131b85038 (&dev->lock){+.+.}-{4:4}, at: do_setlink.constprop.0+0x24e/0x35d0 stack backtrace: CPU: 1 UID: 0 PID: 1745 Comm: bpftool Not tainted 6.15.0-rc6+ #1 PREEMPT(undef) Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <TASK> dump_stack_lvl+0x7a/0xd0 print_deadlock_bug+0x294/0x3d0 __lock_acquire+0x153b/0x28f0 lock_acquire+0x184/0x340 ? xdp_features_set_redirect_target+0x1f/0x80 __mutex_lock+0x1ac/0x18a0 ? xdp_features_set_redirect_target+0x1f/0x80 ? xdp_features_set_redirect_target+0x1f/0x80 ? __pfx_bnxt_rx_page_skb+0x10/0x10 [bnxt_en ? __pfx___mutex_lock+0x10/0x10 ? __pfx_netdev_update_features+0x10/0x10 ? bnxt_set_rx_skb_mode+0x284/0x540 [bnxt_en ? __pfx_bnxt_set_rx_skb_mode+0x10/0x10 [bnxt_en ? xdp_features_set_redirect_target+0x1f/0x80 xdp_features_set_redirect_target+0x1f/0x80 bnxt_xdp+0x34e/0x730 [bnxt_en 11cbcce8fa11cff1dddd7ef358d6219e4ca9add3] dev_xdp_install+0x3f4/0x830 ? __pfx_bnxt_xdp+0x10/0x10 [bnxt_en 11cbcce8fa11cff1dddd7ef358d6219e4ca9add3] ? __pfx_dev_xdp_install+0x10/0x10 dev_xdp_attach+0x560/0xf70 dev_change_xdp_fd+0x22d/0x280 do_setlink.constprop.0+0x2989/0x35d0 ? __pfx_do_setlink.constprop.0+0x10/0x10 ? lock_acquire+0x184/0x340 ? find_held_lock+0x32/0x90 ? rtnl_setlink+0x236/0x570 ? rcu_is_watching+0x11/0xb0 ? trace_contention_end+0xdc/0x120 ? __mutex_lock+0x946/0x18a0 ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xa95/0x28f0 ? rcu_is_watching+0x11/0xb0 ? rcu_is_watching+0x11/0xb0 ? cap_capable+0x172/0x350 rtnl_setlink+0x2cd/0x570 Fixes: 03df156dd3a6 ("xdp: double protect netdev->xdp_flags with netdev->lock") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250520071155.2462843-1-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-22Merge tag 'mt76-next-2025-05-21' of https://github.com/nbd168/wirelessJohannes Berg
Felix Fietkau says: =================== mt76 patches for 6.16 - fixes - EHT improvements - new device ids =================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-22Merge tag 'ath-next-20250521' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git patches for v6.16 ath12k: Add monitor mode support for WCN7850. Enhance regulatory support including 6 GHz power modes. In addition, perform the usual set of bug fixes and cleanups across all supported drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-22wifi: mt76: mt7925: add rfkill_poll for hardware rfkillAllan Wang
Add mac80211 rfkill_poll ops to monitor hardware rfkill state and state change will be updated. Signed-off-by: Allan Wang <allan.wang@mediatek.com> Link: https://patch.msgid.link/20250507053131.4173691-1-allan.wang@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: support power delta calculation for 5 TX pathsShayne Chen
One variant of MT7992 has 5 TX paths, so extend the power delta function to support it. Also, rename nss_delta to path_delta since the value is based on the number of TX paths rather tha the number of spatial streams. (path delta [0.5 dBm] = 10 * log(path number) [dBm] * 2) Co-developed-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-9-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: fix available_antennas settingShayne Chen
Check if available_antennas_tx and available_antennas_rx are already set during the per-chip initialization phase; otherwise, they could be overwritten with incorrect values. Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-8-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7996: fix RX buffer size of MCU eventShayne Chen
Some management frames are first processed by the firmware and then passed to the driver through the MCU event rings. In CONNAC3, event rings do not support scatter-gather and have a size limitation of 2048 bytes. If a packet sized between 1728 and 2048 bytes arrives from an event ring, the ring will hang because the driver attempts to use scatter-gather to process it. To fix this, include the size of struct skb_shared_info in the MCU RX buffer size to prevent scatter-gather from being used for event skb in mt76_dma_rx_fill_buf(). Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-7-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7996: change max beacon sizePeter Chiu
According to hardware capability, the maximum beacon size is 2048 bytes minus the size of TLV headers. Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-6-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7996: fix invalid NSS setting when TX path differs from NSSPeter Chiu
The maximum TX path and NSS may differ on a band. For example, one variant of the MT7992 has 5 TX paths and 4 NSS on the 5 GHz band. To address this, add orig_antenna_mask to record the maximum NSS and prevent setting an invalid NSS in mt7996_set_antenna(). Fixes: 69d54ce7491d ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-5-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7996: drop fragments with multicast or broadcast RABenjamin Lin
IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145. Signed-off-by: Benjamin Lin <benjamin-jw.lin@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-4-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7996: set EHT max ampdu length capabilityPeter Chiu
Set the max AMPDU length in the EHT MAC CAP. Without this patch, the peer station cannot obtain the correct capability, which prevents achieving peak throughput on the 2 GHz band. Fixes: 1816ad9381e0 ("wifi: mt76: mt7996: add max mpdu len capability") Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-3-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7996: fix beamformee SS fieldHoward Hsu
Fix the beamformee SS field for the mt7996, mt7992 and mt7990 chipsets. For the mt7992, this value shall be set to 0x4, while the others shall be set to 0x3. Fixes: 5b20557593d4 ("wifi: mt76: connac: adjust phy capabilities based on band constraints") Signed-off-by: Howard Hsu <howard-yh.hsu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: remove capability of partial bandwidth UL MU-MIMOHoward Hsu
The firmware only supports full bandwidth UL MU-MIMO, so remove the partial bandwidth capability from HE PHY CAP. Signed-off-by: Howard Hsu <howard-yh.hsu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250515032952.1653494-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7925: add test mode supportMichael Lo
The test mode interface allows controlled execution of chip-level operations such as continuous transmission, reception tests, and register access, which are essential during bring-up, diagnostics, and factory testing. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Michael Lo <michael.lo@mediatek.com> Link: https://patch.msgid.link/20250505233618.1951021-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7925: extend MCU support for testmodeMichael Lo
Add MCU command and its handling needed for testmode support on MT7925. This enables low-level chip testing features such as continuous TX/RX.. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Michael Lo <michael.lo@mediatek.com> Link: https://patch.msgid.link/20250505233618.1951021-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7925: ensure all MCU commands wait for responseMichael Lo
Modify MCU command sending functions to wait for a response, ensuring consistent behavior across all commands and improves reliability by confirming that each command is processed successfully. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Michael Lo <michael.lo@mediatek.com> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250414013954.1151774-3-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7925: refine the sniffer commnadMing Yen Hsieh
Remove a duplicate call to `mt76_mcu_send_msg` to fix redundant operations in the sniffer command handling. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250414013954.1151774-2-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7925: prevent multiple scan commandsMing Yen Hsieh
Add a check to ensure only one scan command is active at a time by testing the MT76_HW_SCANNING state. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250414013954.1151774-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()Henry Martin
devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init(). Fixes: 4f831d18d12d ("wifi: mt76: mt7915: enable WED RX support") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Link: https://patch.msgid.link/20250407061900.85317-1-bsdhenrymartin@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init()Henry Martin
devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init() Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Link: https://patch.msgid.link/20250407032349.83360-1-bsdhenrymartin@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: mt7925: add RNR scan support for 6GHzMing Yen Hsieh
Enhance the mt7925 to include RNR scan support. It adds the necessary RNR information to the scan command. Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250321013829.3598-2-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: add mt76_connac_mcu_build_rnr_scan_param routineMing Yen Hsieh
Introduce mt76_connac_mcu_build_rnr_scan_param routine for handling RNR scan. This is a preliminary patch to enable RNR scan in mt7921 and mt7925 driver. Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250321013829.3598-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22wifi: mt76: scan: Fix 'mlink' dereferenced before IS_ERR_OR_NULL checkFeng Jiang
Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202504011739.HvUKtUUe-lkp@intel.com/ Fixes: 3ba20af886d1 ("wifi: mt76: scan: set vif offchannel link for scanning/roc") Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn> Link: https://patch.msgid.link/20250402062415.25434-1-jiangfeng@kylinos.cn Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-22Merge tag 'linux-can-fixes-for-6.15-20250521' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2025-05-22 this is a pull request of 4 patches for net/main. The first 3 patches are by Axel Forsman and fix a ISR race condition in the kvaser_pciefd driver. The last patch is by Carlos Sanchez and fixes the reception of short error messages in the slcan driver. * tag 'linux-can-fixes-for-6.15-20250521' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: slcan: allow reception of short error messages can: kvaser_pciefd: Continue parsing DMA buf after dropped RX can: kvaser_pciefd: Fix echo_skb race can: kvaser_pciefd: Force IRQ edge in case of nested IRQ ==================== Link: https://patch.msgid.link/20250522082344.490913-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-22octeontx2-af: Fix APR entry mapping based on APR_LMT_CFGGeetha sowjanya
The current implementation maps the APR table using a fixed size, which can lead to incorrect mapping when the number of PFs and VFs varies. This patch corrects the mapping by calculating the APR table size dynamically based on the values configured in the APR_LMT_CFG register, ensuring accurate representation of APR entries in debugfs. Fixes: 0daa55d033b0 ("octeontx2-af: cn10k: debugfs for dumping LMTST map table"). Signed-off-by: Geetha sowjanya <gakula@marvell.com> Link: https://patch.msgid.link/20250521060834.19780-3-gakula@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-22octeontx2-af: Set LMT_ENA bit for APR table entriesSubbaraya Sundeep
This patch enables the LMT line for a PF/VF by setting the LMT_ENA bit in the APR_LMT_MAP_ENTRY_S structure. Additionally, it simplifies the logic for calculating the LMTST table index by consistently using the maximum number of hw supported VFs (i.e., 256). Fixes: 873a1e3d207a ("octeontx2-af: cn10k: Setting up lmtst map table"). Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Geetha sowjanya <gakula@marvell.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250521060834.19780-2-gakula@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-22octeontx2-pf: Avoid adding dcbnl_ops for LBK and SDP vfSuman Ghosh
Priority flow control is not supported for LBK and SDP vf. This patch adds support to not add dcbnl_ops for LBK and SDP vf. Fixes: 8e67558177f8 ("octeontx2-pf: PFC config support with DCBx") Signed-off-by: Suman Ghosh <sumang@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250519072658.2960851-1-sumang@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-21net/mlx5: HWS, handle modify header actions dependencyYevgeny Kliteynik
Having adjacent accelerated modify header actions (so-called pattern-argument actions) may result in inconsistent outcome. These inconsistencies can take the form of writes to the same field or a read coupled with a write to the same field. The solution is to detect such dependencies and insert nops between the offending actions. The existing implementation had a few issues, which pretty much required a complete rewrite of the code that handles these dependencies. In the new implementation we're doing the following: * Checking any two adjacent actions for conflicts (not just odd-even pairs). * Marking 'set' and 'add' action fields as destination, rather than source, for the purposes of checking for conflicts. * Checking all types of actions ('add', 'set', 'copy') for dependencies. * Managing offsets of the args in the buffer - copy the action args to the right place in the buffer. * Checking that after inserting nops we're still within the number of supported actions - return an error otherwise. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1747766802-958178-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net/mlx5: HWS, fix typo - 'nope' to 'nop'Yevgeny Kliteynik
Fix typo - rename 'nope_locations' to 'nop_locations', which describes the locations of 'nop' actions. To shorten the lines, this renaming also required some refactoring. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1747766802-958178-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net/mlx5: HWS, register reformat actions with fwVlad Dogaru
Hardware steering handles actions differently from firmware, but for termination rules that use encapsulation the firmware needs to be aware of the action. Fix this by registering reformat actions with the firmware the first time this is needed. To do this, add a third possible owner for an action, and also a lock to protect against registration of the same action from different threads. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1747766802-958178-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net/mlx5: SWS, fix reformat id error handlingVlad Dogaru
The firmware reformat id is a u32 and can't safely be returned as an int. Because the functions also need a way to signal error, prefer to return the id as an output parameter and keep the return code only for success/error. While we're at it, also extract some duplicate code to fetch the reformat id from a more generic struct pkt_reformat. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1747766802-958178-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21idpf: fix idpf_vport_splitq_napi_poll()Eric Dumazet
idpf_vport_splitq_napi_poll() can incorrectly return @budget after napi_complete_done() has been called. This violates NAPI rules, because after napi_complete_done(), current thread lost napi ownership. Move the test against POLL_MODE before the napi_complete_done(). Fixes: c2d548cad150 ("idpf: add TX splitq napi poll support") Reported-by: Peter Newman <peternewman@google.com> Closes: https://lore.kernel.org/netdev/20250520121908.1805732-1-edumazet@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Joshua Hay <joshua.a.hay@intel.com> Cc: Alan Brady <alan.brady@intel.com> Cc: Madhu Chittim <madhu.chittim@intel.com> Cc: Phani Burra <phani.r.burra@intel.com> Cc: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Link: https://patch.msgid.link/20250520124030.1983936-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net/enic: Allow at least 8 RQs to always be usedNelson Escobar
Enic started using netif_get_num_default_rss_queues() to set the number of RQs used in commit cc94d6c4d40c ("enic: Adjust used MSI-X wq/rq/cq/interrupt resources in a more robust way") This resulted in machines with less than 16 cpus using less than 8 RQs. Allow enic to use at least 8 RQs no matter how many cpus are in the machine to not impact existing enic workloads after a kernel upgrade. Reviewed-by: John Daley <johndale@cisco.com> Reviewed-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250521-enic_min_8rq-v1-1-691bd2353273@cisco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21hinic3: module initialization and tx/rx logicFan Gong
This is [1/3] part of hinic3 Ethernet driver initial submission. With this patch hinic3 is a valid kernel module but non-functional driver. The driver parts contained in this patch: Module initialization. PCI driver registration but with empty id_table. Auxiliary driver registration. Net device_ops registration but open/stop are empty stubs. tx/rx logic. All major data structures of the driver are fully introduced with the code that uses them but without their initialization code that requires management interface with the hw. Co-developed-by: Xin Guo <guoxin09@huawei.com> Signed-off-by: Xin Guo <guoxin09@huawei.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Co-developed-by: Gur Stavi <gur.stavi@huawei.com> Signed-off-by: Gur Stavi <gur.stavi@huawei.com> Link: https://patch.msgid.link/76a137ffdfe115c737c2c224f0c93b60ba53cc16.1747736586.git.gur.stavi@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21emulex/benet: correct command version selection in be_cmd_get_stats()Alok Tiwari
Logic here always sets hdr->version to 2 if it is not a BE3 or Lancer chip, even if it is BE2. Use 'else if' to prevent multiple assignments, setting version 0 for BE2, version 1 for BE3 and Lancer, and version 2 for others. Fixes potential incorrect version setting when BE2_chip and BE3_chip/lancer_chip checks could both be true. Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://patch.msgid.link/20250519141731.691136-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: phy: Add support for Aeonsemi AS21xxx PHYsChristian Marangi
Add support for Aeonsemi AS21xxx 10G C45 PHYs. These PHYs integrate an IPC to setup some configuration and require special handling to sync with the parity bit. The parity bit is a way the IPC use to follow correct order of command sent. Supported PHYs AS21011JB1, AS21011PB1, AS21010JB1, AS21010PB1, AS21511JB1, AS21511PB1, AS21510JB1, AS21510PB1, AS21210JB1, AS21210PB1 that all register with the PHY ID 0x7500 0x7510 before the firmware is loaded. They all support up to 5 LEDs with various HW mode supported. While implementing it was found some strange coincidence with using the same logic for implementing C22 in MMD regs in Broadcom PHYs. For reference here the AS21xxx PHY name logic: AS21x1xxB1 ^ ^^ | |J: Supports SyncE/PTP | |P: No SyncE/PTP support | 1: Supports 2nd Serdes | 2: Not 2nd Serdes support 0: 10G, 5G, 2.5G 5: 5G, 2.5G 2: 2.5G Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://patch.msgid.link/20250517201353.5137-6-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: phy: introduce genphy_match_phy_device()Christian Marangi
Introduce new API, genphy_match_phy_device(), to provide a way to check to match a PHY driver for a PHY device based on the info stored in the PHY device struct. The function generalize the logic used in phy_bus_match() to check the PHY ID whether if C45 or C22 ID should be used for matching. This is useful for custom .match_phy_device function that wants to use the generic logic under some condition. (example a PHY is already setup and provide the correct PHY ID) Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://patch.msgid.link/20250517201353.5137-5-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: phy: nxp-c45-tja11xx: simplify .match_phy_device OPChristian Marangi
Simplify .match_phy_device OP by using a generic function and using the new phy_id PHY driver info instead of hardcoding the matching PHY ID with new variant for macsec and no_macsec PHYs. Also make use of PHY_ID_MATCH_MODEL macro and drop PHY_ID_MASK define to introduce phy_id and phy_id_mask again in phy_driver struct. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://patch.msgid.link/20250517201353.5137-4-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: phy: bcm87xx: simplify .match_phy_device OPChristian Marangi
Simplify .match_phy_device OP by using a generic function and using the new phy_id PHY driver info instead of hardcoding the matching PHY ID. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://patch.msgid.link/20250517201353.5137-3-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: phy: pass PHY driver to .match_phy_device OPChristian Marangi
Pass PHY driver pointer to .match_phy_device OP in addition to phydev. Having access to the PHY driver struct might be useful to check the PHY ID of the driver is being matched for in case the PHY ID scanned in the phydev is not consistent. A scenario for this is a PHY that change PHY ID after a firmware is loaded, in such case, the PHY ID stored in PHY device struct is not valid anymore and PHY will manually scan the ID in the match_phy_device function. Having the PHY driver info is also useful for those PHY driver that implement multiple simple .match_phy_device OP to match specific MMD PHY ID. With this extra info if the parsing logic is the same, the matching function can be generalized by using the phy_id in the PHY driver instead of hardcoding. Rust wrapper callback is updated to align to the new match_phy_device arguments. Suggested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Benno Lossin <lossin@kernel.org> # for Rust Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20250517201353.5137-2-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: libwx: Fix log levelJiawen Wu
There is a log should be printed as info level, not error level. Fixes: 9bfd65980f8d ("net: libwx: Add sriov api for wangxun nics") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/67409DB57B87E2F0+20250519063357.21164-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: hibmcge: fix wrong ndo.open() after reset fail issue.Jijie Shao
If the driver reset fails, it may not work properly. Therefore, the ndo.open() operation should be rejected. In this patch, the driver calls netif_device_detach() before the reset and calls netif_device_attach() after the reset succeeds. If the reset fails, netif_device_attach() is not called. Therefore, netdev does not present and cannot be opened. If reset fails, only the PCI reset (via sysfs) can be used to attempt recovery. Fixes: 3f5a61f6d504 ("net: hibmcge: Add reset supported in this module") Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250517095828.1763126-3-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21net: hibmcge: fix incorrect statistics update issueJijie Shao
When the user dumps statistics, the hibmcge driver automatically updates all statistics. If the driver is performing the reset operation, the error data of 0xFFFFFFFF is updated. Therefore, if the driver is resetting, the hbg_update_stats_by_info() needs to return directly. Fixes: c0bf9bf31e79 ("net: hibmcge: Add support for dump statistics") Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250517095828.1763126-2-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21rtase: Use min() instead of min_t()Justin Lai
Use min() instead of min_t() to avoid the possibility of casting to the wrong type. Signed-off-by: Justin Lai <justinlai0215@realtek.com> Reviewed-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250520042031.9297-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-21wifi: ath12k: fix regdomain update failure when connection establishesBaochen Qiang
Commit 7ed3e88664e3 ("wifi: ath12k: update regulatory rules when connection established") introduced a call to ath12k_reg_handle_chan_list() upon connection to update the regulatory domain in cfg80211 based on the power type received from the AP. However, this update fails because ah->regd_updated was already set to true during the earlier regulatory update triggered when the interface was added. To resolve this, reset ah->regd_updated before calling ath12k_reg_handle_chan_list() to ensure the update proceeds correctly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 7ed3e88664e3 ("wifi: ath12k: update regulatory rules when connection established") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250521-ath12k-fix-ah-regd_updated-v1-3-9737de5bf98e@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-21wifi: ath12k: fix regdomain update failure when adding interfaceBaochen Qiang
Commit 4c546023d71a ("wifi: ath12k: update regulatory rules when interface added"), introduced a call to ath12k_reg_handle_chan_list() during interface addition to update the regulatory domain based on the interface type. While this works initially, subsequent updates (e.g., after an interface delete/re-add cycle) fail because ah->regd_updated is never reset. To address this, reset ah->regd_updated before calling ath12k_reg_handle_chan_list() to allow the update to proceed. However, this change exposes another issue: a timeout occurs when waiting for the 11D scan to complete, as seen in the log: ath12k_pci 0000:05:00.0: failed to receive 11d scan complete: timed out This happens because during interface down, ar->state_11d is set to ATH12K_11D_PREPARING, and during interface up, the host waits for ar->completed_11d_scan even though the scan hasn't started yet. Fix this by updating the wait condition to check for ATH12K_11D_RUNNING, which is the only state where a scan complete event is expected. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 4c546023d71a ("wifi: ath12k: update regulatory rules when interface added") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250521-ath12k-fix-ah-regd_updated-v1-2-9737de5bf98e@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>