summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-01-27wifi: cfg80211: treat deprecated INDOOR_SP_AP_OLD control value as LPI modePagadala Yesu Anjaneyulu1-1/+1
Although value 4 (INDOOR_SP_AP_OLD) is deprecated in IEEE standards, existing APs may still use this control value. Since this value is based on the old specification, we cannot trust such APs implement proper power controls. Therefore, move IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP_OLD case from SP_AP to LPI_AP power type handling to prevent potential power limit violations. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111163601.6b5a36d3601e.I1704ee575fd25edb0d56f48a0a3169b44ef72ad0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: rtw88: sdio: Migrate to use sdio specific shutdown functionUwe Kleine-König7-8/+7
This saves a cast in the driver. The motivation is stop using the callback .shutdown in rsi_driver.drv to make it possible to drop that. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5a328658c20613068bbbfabd3d0e721b69b3d474.1768232321.git.u.kleine-koenig@baylibre.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: rsi: sdio: Migrate to use sdio specific shutdown functionUwe Kleine-König1-3/+2
This saves a cast in the driver. The motivation is stop using the callback .shutdown in rsi_driver.drv to make it possible to drop that. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/2909323889b8ad4732ef6a8e05b5c40487a6c4bb.1768232321.git.u.kleine-koenig@baylibre.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27sdio: Provide a bustype shutdown functionUwe Kleine-König2-0/+26
To prepare sdio drivers to migrate away from struct device_driver::shutdown (and then eventually remove that callback) create a serdev driver shutdown callback and migration code to keep the existing behaviour. Note this introduces a warning for each driver that isn't converted yet to that callback at register time. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/397f45c2818f6632151f92b70e547262f373c3b6.1768232321.git.u.kleine-koenig@baylibre.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: support operating as RSTA in PMSR FTM requestAvraham Stern4-1/+37
Add an option to operate as the RSTA in an FTM measurement request. When requested, the device will dwell on the requested channel until the peer starts the FTM negotiation. This option is only valid for trigger-based/non trigger-based measurement with LMR feedback which will allow the RSTA to receive the results of the measurement. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.1f95fc0afab4.Iae2d32783b8e7c4a29089fec0f4c6bce94d303cc@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: add negotiated burst period to FTM resultAvraham Stern3-0/+6
The FTM result includes some of the periodic measurement negotiated parameters (like the burst duration and number of bursts), but it doesn't include the burst period. Add it to the FTM result notification. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.e0778f86edef.I3c98c1933eb639963bc3ffdef81a8788b59f2188@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: clarify periodic FTM parameters for non-EDCA based ↵Avraham Stern3-8/+14
ranging Periodic FTM request attributes are defined based on the periodic parameters used in EDCA-based ranging negotiation. However, non-EDCA based ranging (trigger-based/non-trigger-based) does not include periodic parameters in the negotiation protocol, even though upper layers may still request periodic measurements. Clarify the semantics of periodic ranging attributes when used with non-EDCA based ranging. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.b89cb3f68e1a.I7a9d8c6d1c66c77f1b43120a841101c96c3f19ad@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-27wifi: nl80211/cfg80211: add new FTM capabilitiesAvraham Stern3-1/+71
Add new capabilities to the PMSR FTM capabilities list. The new capabilities include 6 GHz support, supported number of spatial streams and supported number of LTF repetitions. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111190221.bf43785c18f6.Ic98cf9790ddee84bf88e5720b93c46c23af3c96c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: mac80211: mark iface work SKBs as consumedJohannes Berg1-3/+3
Using kfree_skb() here is misleading when looking at traces, since these frames have been handled. Use consume_skb() instead. Link: https://patch.msgid.link/20260116092115.1db534bdc12c.Ic0adae06684a6871144398d15cf7700c57620baa@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: mac80211: remove RX_DROPJohannes Berg2-50/+94
Since it's hard to figure out what RX_DROP means when looking at traces that drop packets in mac80211, add more specific drop reasons and remove RX_DROP entirely. Link: https://patch.msgid.link/20260116092025.79d995e87026.I7cde413988f7a382c551cd1c1e2b05a52ec71755@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: nl80211: ignore cluster id after NAN startedMiri Korenblit2-6/+9
After NAN was started, cluster id updates from the user space should not happen, since the device already started a cluster with the previousely provided id. Since NL80211_CMD_CHANGE_NAN_CONFIG requires to set the full NAN configuration, we can't require that NL80211_NAN_CONF_CLUSTER_ID won't be included in this command, and keeping the last confgiured value just to be able to compare it against the new one seems a bit overkill. Therefore, just ignore cluster id in this command and clarify the documentation. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260107142229.fb55e5853269.I10d18c8f69d98b28916596d6da4207c15ea4abb5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: cfg80211: cleanup cluster_id when stopping NANMiri Korenblit1-0/+2
When NAN is stopped, cluster_id should be set to 0 to indicate that we are not part of any cluster. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260107142229.9ccb700797ec.I890ac852be6ca0093995655d987ca5c28a26ce3d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: cfg80211: limit NAN func management APIs to offloaded DEMiri Korenblit1-0/+6
A driver that declared that it has userspace DE should not call NAN func related APIs such as cfg80211_nan_match and cfg80211_nan_func_terminated Check and warn in such a case, as this indicates a driver bug. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260107141549.86fa96c75211.I8fbb0506377170dd7b41234f20bcba057951dd1e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: cfg80211: stop NAN and P2P in cfg80211_leaveMiri Korenblit1-1/+3
Seems that there is an assumption that this function should be called only for netdev interfaces, but it can also be called in suspend, or from nl80211_netlink_notify (indirectly). Note that the documentation of NL80211_ATTR_SOCKET_OWNER explicitly says that NAN interfaces would be destroyed as well in the nl80211_netlink_notify case. Fix this by also stopping P2P and NAN. Fixes: cb3b7d87652a ("cfg80211: add start / stop NAN commands") Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260107140430.dab142cbef0b.I290cc47836d56dd7e35012ce06bec36c6da688cd@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: cfg80211: allow only one NAN interface, also in multi radioMiri Korenblit1-6/+2
According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can have one NAN management interface. This applies also to multi radio devices. The current code allows a driver to support more than one NAN interface, if those are not in the same radio. Fix it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec1481ff197e47f6ce0793d7118@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19wifi: wlcore: Add support for IGTK keyPeter Åstrand2-0/+10
This change re-applies commit 2b7aadd3b9e1 ("wlcore: Adding suppoprt for IGTK key in wlcore driver") (sic), but only enables WLAN_CIPHER_SUITE_AES_CMAC with modern firmware. This patch is required to support WPA3 connections. Signed-off-by: Peter Åstrand <astrand@lysator.liu.se> Link: https://patch.msgid.link/0d3df7ab-6c41-c3cc-83cc-5ba55fe4e4bd@lysator.liu.se Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-19Merge tag 'rtw-next-2026-01-15' of https://github.com/pkshih/rtwJohannes Berg46-397/+3681
Ping-Ke Shih says: ================== rtw-next patches for -next release. Main changes are to prepare to support RTL8922DE, including refactor/add register settings in common flow, and add newly firmware command/event handlers. Others are some random fixes and improvements across all drivers. ================== Link: https://patch.msgid.link/006be16d-61ba-4af8-b76a-bc94100c3555@RTKEXHMBS03.realtek.com.tw Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-15wifi: rtw89: pci: consider RTL8922D in PCI common flowPing-Ke Shih3-19/+151
Clear TX/RX ring index, PCI operating mode, SER setting, PCI LTR and preinit settings. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-9-pkshih@realtek.com
2026-01-15wifi: rtw89: mac: consider RTL8922D in MAC common flowPing-Ke Shih2-21/+376
The MAC settings are different from RTL8922A to RTL8922D, including scheduler, DLE, DCPU, MLO, NAV, TMAC, TX/RX protocol, RMAC, IMR, host RPT, AMSDU. Update them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-8-pkshih@realtek.com
2026-01-15wifi: rtw89: mac: correct page number for CSI responsePing-Ke Shih1-1/+1
For beamforming procedure, hardware reserve memory page for CSI response. The unit of register is (value - 1), so add one accordingly as expected. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-7-pkshih@realtek.com
2026-01-15wifi: rtw89: align CUSTID defined by firmwarePing-Ke Shih1-7/+9
Firmware does customized features by CUSTID, so align the ID definition to have expected features enabled. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-6-pkshih@realtek.com
2026-01-15wifi: rtw89: disable EHT protocol by chip capabilitiesPing-Ke Shih4-1/+11
For certain chip models, EHT protocol is disabled, and driver must follow the capabilities. Otherwise, chips become unusable. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-5-pkshih@realtek.com
2026-01-15wifi: rtw89: support EHT GI/LTF settingKuan-Chung Chen1-10/+18
Add support for fixed EHT GI/LTF via nl80211. The command example: iw wlan0 set bitrates eht-gi-6 0.8 eht-ltf-6 2 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-4-pkshih@realtek.com
2026-01-15wifi: rtw89: wow: add reason codes for disassociation in WoWLAN modeChin-Yen Lee2-0/+5
Some APs disconnect clients by sending a Disassociation frame rather than a Deauthentication frame. Since these frames use different reason codes in WoWLAN mode, this commit adds support for handling Disassociation to prevent missed disconnection events. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-3-pkshih@realtek.com
2026-01-15wifi: rtw89: pci: validate sequence number of TX release reportPing-Ke Shih1-1/+6
Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wd_ring->pages array, causing NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: <IRQ> rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 </IRQ> <TASK> rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> To prevent crash, validate rpp_info.seq before using. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-2-pkshih@realtek.com
2026-01-14wifi: mac80211: add support for encryption/decryption of (Re)Association framesKavita Kavita5-4/+34
Currently, mac80211 does not encrypt or decrypt (Re)Association frames (Request and Response) because temporal keys are not yet available at that stage. With extensions from IEEE P802.11bi, e.g. EPPKE, temporal keys can be established before association. This enables the encryption and decryption of (Re)Association Request/Response frames. Add support to unset the IEEE80211_TX_INTFL_DONT_ENCRYPT flag when the peer is marked as an Enhanced Privacy Protection (EPP) peer and encryption keys are available for the connection in non-AP STA mode, allowing secure transmission of (Re)Association Request frames. Drop unprotected (Re)Association Request/Response frames received from an EPP peer. Co-developed-by: Sai Pratyusha Magam <quic_smagam@quicinc.com> Signed-off-by: Sai Pratyusha Magam <quic_smagam@quicinc.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-9-kavita.kavita@oss.qualcomm.com [remove useless parentheses] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: mac80211: add support for EPPKE authentication protocol in non-AP STA modeKavita Kavita2-7/+26
Add support for the Enhanced Privacy Protection Key Exchange (EPPKE) authentication protocol in non-AP STA mode, as specified in "IEEE P802.11bi/D3.0, 12.16.9". EPPKE is an RSNA authentication protocol that operates using Pre-Association Security Negotiation (PASN) procedures. It consists of three Authentication frames with transaction sequence numbers 1, 2, and 3. The first and third from the non-AP STA and the second from the AP STA. Extend mac80211 to process EPPKE Authentication frames during the authentication phase. Currently, mac80211 processes only frames with the expected transaction number. In the case of EPPKE, process the Authentication frame from the AP only if the transaction number matches the expected value, which is 2. After receiving the final Authentication frame with transaction number 3 from the non-AP STA, it indicates that both the non-AP STA and the AP confirm there are no issues with authentication. Since this is the final confirmation frame to send out, mark the state as authenticated in mac80211. For EPPKE authentication, the Multi-Link element (MLE) must be included in the Authentication frame body by userspace in case of MLO connection. If the MLE is not present, reject the Authentication frame. Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-8-kavita.kavita@oss.qualcomm.com [remove a single stray space] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: mac80211: Check for MLE before appending in Authentication frameKavita Kavita1-3/+9
Currently, in MLO connections, userspace constructs most of the Authentication frame body, excluding the Multi-Link element (MLE), which mac80211 appends later in ieee80211_send_auth(). At present, mac80211 always adds the MLE itself, since userspace (e.g. wpa_supplicant) does not yet include it. However, for new authentication protocols such as Enhanced Privacy Protection Key Exchange (EPPKE), as specified in "IEEE P802.11bi/D3.0 section 12.16.9", the MLE must be included in userspace so that the Message Integrity Code (MIC) can be computed correctly over the complete frame body. Table 9-71 specifies that the MIC is mandatory. If mac80211 appends the MLE again, the Authentication frame becomes invalid. Add a check in ieee80211_send_auth() to detect whether the MLE is already present in the Authentication frame body before appending. Skip the append if the MLE exists, otherwise add it as before. Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-7-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: mac80211: allow key installation before associationKavita Kavita3-2/+19
Currently, mac80211 allows key installation only after association completes. However, Enhanced Privacy Protection Key Exchange (EPPKE) requires key installation before association to enable encryption and decryption of (Re)Association Request and Response frames. Add support to install keys prior to association when the peer is an Enhanced Privacy Protection (EPP) peer that requires encryption and decryption of (Re)Association Request and Response frames. Introduce a new boolean parameter "epp_peer" in the "ieee80211_sta" profile to indicate that the peer supports the Enhanced Privacy Protection Key Exchange (EPPKE) protocol. For non-AP STA mode, it is set when the authentication algorithm is WLAN_AUTH_EPPKE during station profile initialization. For AP mode, it is set during NL80211_CMD_NEW_STA and NL80211_CMD_ADD_LINK_STA. When "epp_peer" parameter is set, mac80211 now accepts keys before association and enables encryption of the (Re)Association Request/Response frames. Co-developed-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com> Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-6-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: nl80211: Add support for EPP peer indicationSai Pratyusha Magam3-0/+12
Introduce a new netlink attribute NL80211_ATTR_EPP_PEER to be used with NL80211_CMD_NEW_STA and NL80211_CMD_ADD_LINK_STA for the userspace to indicate that a non-AP STA is an Enhanced Privacy Protection (EPP) peer. 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> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-5-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: cfg80211: add support for key configuration before associationKavita Kavita1-1/+3
Currently, cfg80211 does not allow key installation, removal, or modification prior to association in non-AP STA mode. However, Enhanced Privacy Protection Key Exchange (EPPKE) requires encryption keys to be managed before association. Add support to manage keys before association in non-AP STA mode when the NL80211_EXT_FEATURE_ASSOC_FRAME_ENCRYPTION feature flag is set. If the flag is not set, reject the encryption keys. Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-4-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: cfg80211: add feature flag for (re)association frame encryptionAiny Kumari1-0/+6
Introduce an extended feature flag that allows drivers to signal support for encryption of (Re)Association Request and Response frames in both non-AP STA and AP mode, as specified in specification "IEEE P802.11bi/D3.0, 12.16.6". Signed-off-by: Ainy Kumari <ainy.kumari@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-3-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: cfg80211: add support for EPPKE Authentication ProtocolAiny Kumari3-2/+20
Add an extended feature flag NL80211_EXT_FEATURE_EPPKE to allow a driver to indicate support for the Enhanced Privacy Protection Key Exchange (EPPKE) authentication protocol in non-AP STA mode, as defined in "IEEE P802.11bi/D3.0, 12.16.9". In case of SME in userspace, the Authentication frame body is prepared in userspace while the driver finalizes the Authentication frame once it receives the required fields and elements. The driver indicates support for EPPKE using the extended feature flag so that userspace can initiate EPPKE authentication. When the feature flag is set, process EPPKE Authentication frames from userspace in non-AP STA mode. If the flag is not set, reject EPPKE Authentication frames. Define a new authentication type NL80211_AUTHTYPE_EPPKE for EPPKE. Signed-off-by: Ainy Kumari <ainy.kumari@oss.qualcomm.com> Co-developed-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-2-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-13wifi: cfg80211: don't apply HT flags to S1G channelsLachlan Hodges1-1/+10
HT flags don't really make sense when applied to S1G channels especially given the bandwidths both used for calculations and conveyed (i.e 20MHz). Similarly with the 80/160/..MHz channels, each bonded subchannel is validated individually within cfg80211_s1g_usable(), so the regulatory validation is similarly redundant. Additionally, usermode application output (such as iwinfo below) doesn't particularly make sense when enumerating S1G channels: before: 925.500 MHz (Band: 900 MHz, Channel 47) [NO_HT40+, NO_HT40-, NO_16MHZ] 926.500 MHz (Band: 900 MHz, Channel 49) [NO_HT40+, NO_HT40-, NO_16MHZ] 927.500 MHz (Band: 900 MHz, Channel 51) [NO_HT40+, NO_HT40-, NO_16MHZ, NO_PRIMARY] after: 925.500 MHz (Band: 900 MHz, Channel 47) [NO_16MHZ] 926.500 MHz (Band: 900 MHz, Channel 49) [NO_16MHZ] 927.500 MHz (Band: 900 MHz, Channel 51) [NO_16MHZ, NO_PRIMARY] Don't process the S1G band when applying HT flags as both the regulatory component is redundant and the flags don't make sense for S1G channels. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260113030934.18726-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-13wifi: rtw89: Add support for D-Link VR Air Bridge (DWA-F18)Zenm Chen1-0/+2
Add the ID 2001:3323 to the table to support an additional RTL8832AU adapter: D-Link VR Air Bridge (DWA-F18). Compile tested only. Link: https://github.com/morrownr/rtw89/pull/44 Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260112004759.6028-1-zenmchen@gmail.com
2026-01-13wifi: rtw89: Add support for MSI AX1800 Nano (GUAX18N)Zenm Chen1-0/+2
Add the ID 0db0:f0c8 to the table to support an additional RTL8832BU adapter: MSI AX1800 Nano (GUAX18N). Compile tested only. Link: https://github.com/morrownr/rtl8852bu-20250826/pull/2 Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260112004358.5516-1-zenmchen@gmail.com
2026-01-13wifi: rtw89: mac: set EDCCA configurations for RTL8922DPing-Ke Shih5-0/+273
Update EDCCA settings of MAC part for RTL8922D to consider EDCCA state signaled by BB circuit. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-14-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: add an entry to enable MAC function in preinitPing-Ke Shih3-0/+82
The preinit is to initialize partial MAC hardware needed before downloading firmware, and then does post-init after firmware runs. For RTL8922D, initialize some DMAC and CMAC at this step. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-13-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: separate functions of CMAC power and function enablePing-Ke Shih4-16/+100
To enable/disable CMAC function somewhere, separate controls of CMAC power and function into individual functions. Also correct the hardware settings by the way. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-12-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: configure DMA_STOP1 by predefined maskPing-Ke Shih4-31/+24
For coming chip 8922DE, the DMA channel set is different from existing one, so use predefined mask to handle the difference. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-11-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: define preload_init for generationsPing-Ke Shih3-3/+8
The preload_init is to define preload size from memory to transmitting buffer. The different generations should call its callback respectively but suddenly it is missed. However, the register definitions of WiFi 6/7 are the same, things are well. For the coming RTL8922D, settings are different, so abstract it. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-10-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: update WP quota for RTL8922DPing-Ke Shih4-6/+35
WP (WiFi payload) quota is to point to payload being transmitting in memory. Assign quota to indicate WP page full. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-9-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: update MPDU quota according to chip DLE definitionPing-Ke Shih4-1/+14
MPDU quota is to define number of memory used to handle packets in DLE (Data Link Engine). All chips use the same value before, but the RTL8922D need to use chip specific value. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-8-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: set quota 13 for PLE SNRPTPing-Ke Shih2-0/+9
The RTL8922D has additional quota 13 of SNRPT for PLE (payload engine). Set value to the quota according to predefined tables. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-7-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: add dle_mem and ple_{min,max}_qt quota for RTL8922DPing-Ke Shih3-2/+47
The quota of DLE and PLE depends on hardware design and consideration of performance and application. Define them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-6-pkshih@realtek.com
2026-01-13wifi: rtw89: mac: remove unnecessary return from ↵Ping-Ke Shih1-1/+1
rtw89_fwdl_secure_idmem_share_mode() The return type of rtw89_fwdl_secure_idmem_share_mode() is void, so no need a return. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-5-pkshih@realtek.com
2026-01-13wifi: rtw89: coex: update coex software control for RTL8922DChia-Yuan Li3-1/+129
Update software control API due to 8922D PTA hardware changes. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-4-pkshih@realtek.com
2026-01-13wifi: rtw89: coex: update scoreboard value according to power state for two BTPing-Ke Shih1-3/+19
Assign timeslot to WiFi if power state is on. Since firmware isn't working at this moment, write scoreboard register to notify BT. Extend the code to support two BT for coming chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-3-pkshih@realtek.com
2026-01-13wifi: rtw89: coex: make coex scoreboard as chip infoPing-Ke Shih9-5/+29
The coex scoreboard is to exchange WiFi and BT profiles, and the coming chip 8922D changes the design including extend to two scoreboards and individual register for cfg/get. Follow the changes to abstract current code, but not change logic for existing chips at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260108120320.2217402-2-pkshih@realtek.com
2026-01-13Merge tag 'wireless-next-2026-01-12' of ↵Jakub Kicinski103-17405/+20328
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== First set of changes for the current -next cycle, of note: - ath12k gets an overhaul to support multi-wiphy device wiphy and pave the way for future device support in the same driver (rather than splitting to ath13k) - mac80211 gets some better iteration macros * tag 'wireless-next-2026-01-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (120 commits) wifi: mac80211: remove width argument from ieee80211_parse_bitrates wifi: mac80211_hwsim: remove NAN by default wifi: mac80211: improve station iteration ergonomics wifi: mac80211: improve interface iteration ergonomics wifi: cfg80211: include S1G_NO_PRIMARY flag when sending channel wifi: mac80211: unexport ieee80211_get_bssid() wl1251: Replace strncpy with strscpy in wl1251_acx_fw_version wifi: iwlegacy: 3945-rs: remove redundant pointer check in il3945_rs_tx_status() and il3945_rs_get_rate() wifi: mac80211: don't send an unused argument to ieee80211_check_combinations wifi: libertas: fix WARNING in usb_tx_block wifi: mwifiex: Allocate dev name earlier for interface workqueue name wifi: wlcore: sdio: Use pm_ptr instead of #ifdef CONFIG_PM wifi: cfg80211: Fix use_for flag update on BSS refresh wifi: brcmfmac: rename function that frees vif wifi: brcmfmac: fix/add kernel-doc comments wifi: mac80211: Update csa_finalize to use link_id wifi: cfg80211: add cfg80211_stop_link() for per-link teardown wifi: ath12k: Skip DP peer creation for scan vdev wifi: ath12k: move firmware stats request outside of atomic context wifi: ath12k: add the missing RCU lock in ath12k_dp_tx_free_txbuf() ... ==================== Link: https://patch.msgid.link/20260112185836.378736-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-04-30 13:52:07 +0300