linux.git/drivers/net/wireless/rsi/rsi_91x_mgmt.c, branch master

wifi: rsi: bound background scan probe request copy

2026-07-06T12:11:08Z

rsi_send_bgscan_probe_req() allocates room for struct rsi_bgscan_probe plus MAX_BGSCAN_PROBE_REQ_LEN bytes, but copies the entire mac80211-generated probe request skb after the fixed header. The probe request length depends on scan IEs and is not checked against the fixed firmware buffer. Reject generated probe requests that do not fit the firmware command buffer before copying them into the skb. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704011231.45593-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg

wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers

2026-07-06T12:11:08Z

rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260701053414.34015-1-pengpeng@iscas.ac.cn [drop useless length check] Signed-off-by: Johannes Berg

wifi: rsi: Slightly simplify rsi_set_channel()

2023-03-31T14:45:50Z

There is no point in allocating 'skb' and then freeing it if !channel. Make the sanity check first to slightly simplify the code. Signed-off-by: Christophe JAILLET Reviewed-by: Simon Horman Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/29bf0296bd939e3f6952272bfdcc73b22edbc374.1679328588.git.christophe.jaillet@wanadoo.fr

wifi: mac80211: move interface config to new struct

2022-06-20T10:55:03Z

We'll use bss_conf for per-link configuration later, so move out all the non-link-specific data out into a new struct ieee80211_vif_cfg used in the vif. Some adjustments were done with the following spatch: @@ expression sdata; struct ieee80211_vif *vifp; identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator }; @@ ( -sdata->vif.bss_conf.var +sdata->vif.cfg.var | -vifp->bss_conf.var +vifp->cfg.var ) @bss_conf@ struct ieee80211_bss_conf *bss_conf; identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator }; @@ -bss_conf->var +vif_cfg->var (though more manual fixups were needed, e.g. replacing "vif_cfg->" by "vif->cfg." in many files.) Signed-off-by: Johannes Berg

mac80211: prepare sta handling for MLO support

2022-04-11T14:42:03Z

Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg

rsi: fix rate mask set leading to P2P failure

2021-09-21T05:42:37Z

P2P client mode was only working the first time. On subsequent connection attempts the group was successfully created but no data was sent (no transmitted data packets were seen with a sniffer). The reason for this was that the hardware was being configured in fixed rate mode with rate RSI_RATE_1 (1Mbps) which is not valid in the 5GHz band. In P2P mode wpa_supplicant uses NL80211_CMD_SET_TX_BITRATE_MASK to disallow the 11b rates in the 2.4GHz band which updated common->fixedrate_mask. rsi_set_min_rate() then used the fixedrate_mask to calculate the minimum allowed rate, or 0xffff = auto if none was found. However that calculation did not account for the different rate sets allowed in the different bands leading to the error. Fixing set_min_rate() would result in 6Mb/s being used all the time which is not what we want either. The reason the problem did not occur on the first connection is that rsi_mac80211_set_rate_mask() only updated the fixedrate_mask for the *current* band. When it was called that was still 2.4GHz as the switch is done later. So the when set_min_rate() was subsequently called after the switch to 5GHz it still had a mask of zero, leading to defaulting to auto mode. Fix this by differentiating the case of a single rate being requested, in which case the hardware will be used in fixed rate mode with just that rate, and multiple rates being requested, in which case we remain in auto mode but the firmware rate selection algorithm is configured with a restricted set of rates. Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-4-git-send-email-martin.fuzzey@flowbird.group

rsi: fix occasional initialisation failure with BT coex

2021-09-21T05:42:36Z

When BT coexistence is enabled (eg oper mode 13, which is the default) the initialisation on startup sometimes silently fails. In a normal initialisation we see usb 1-1.3: Product: Wireless USB Network Module usb 1-1.3: Manufacturer: Redpine Signals, Inc. usb 1-1.3: SerialNumber: 000000000001 rsi_91x: rsi_probe: Initialized os intf ops rsi_91x: rsi_load_9116_firmware: Loading chunk 0 rsi_91x: rsi_load_9116_firmware: Loading chunk 1 rsi_91x: rsi_load_9116_firmware: Loading chunk 2 rsi_91x: Max Stations Allowed = 1 But sometimes the last log is missing and the wlan net device is not created. Running a userspace loop that resets the hardware via a GPIO shows the problem occurring ~5/100 resets. The problem does not occur in oper mode 1 (wifi only). Adding logs shows that the initialisation state machine requests a MAC reset via rsi_send_reset_mac() but the firmware does not reply, leading to the initialisation sequence being incomplete. Fix this by delaying attaching the BT adapter until the wifi initialisation has completed. With this applied I have done > 300 reset loops with no errors. Fixes: 716b840c7641 ("rsi: handle BT traffic in driver") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-2-git-send-email-martin.fuzzey@flowbird.group

rsi: fix AP mode with WPA failure due to encrypted EAPOL

2021-06-15T13:42:18Z

In AP mode WPA2-PSK connections were not established. The reason was that the AP was sending the first message of the 4 way handshake encrypted, even though no pairwise key had (correctly) yet been set. Encryption was enabled if the "security_enable" driver flag was set and encryption was not explicitly disabled by IEEE80211_TX_INTFL_DONT_ENCRYPT. However security_enable was set when *any* key, including the AP GTK key, had been set which was causing unwanted encryption even if no key was avaialble for the unicast packet to be sent. Fix this by adding a check that we have a key and drop the old security_enable driver flag which is insufficient and redundant. The Redpine downstream out of tree driver does it this way too. Regarding the Fixes tag the actual code being modified was introduced earlier, with the original driver submission, in dad0d04fa7ba ("rsi: Add RS9113 wireless driver"), however at that time AP mode was not yet supported so there was no bug at that point. So I have tagged the introduction of AP support instead which was part of the patch set "rsi: support for AP mode" [1] It is not clear whether AP WPA has ever worked, I can see nothing on the kernel side that broke it afterwards yet the AP support patch series says "Tests are performed to confirm aggregation, connections in WEP and WPA/WPA2 security." One possibility is that the initial tests were done with a modified userspace (hostapd). [1] https://www.spinics.net/lists/linux-wireless/msg165302.html Signed-off-by: Martin Fuzzey Fixes: 38ef62353acb ("rsi: security enhancements for AP mode") CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1622564459-24430-1-git-send-email-martin.fuzzey@flowbird.group

rsi: Fix missing function name in comments

2021-06-15T13:10:46Z

Fixes the following W=1 kernel build warning(s): drivers/net/wireless/rsi/rsi_91x_mgmt.c:1550: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Amitkumar Karwar Cc: Siva Rebbagondla Signed-off-by: Yang Shen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210517050141.61488-10-shenyang39@huawei.com

rsi: Add descriptions for rsi_set_vap_capabilities()'s parameters

2020-09-01T09:20:12Z

Fixes the following W=1 kernel build warning(s): drivers/net/wireless/rsi/rsi_91x_mgmt.c:713: warning: Function parameter or member 'mac_addr' not described in 'rsi_set_vap_capabilities' drivers/net/wireless/rsi/rsi_91x_mgmt.c:713: warning: Function parameter or member 'vap_id' not described in 'rsi_set_vap_capabilities' drivers/net/wireless/rsi/rsi_91x_mgmt.c:713: warning: Function parameter or member 'vap_status' not described in 'rsi_set_vap_capabilities' Cc: Amitkumar Karwar Cc: Siva Rebbagondla Cc: Kalle Valo Cc: "David S. Miller" Cc: Jakub Kicinski Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200821071644.109970-7-lee.jones@linaro.org