summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-03-03wifi: rtw89: 8852a: update supported firmware format to 1Zong-Zhe Yang
More data will be included in Firmware file and loaded via FW elements. Unlike other chips, for RF radio, RTL8852A uses rtw89_phy_config_rf_reg instead of v1, so update loading handling of corresponding FW element. And then, increase RTL8852A FW format to 1 to prevent old driver from misusing the data in FW elements. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260213061552.29997-7-pkshih@realtek.com
2026-03-03wifi: rtw89: 8852a: move DIG tables to rtw8852a.cZong-Zhe Yang
Now, most of PHY parameter tables in driver can be loaded via FW elements. Plan to generate the corresponding FW elements for 8852A PHY tables. Then, after FW elements work for a enough time, rtw8852a_table.c can be cleaned up. However, DIG (dynamic initial gain) tables are legacy for 8852A only, so FW element doesn't support. Their sizes are not very big, so move them to rtw8852a.c and keep rtw8852a_table.c for PHY tables which are supported by FW elements. No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260213061552.29997-6-pkshih@realtek.com
2026-03-03wifi: rtw89: 8852b: update supported firmware format to 2Ping-Ke Shih
After firmware version 0.29.29.15, more data are included in firmware file. Increase format to 2 to prevent old driver failed to load the new firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260213061552.29997-5-pkshih@realtek.com
2026-03-02net: dsa: realtek: rtl8365mb: fix rtl8365mb_phy_ocp_write return valueMieczyslaw Nalewaj
Function rtl8365mb_phy_ocp_write() always returns 0, even when an error occurs during register access. This patch fixes the return value to propagate the actual error code from regmap operations. Link: https://lore.kernel.org/netdev/a2dfde3c-d46f-434b-9d16-1e251e449068@yahoo.com/ Fixes: 2796728460b8 ("net: dsa: realtek: rtl8365mb: serialize indirect PHY register access") Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260301-realtek_namiltd_fix1-v1-1-43a6bb707f9c@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-03wifi: rtw89: add general way to generate module firmware stringZong-Zhe Yang
Module firmware string depends on max format of the firmware. When max format is 0, the module firmware string will be like XYZ.bin. However, when max format N > 0, the module firmware string will become XYZ-N.bin. Originally, when one chip updated its max firmware format from 0 to 1, the module firmware string also needed to be changed. However, did not need to do for other cases, e.g. from 1 to 2. It's a bit inconvenient to always remember that from 0 to 1 is a special case. So, add a general macro to generate the corresponding module firmware string based on max firmware format. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260213061552.29997-4-pkshih@realtek.com
2026-03-03wifi: rtw89: fw: recognize firmware type B by AIDPing-Ke Shih
Select a firmware suit including normal and WoWLAN firmware by chip AID from multiple firmware, because coming RTL8922D has variant hardware with different chip AID. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260213061552.29997-3-pkshih@realtek.com
2026-03-03wifi: rtw89: fw: add fw_def struct to put firmware name and format versionPing-Ke Shih
The RTL8922DE has a RTL8922DE-VS variant which uses different firmware name and format version, and the rule to select firmware type will be needed to extend. Prepare for coming patches. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260213061552.29997-2-pkshih@realtek.com
2026-03-03wifi: rtw88: coex: Solve LE-HID lag & update coex version to 26020420Ching-Te Ku
When Wi-Fi enters power save, the register value can not be read correctly. If mechanism take the wrong information to make decision, it will run with wrong parameters. It leads Bluetooth low-energy HID lag. Add logic to isolate the wrong register state. BTCOEX Version: 26020420-2020 Desired_BT_Coex_Ver: 0x20 Desired_WL_FW_Ver: 9.9.X Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260213053445.19384-1-pkshih@realtek.com
2026-03-02net: remove addr_len argument of recvmsg() handlersEric Dumazet
Use msg->msg_namelen as a place holder instead of a temporary variable, notably in inet[6]_recvmsg(). This removes stack canaries and allows tail-calls. $ scripts/bloat-o-meter -t vmlinux.old vmlinux add/remove: 0/0 grow/shrink: 2/19 up/down: 26/-532 (-506) Function old new delta rawv6_recvmsg 744 767 +23 vsock_dgram_recvmsg 55 58 +3 vsock_connectible_recvmsg 50 47 -3 unix_stream_recvmsg 161 158 -3 unix_seqpacket_recvmsg 62 59 -3 unix_dgram_recvmsg 42 39 -3 tcp_recvmsg 546 543 -3 mptcp_recvmsg 1568 1565 -3 ping_recvmsg 806 800 -6 tcp_bpf_recvmsg_parser 983 974 -9 ip_recv_error 588 576 -12 ipv6_recv_rxpmtu 442 428 -14 udp_recvmsg 1243 1224 -19 ipv6_recv_error 1046 1024 -22 udpv6_recvmsg 1487 1461 -26 raw_recvmsg 465 437 -28 udp_bpf_recvmsg 1027 984 -43 sock_common_recvmsg 103 27 -76 inet_recvmsg 257 175 -82 inet6_recvmsg 257 175 -82 tcp_bpf_recvmsg 663 568 -95 Total: Before=25143834, After=25143328, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260227151120.1346573-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-03wifi: rtw89: Turbo mode for RTL8851BU/RTL8852BUBitterblue Smith
RTL8851BU and RTL8852BU currently have much lower TX speed than expected, ~100 and ~300 Mbps, respectively. This is because part of the chip's memory is allocated for some unknown firmware features instead of the TX buffers. The vendor drivers have a module parameter called "rtw_quota_turbo_en", which can be used to choose between full TX speed or the unknown firmware features. It is on by default. Change the relevant chip parameters to implement the turbo mode. Do it only for USB because PCI is already fast even without the turbo mode. It's unclear if SDIO will need it or not. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/88cce107-ff52-496f-bb77-b930e4182b67@gmail.com
2026-03-02wifi: ath12k: Remove the unused argument from the Rx data pathKarthikeyan Periyasamy
Currently, the Rx path uses new infrastructure to extract the required HAL parameters. Consequently, the HAL Rx descriptor argument is no longer needed in the following helper functions. Remove the unused argument from the following helper functions. ath12k_dp_rx_h_undecap() ath12k_dp_rx_check_nwifi_hdr_len_valid() ath12k_wifi7_dp_rx_h_mpdu() Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260227042128.3494167-1-karthikeyan.periyasamy@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-03-02wifi: ath12k: Enable monitor mode support on IPQ5332Aaradhana Sahu
Currently, rxdma1_enable and supports_monitor are set to false in IPQ5332 hardware parameters, which skips monitor ring configuration and removes NL80211_IFTYPE_MONITOR from the supported interface modes. Set rxdma1_enable and supports_monitor to true so that monitor rings are configured and monitor mode is enabled on IPQ5332. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.7-00587-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260227033332.687805-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-03-02wifi: ath12k: Set up MLO after SSRRamya Gnanasekar
During recovery of an MLO setup from a core reset, ATH12K_GROUP_FLAG_REGISTERED is set because ath12k_mac_unregister is not called during core reset. So, when an MLO setup is recovering from a core reset, ath12k_core_mlo_setup() is skipped. Hence, the firmware will not have information about partner links. This makes MLO association fail after recovery. To resolve this, call ath12k_core_mlo_setup() during recovery, to set up MLO. Also, if MLO setup fails during recovery, call ath12k_mac_unregister() and ath12k_mac_destroy() to unregister mac and then tear down the mac structures. Also, initiate MLO teardown in the hardware group stop sequence to align with the hardware group start sequence. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1 Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260227041127.3265879-1-roopni.devanathan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-03-02wifi: ath11k: Silence remoteproc probe deferral printsBjorn Andersson
Upon failing to resolve the remoteproc phandle one ath11k_dbg() and one ath11k_err() is used to tell the user about the (presumably) temporary failure. Reduce the log spam by removing the duplicate print and switching to dev_err_probe(), in line with how ath12k handles this error. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260212-ath11k-silence-probe-deferr-v1-1-b8a49bb3c332@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-03-02net/mlx5: Drop MR cache related codeMichael Guralnik
Following mlx5_ib move to using FRMR pools, drop all unused code of MR cache. Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Reviewed-by: Yishai Hadas <yishaih@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260226-frmr_pools-v4-7-95360b54f15e@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-03-02wifi: rsi: Don't default to -EOPNOTSUPP in rsi_mac80211_configSebastian Krzyszkowiak
This triggers a WARN_ON in ieee80211_hw_conf_init and isn't the expected behavior from the driver - other drivers default to 0 too. Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Link: https://patch.msgid.link/20260221-rsi-config-ret-v1-1-9a8f805e2f31@puri.sm Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: cfg80211: support key installation on non-netdev wdevsAvraham Stern
Currently key installation is only supported for netdev. For NAN, support most key operations (except setting default data key) on wdevs instead of netdevs, and adjust all the APIs and tracing to match. Since nothing currently sets NL80211_EXT_FEATURE_SECURE_NAN, this doesn't change anything (P2P Device already isn't allowed.) Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260107150057.69a0cfad95fa.I00efdf3b2c11efab82ef6ece9f393382bcf33ba8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02can: gs_usb: gs_can_open(): always configure bitrates before starting deviceMarc Kleine-Budde
So far the driver populated the struct can_priv::do_set_bittiming() and struct can_priv::fd::do_set_data_bittiming() callbacks. Before bringing up the interface, user space has to configure the bitrates. With these callbacks the configuration is directly forwarded into the CAN hardware. Then the interface can be brought up. An ifdown-ifup cycle (without changing the bit rates) doesn't re-configure the bitrates in the CAN hardware. This leads to a problem with the CANable-2.5 [1] firmware, which resets the configured bit rates during ifdown. To fix the problem remove both bit timing callbacks and always configure the bitrates in the struct net_device_ops::ndo_open() callback. [1] https://github.com/Elmue/CANable-2.5-firmware-Slcan-and-Candlelight Cc: stable@vger.kernel.org Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20260219-gs_usb-always-configure-bitrates-v2-1-671f8ba5b0a5@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: usb: f81604: correctly anchor the urb in the read bulk callbackGreg Kroah-Hartman
When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also. Cc: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Vincent Mailhol <mailhol@kernel.org> Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026022334-starlight-scaling-2cea@gregkh Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: usb: f81604: handle bulk write errors properlyGreg Kroah-Hartman
If a write urb fails then more needs to be done other than just logging the message, otherwise the transmission could be stalled. Properly increment the error counters and wake up the queues so that data will continue to flow. Cc: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Vincent Mailhol <mailhol@kernel.org> Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026022334-slackness-dynamic-9195@gregkh Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: usb: f81604: handle short interrupt urb messages properlyGreg Kroah-Hartman
If an interrupt urb is received that is not the correct length, properly detect it and don't attempt to treat the data as valid. Cc: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Vincent Mailhol <mailhol@kernel.org> Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026022331-opal-evaluator-a928@gregkh Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: usb: etas_es58x: correctly anchor the urb in the read bulk callbackGreg Kroah-Hartman
When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also. Cc: Vincent Mailhol <mailhol@kernel.org> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Tested-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/2026022320-poser-stiffly-9d84@gregkh Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: ucan: Fix infinite loop from zero-length messagesGreg Kroah-Hartman
If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 ("can: kvaser_usb: leaf: Fix potential infinite loop in command parsers"), so there must be some broken devices out there like this somewhere. Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Vincent Mailhol <mailhol@kernel.org> Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026022319-huff-absurd-6a18@gregkh Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a messageGreg Kroah-Hartman
When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message. Cc: Vincent Mailhol <mailhol@kernel.org> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026022316-answering-strainer-a5db@gregkh Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: esd_usb: add endpoint type validationZiyi Guo
esd_usb_probe() constructs bulk pipes for two endpoints without verifying their transfer types: - usb_rcvbulkpipe(dev->udev, 1) for RX (version reply, async RX data) - usb_sndbulkpipe(dev->udev, 2) for TX (version query, CAN frames) A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes, triggering the WARNING in usb_submit_urb(). Use usb_find_common_endpoints() to discover and validate the first bulk IN and bulk OUT endpoints at probe time, before any allocation. Found pipes are saved to struct esd_usb and code uses them directly instead of making pipes in place. Similar to - commit 136bed0bfd3b ("can: mcba_usb: properly check endpoint type") which established the usb_find_common_endpoints() + stored pipes pattern for CAN USB drivers. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Suggested-by: Vincent Mailhol <mailhol@kernel.org> Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20260213203927.599163-1-n7l8m4@u.northwestern.edu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02wifi: cfg80211: make cluster id an arrayMiri Korenblit
cfg80211_nan_conf::cluster_id is currently a pointer, but there is no real reason to not have it an array. It makes things easier as there is no need to check the pointer validity each time. If a cluster ID wasn't provided by user space it will be randomized. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260302091108.2b12e4ccf5bb.Ib16bf5cca55463d4c89e18099cf1dfe4de95d405@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02can: mcp251x: fix deadlock in error path of mcp251x_openAlban Bedel
The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock. Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de> Link: https://patch.msgid.link/20260209144706.2261954-1-alban.bedel@lht.dlh.de Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02can: dummy_can: dummy_can_init(): fix packet statisticsOliver Hartkopp
The former implementation was only counting the tx_packets value but not the tx_bytes as the skb was dropped on driver layer. Enable CAN echo support (IFF_ECHO) in dummy_can_init(), which activates the code for setting and retrieving the echo SKB and counts the tx_bytes correctly. Fixes: 816cf430e84b ("can: add dummy_can driver") Cc: Vincent Mailhol <mailhol@kernel.org> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20260126104540.21024-1-socketcan@hartkopp.net [mkl: make commit message imperative] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-03-02wifi: mac80211_hwsim: Advertise support for (Re)Association frame encryptionKavita Kavita
Advertise support for (Re)Association frame encryption in mac80211_hwsim for testing scenarios. Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260226185553.1516290-2-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211: Fix AAD/Nonce computation for management frames with MLOSai Pratyusha Magam
Per IEEE Std 802.11be-2024, 12.5.2.3.3, if the MPDU is an individually addressed Data frame between an AP MLD and a non-AP MLD associated with the AP MLD, then A1/A2/A3 will be MLD MAC addresses. Otherwise, Al/A2/A3 will be over-the-air link MAC addresses. Currently, during AAD and Nonce computation for software based encryption/decryption cases, mac80211 directly uses the addresses it receives in the skb frame header. However, after the first authentication, management frame addresses for non-AP MLD stations are translated to MLD addresses from over the air link addresses in software. This means that the skb header could contain translated MLD addresses, which when used as is, can lead to incorrect AAD/Nonce computation. In the following manner, ensure that the right set of addresses are used: In the receive path, stash the pre-translated link addresses in ieee80211_rx_data and use them for the AAD/Nonce computations when required. In the transmit path, offload the encryption for a CCMP/GCMP key to the hwsim driver that can then ensure that encryption and hence the AAD/Nonce computations are performed on the frame containing the right set of addresses, i.e, MLD addresses if unicast data frame and link addresses otherwise. To do so, register the set key handler in hwsim driver so mac80211 is aware that it is the driver that would take care of encrypting the frame. Offload encryption for a CCMP/GCMP key, while keeping the encryption for WEP/TKIP and MMIE generation for a AES_CMAC or a AES_GMAC key still at the SW crypto in mac layer Co-developed-by: Rohan Dutta <quic_drohan@quicinc.com> Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com> Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com> Link: https://patch.msgid.link/20260226042959.3766157-1-sai.magam@oss.qualcomm.com [only store and apply link_addrs for unicast non-data rather storing always and applying for !unicast_data] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: rt2x00: use generic nvmem_cell_getRosen Penev
The library doesn't necessarily depend on OF. This codepath is used by both soc (OF only) and pci (no such requirement). After this, the only of specific function is of_get_mac_address, which is needed for nvmem. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260223214004.19960-1-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211: fetch unsolicited probe response template by link IDSriram R
Currently, the unsolicited probe response template is always fetched from the default link of a virtual interface in both Multi-Link Operation (MLO) and non-MLO cases. However, in the MLO case there is a need to fetch the unsolicited probe response template from a specific link instead of the default link. Hence, add support for fetching the unsolicited probe response template based on the link ID from the corresponding link data. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-fils-prob-by-link-v1-2-a2746a853f75@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211: fetch FILS discovery template by link IDSriram R
Currently, the FILS discovery template is always fetched from the default link of a virtual interface in both Multi-Link Operation (MLO) and non-MLO cases. However, in the MLO case there is a need to fetch the FILS discovery template from a specific link instead of the default link. Hence, add support for fetching the FILS discovery template based on the link ID from the corresponding link data. Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-fils-prob-by-link-v1-1-a2746a853f75@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: nl80211/cfg80211: support stations of non-netdev interfacesMiri Korenblit
Currently, a station can only be added to a netdev interface, mainly because there was no need for a station of a non-netdev interface. But for NAN, we will have stations that belong to the NL80211_IFTYPE_NAN interface. Prepare for adding/changing/deleting a station that belongs to a non-netdev interface. This doesn't actually allow such stations - this will be done in a different patch. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260219114327.65c9cc96f814.Ic02066b88bb8ad6b21e15cbea8d720280008c83b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: iwlegacy: Avoid multiple -Wflex-array-member-not-at-end warningsGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Move the conflicting declarations (which in a couple of cases happen to be in a union, so the entire unions are moved) to the end of the corresponding structures, struct il_frame, and struct il3945_frame. Notice that `struct il_tx_beacon_cmd`, `struct il4965_tx_resp`, and `struct il3945_tx_beacon_cmd` are flexible structures, this is structures that contain a flexible-array member. The case for struct il4965_beacon_notif is different. Since this structure is defined by hardware, we create the new `struct il4965_tx_resp_hdr` type. We then use this newly created type to replace the object type causing trouble in struct il4965_beacon_notif, namely `struct il4965_tx_resp`. Also, once -fms-extensions is enabled, we can use transparent struct members in struct il4965_tx_resp. Notice that the newly created type does not contain the flex-array member `agg_status`, which is the object causing the -Wfamnae warnings. This object is currently in a union along with `__le32 status`, so anything using struct il4965_beacon_notif needs to have its own view of `status`. To preserve the memory layout, we therefore add member `__le32 beacon_tx_status` to struct il4965_beacon_notif. After these changes, the size of struct il4965_beacon_notif along with its member's offsets remain the same, hence the memory layout doesn't change: Before changes: struct il4965_beacon_notif { struct il4965_tx_resp beacon_notify_hdr; /* 0 24 */ __le32 low_tsf; /* 24 4 */ __le32 high_tsf; /* 28 4 */ __le32 ibss_mgr_status; /* 32 4 */ /* size: 36, cachelines: 1, members: 4 */ /* last cacheline: 36 bytes */ }; After changes: struct il4965_beacon_notif { struct il4965_tx_resp_hdr beacon_notify_hdr; /* 0 20 */ __le32 beacon_tx_status; /* 20 4 */ __le32 low_tsf; /* 24 4 */ __le32 high_tsf; /* 28 4 */ __le32 ibss_mgr_status; /* 32 4 */ /* size: 36, cachelines: 1, members: 5 */ /* last cacheline: 36 bytes */ }; Lastly, adjust the rest of the code, accordingly. With these changes fix the following warnings: 11 drivers/net/wireless/intel/iwlegacy/common.h:526:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] 11 drivers/net/wireless/intel/iwlegacy/commands.h:2667:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] 4 drivers/net/wireless/intel/iwlegacy/3945.h:131:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/aZLienEatf9KC6Rx@kspp Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()Daniel Hodges
The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. Fixes: 4636187da60b ("mwifiex: add wakeup timer based recovery mechanism") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges <git@danielhodges.dev> Link: https://patch.msgid.link/20260206194401.2346-1-git@danielhodges.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mac80211_hwsim: background CAC supportJanusz Dziedzic
Report background CAC support and add allow to cancel background CAC and simulate radar. echo cancel > /sys/kernel/debug/ieee80211/phy2/hwsim/dfs_background_cac echo radar > /sys/kernel/debug/ieee80211/phy2/hwsim/dfs_background_cac Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com> Link: https://patch.msgid.link/20260206171830.553879-5-janusz.dziedzic@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-02wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt()Zilin Guan
In mwifiex_11n_aggregate_pkt(), skb_aggr is allocated via mwifiex_alloc_dma_align_buf(). If mwifiex_is_ralist_valid() returns false, the function currently returns -1 immediately without freeing the previously allocated skb_aggr, causing a memory leak. Since skb_aggr has not yet been queued via skb_queue_tail(), no other references to this memory exist. Therefore, it has to be freed locally before returning the error. Fix this by calling mwifiex_write_data_complete() to free skb_aggr before returning the error status. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Jeff Chen <jeff.chen_1@nxp.com> Link: https://patch.msgid.link/20260119092625.1349934-1-zilin@seu.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-01Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf before 7.0-rc2Alexei Starovoitov
Cross-merge BPF and other fixes after downstream PR. No conflicts. Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-02-28amd-xgbe: fix MAC_TCR_SS register width for 2.5G and 10M speedsRaju Rangoju
Extend the MAC_TCR_SS (Speed Select) register field width from 2 bits to 3 bits to properly support all speed settings. The MAC_TCR register's SS field encoding requires 3 bits to represent all supported speeds: - 0x00: 10Gbps (XGMII) - 0x02: 2.5Gbps (GMII) / 100Mbps - 0x03: 1Gbps / 10Mbps - 0x06: 2.5Gbps (XGMII) - P100a only With only 2 bits, values 0x04-0x07 cannot be represented, which breaks 2.5G XGMII mode on newer platforms and causes incorrect speed select values to be programmed. Fixes: 07445f3c7ca1 ("amd-xgbe: Add support for 10 Mbps speed") Co-developed-by: Guruvendra Punugupati <Guruvendra.Punugupati@amd.com> Signed-off-by: Guruvendra Punugupati <Guruvendra.Punugupati@amd.com> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Link: https://patch.msgid.link/20260226170753.250312-1-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28net: ti: icssg-prueth: Fix ping failure after offload mode setup when link ↵MD Danish Anwar
speed is not 1G When both eth interfaces with links up are added to a bridge or hsr interface, ping fails if the link speed is not 1Gbps (e.g., 100Mbps). The issue is seen because when switching to offload (bridge/hsr) mode, prueth_emac_restart() restarts the firmware and clears DRAM with memset_io(), setting all memory to 0. This includes PORT_LINK_SPEED_OFFSET which firmware reads for link speed. The value 0 corresponds to FW_LINK_SPEED_1G (0x00), so for 1Gbps links the default value is correct and ping works. For 100Mbps links, the firmware needs FW_LINK_SPEED_100M (0x01) but gets 0 instead, causing ping to fail. The function emac_adjust_link() is called to reconfigure, but it detects no state change (emac->link is still 1, speed/duplex match PHY) so new_state remains false and icssg_config_set_speed() is never called to correct the firmware speed value. The fix resets emac->link to 0 before calling emac_adjust_link() in prueth_emac_common_start(). This forces new_state=true, ensuring icssg_config_set_speed() is called to write the correct speed value to firmware memory. Fixes: 06feac15406f ("net: ti: icssg-prueth: Fix emac link speed handling") Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Link: https://patch.msgid.link/20260226102356.2141871-1-danishanwar@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: Use common structuresRatheesh Kannoth
CN20K and legacy silicon differ in the size of key words used in NPC MCAM. However, SoC-specific structures are not required for low-level functions. Remove the SoC-specific structures and rename the macros to improve readability. Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-14-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: add debugfs supportRatheesh Kannoth
CN20K silicon divides the NPC MCAM into banks and subbanks, with each subbank configurable for x2 or x4 key widths. This patch adds debugfs entries to expose subbank usage details and their configured key type. A debugfs entry is also added to display the default MCAM indexes allocated for each pcifunc. Additionally, debugfs support is introduced to show the mapping between virtual indexes and real MCAM indexes, and vice versa. Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-13-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-pf: cn20k: Add TC rules supportSubbaraya Sundeep
Unlike previous silicons, MCAM entries required for TC rules in CN20K are allocated dynamically. The key size can also be dynamic, i.e., X2 or X4. Based on the size of the TC rule match criteria, the AF driver allocates an X2 or X4 rule. This patch implements the required changes for CN20K TC by requesting an MCAM entry from the AF driver on the fly when the user installs a rule. Based on the TC rule priority added or deleted by the user, the PF driver shifts MCAM entries accordingly. If there is a mix of X2 and X4 rules and the user tries to install a rule in the middle of existing rules, the PF driver detects this and rejects the rule since X2 and X4 rules cannot be shifted in hardware. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-12-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: Allocate MCAM entry for flow installationRatheesh Kannoth
In CN20K, the PF/VF driver is unaware of the NPC MCAM entry type (x2/x4) required for a particular TC rule when the user installs rules through the TC command. This forces the PF/VF driver to first query the AF driver for the rule size, then allocate an entry, and finally install the flow. This sequence requires three mailbox request/response exchanges from the PF. To speed up the installation, the `install_flow` mailbox request message is extended with additional fields that allow the AF driver to determine the required NPC MCAM entry type, allocate the MCAM entry, and complete the flow installation in a single step. Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-11-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: virtual index supportRatheesh Kannoth
This patch adds support for virtual MCAM index allocation and improves CN20K MCAM defragmentation handling. A new field is introduced in the non-ref, non-contiguous MCAM allocation mailbox request to indicate that virtual indexes should be returned instead of physical ones. Virtual indexes allow the hardware to move mapped MCAM entries internally, enabling defragmentation and preventing scattered allocations across subbanks. The patch also enhances defragmentation by treating non-ref, non-contiguous allocations as ideal candidates for packing sparsely used regions, which can free up subbanks for potential x2 or x4 configuration. All such allocations are tracked and always returned as virtual indexes so they remain stable even when entries are moved during defrag. During defragmentation, MCAM entries may shift between subbanks, but their virtual indexes remain unchanged. Additionally, this update fixes an issue where entry statistics were not being restored correctly after defragmentation. Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-10-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: Add new mailboxes for CN20K siliconSuman Ghosh
To enable enhanced MCAM capabilities for CN20K, the struct mcam_entry has been extended to support expanded keyword requirements. Specifically, the kw and kw_mask arrays have been increased from a size of 7 to 8 to accommodate the additional keyword field introduced for CN20K. To ensure seamless integration while preserving compatibility with existing platforms, dedicated CN20K-specific mailboxes have been introduced that leverage the updated struct mcam_entry. This approach allows CN20K to utilize the extended structure without impacting current implementations. This patch identifies the relevant mailboxes and introduces the following CN20K-specific additions: New mailboxes added: 1. `NPC_CN20K_MCAM_WRITE_ENTRY` 2. `NPC_CN20K_MCAM_ALLOC_AND_WRITE_ENTRY` 3. `NPC_CN20K_MCAM_READ_ENTRY` 4. `NPC_CN20K_MCAM_READ_BASE_RULE` Signed-off-by: Suman Ghosh <sumang@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-9-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: Prepare for new SoCRatheesh Kannoth
Current code pass mcam_entry structure to all low level functions. This is not proper: 1) We need to modify all functions to support a new SoC 2) It does not look good to pass soc specific structure to all common functions. This patch adds a mcam meta data structure, which is populated and passed to low level functions. Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-8-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: Use common APIsSuman Ghosh
In cn20k silicon, the register definitions and the algorithms used to read, write, copy, and enable MCAM entries have changed. This patch updates the common APIs to support both cn20k and previous silicon variants. Additionally, cn20k introduces a new algorithm for MCAM index management. The common APIs are updated to invoke the cn20k-specific index management routines for allocating, freeing, and retrieving default MCAM entries. Signed-off-by: Suman Ghosh <sumang@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-7-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: Allocate default MCAM indexesRatheesh Kannoth
Reserving MCAM entries in the AF driver for installing default MCAM entries is not an efficient allocation method, as it results in significant wastage of entries. This patch allocates MCAM indexes for promiscuous, multicast, broadcast, and unicast traffic in descending order of indexes (from lower to higher priority) when the NIX LF is attached to the PF/VF. Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-6-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-20 08:14:31 +0000