Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21 |
|
#
8de7838a |
| 20-Mar-2023 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
wifi: rsi: Slightly simplify rsi_set_channel()
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: Chri
wifi: rsi: Slightly simplify rsi_set_channel()
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 <christophe.jaillet@wanadoo.fr> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/29bf0296bd939e3f6952272bfdcc73b22edbc374.1679328588.git.christophe.jaillet@wanadoo.fr
show more ...
|
Revision tags: v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39 |
|
#
f276e20b |
| 10-May-2022 |
Johannes Berg <johannes.berg@intel.com> |
wifi: mac80211: move interface config to new struct
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 th
wifi: mac80211: move interface config to new struct
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 <johannes.berg@intel.com>
show more ...
|
Revision tags: v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
046d2e7c |
| 04-Apr-2022 |
Sriram R <quic_srirrama@quicinc.com> |
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee8
mac80211: prepare sta handling for MLO support
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 <quic_srirrama@quicinc.com> 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 <johannes.berg@intel.com>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62 |
|
#
b515d097 |
| 30-Aug-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rsi: fix rate mask set leading to P2P failure
P2P client mode was only working the first time. On subsequent connection attempts the group was successfully created but no data was sent (no transmitt
rsi: fix rate mask set leading to P2P failure
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 <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630337206-12410-4-git-send-email-martin.fuzzey@flowbird.group
show more ...
|
#
9b14ed6e |
| 30-Aug-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rsi: fix occasional initialisation failure with BT coex
When BT coexistence is enabled (eg oper mode 13, which is the default) the initialisation on startup sometimes silently fails.
In a normal in
rsi: fix occasional initialisation failure with BT coex
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 <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630337206-12410-2-git-send-email-martin.fuzzey@flowbird.group
show more ...
|
#
a72ebbbc |
| 30-Aug-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rsi: fix rate mask set leading to P2P failure
commit b515d097053a71d624e0c5840b42cd4caa653941 upstream.
P2P client mode was only working the first time. On subsequent connection attempts the group
rsi: fix rate mask set leading to P2P failure
commit b515d097053a71d624e0c5840b42cd4caa653941 upstream.
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 <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630337206-12410-4-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d63343e5 |
| 30-Aug-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rsi: fix occasional initialisation failure with BT coex
commit 9b14ed6e11b72dd4806535449ca6c6962cb2369d upstream.
When BT coexistence is enabled (eg oper mode 13, which is the default) the initiali
rsi: fix occasional initialisation failure with BT coex
commit 9b14ed6e11b72dd4806535449ca6c6962cb2369d upstream.
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 <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630337206-12410-2-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42 |
|
#
31453804 |
| 01-Jun-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rsi: fix AP mode with WPA failure due to encrypted EAPOL
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 encryp
rsi: fix AP mode with WPA failure due to encrypted EAPOL
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 <martin.fuzzey@flowbird.group> Fixes: 38ef62353acb ("rsi: security enhancements for AP mode") CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1622564459-24430-1-git-send-email-martin.fuzzey@flowbird.group
show more ...
|
Revision tags: v5.10.41, v5.10.40, v5.10.39 |
|
#
c707db1b |
| 17-May-2021 |
Yang Shen <shenyang39@huawei.com> |
rsi: Fix missing function name in comments
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 kerne
rsi: Fix missing function name in comments
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 <amitkarwar@gmail.com> Cc: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-10-shenyang39@huawei.com
show more ...
|
#
998de999 |
| 01-Jun-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rsi: fix AP mode with WPA failure due to encrypted EAPOL
commit 314538041b5632ffaf64798faaeabaf2793fe029 upstream.
In AP mode WPA2-PSK connections were not established.
The reason was that the AP
rsi: fix AP mode with WPA failure due to encrypted EAPOL
commit 314538041b5632ffaf64798faaeabaf2793fe029 upstream.
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 <martin.fuzzey@flowbird.group> Fixes: 38ef62353acb ("rsi: security enhancements for AP mode") CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1622564459-24430-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60 |
|
#
a451ff85 |
| 21-Aug-2020 |
Lee Jones <lee.jones@linaro.org> |
rsi: Add descriptions for rsi_set_vap_capabilities()'s parameters
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/rsi/rsi_91x_mgmt.c:713: warning: Function parameter or membe
rsi: Add descriptions for rsi_set_vap_capabilities()'s parameters
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 <amitkarwar@gmail.com> Cc: Siva Rebbagondla <siva8118@gmail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200821071644.109970-7-lee.jones@linaro.org
show more ...
|
#
31117517 |
| 19-Aug-2020 |
Lee Jones <lee.jones@linaro.org> |
rsi: Fix a myriad of documentation issues
Too many, not enough, misnamed and formatting problems, all resolved.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/rsi/rsi_91x_m
rsi: Fix a myriad of documentation issues
Too many, not enough, misnamed and formatting problems, all resolved.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/rsi/rsi_91x_mgmt.c:24: warning: cannot understand function prototype: 'struct bootup_params boot_params_20 = ' drivers/net/wireless/rsi/rsi_91x_mgmt.c:487: warning: Excess function parameter 'type' description in 'rsi_mgmt_pkt_to_core' drivers/net/wireless/rsi/rsi_91x_mgmt.c:538: warning: Function parameter or member 'sta_id' not described in 'rsi_hal_send_sta_notify_frame' drivers/net/wireless/rsi/rsi_91x_mgmt.c:538: warning: Function parameter or member 'vif' not described in 'rsi_hal_send_sta_notify_frame' drivers/net/wireless/rsi/rsi_91x_mgmt.c:615: warning: Function parameter or member 'sta_id' not described in 'rsi_send_aggregation_params_frame' drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or member 'mode' not described in 'rsi_set_vap_capabilities' drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or member 'mac_addr' not described in 'rsi_set_vap_capabilities' drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or member 'vap_id' not described in 'rsi_set_vap_capabilities' drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or member 'vap_status' not described in 'rsi_set_vap_capabilities' drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Excess function parameter 'opmode' description in 'rsi_set_vap_capabilities' drivers/net/wireless/rsi/rsi_91x_mgmt.c:794: warning: Function parameter or member 'sta_id' not described in 'rsi_hal_load_key' drivers/net/wireless/rsi/rsi_91x_mgmt.c:794: warning: Function parameter or member 'vif' not described in 'rsi_hal_load_key' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1053: warning: Function parameter or member 'curchan' not described in 'rsi_band_check' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1173: warning: Excess function parameter 'channel' description in 'rsi_send_radio_params_update' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1299: warning: Function parameter or member 'sta' not described in 'rsi_send_auto_rate_request' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1299: warning: Function parameter or member 'sta_id' not described in 'rsi_send_auto_rate_request' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1299: warning: Function parameter or member 'vif' not described in 'rsi_send_auto_rate_request' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or member 'opmode' not described in 'rsi_inform_bss_status' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or member 'addr' not described in 'rsi_inform_bss_status' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or member 'sta' not described in 'rsi_inform_bss_status' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or member 'sta_id' not described in 'rsi_inform_bss_status' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or member 'assoc_cap' not described in 'rsi_inform_bss_status' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or member 'vif' not described in 'rsi_inform_bss_status' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Excess function parameter 'bssid' description in 'rsi_inform_bss_status' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1543: warning: Function parameter or member 'common' not described in 'rsi_send_block_unblock_frame' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1543: warning: Function parameter or member 'block_event' not described in 'rsi_send_block_unblock_frame' drivers/net/wireless/rsi/rsi_91x_mgmt.c:1587: warning: Excess function parameter 'Return' description in 'rsi_send_rx_filter_frame'
Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Siva Rebbagondla <siva8118@gmail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200819072402.3085022-21-lee.jones@linaro.org
show more ...
|
Revision tags: v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3 |
|
#
d563131e |
| 13-Sep-2019 |
Navid Emamdoost <navid.emamdoost@gmail.com> |
rsi: release skb if rsi_prepare_beacon fails
In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should be released.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-
rsi: release skb if rsi_prepare_beacon fails
In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should be released.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6 |
|
#
0a60014b |
| 02-Apr-2019 |
Siva Rebbagondla <siva8118@gmail.com> |
rsi: miscallaneous changes for 9116 and common
Below changes are done: * Device 80MHz clock should be disabled for 9116 in 20MHz band. * Default edca parameters should be used initially before con
rsi: miscallaneous changes for 9116 and common
Below changes are done: * Device 80MHz clock should be disabled for 9116 in 20MHz band. * Default edca parameters should be used initially before connection. * Default TA aggregation is 3 for 9116. * Bootup parameters should be loaded first when channel is changed. * 4 byte register writes are possible for 9116.
Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
#
1533f976 |
| 02-Apr-2019 |
Siva Rebbagondla <siva8118@gmail.com> |
rsi: send new tx command frame wlan9116 features
For 9116 device, we have introduced w9116 features frame, which shall be send when radio capabilities confirm is received.
Signed-off-by: Siva Rebba
rsi: send new tx command frame wlan9116 features
For 9116 device, we have introduced w9116 features frame, which shall be send when radio capabilities confirm is received.
Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
#
f911c861 |
| 02-Apr-2019 |
Siva Rebbagondla <siva8118@gmail.com> |
rsi: new bootup parameters for 9116
Bootup parameters are different for 9116 device. Check added for device model where-ever bootup parameters are being send.
Signed-off-by: Siva Rebbagondla <siva8
rsi: new bootup parameters for 9116
Bootup parameters are different for 9116 device. Check added for device model where-ever bootup parameters are being send.
Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
#
9ba4562a |
| 02-Apr-2019 |
Siva Rebbagondla <siva8118@gmail.com> |
rsi: change in device init frame sequence for 9116
Initial frame exchange sequence has been changed for 9116 chip. Getting MAC address using EEPROM read frame will be once common device configuratio
rsi: change in device init frame sequence for 9116
Initial frame exchange sequence has been changed for 9116 chip. Getting MAC address using EEPROM read frame will be once common device configuration is done and RESET_MAC frame is sending after bootup parameters confirmation is received, which are different from RS9113 device
Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25 |
|
#
74ee436f |
| 21-Feb-2019 |
Colin Ian King <colin.king@canonical.com> |
rsi: fix missing null pointer check from a failed ieee80211_probereq_get call
The call to ieee80211_probereq_get can return NULL if a skb allocation fails, so add a null pointer check and free an ea
rsi: fix missing null pointer check from a failed ieee80211_probereq_get call
The call to ieee80211_probereq_get can return NULL if a skb allocation fails, so add a null pointer check and free an earlier skb on the error exit return path.
Fixes: 7fdcb8e12660 ("rsi: add support for hardware scan offload") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.24, v4.19.23, v4.19.22, v4.19.21 |
|
#
b9c767fd |
| 12-Feb-2019 |
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> |
rsi: fix spelling mistakes
Trivial fixes to spelling mistakes in various files in rsi folder.
Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@
rsi: fix spelling mistakes
Trivial fixes to spelling mistakes in various files in rsi folder.
Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.20 |
|
#
6f3a5de1 |
| 04-Feb-2019 |
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> |
rsi: Add debug support for wowlan wakeup confirmation
When a wowlan magic-packet has received to wake up the device, currently driver is not taking care of what kind of packet has received. This pat
rsi: Add debug support for wowlan wakeup confirmation
When a wowlan magic-packet has received to wake up the device, currently driver is not taking care of what kind of packet has received. This patch will add debug support for wakeup reason in driver.
Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13 |
|
#
7fdcb8e1 |
| 27-Dec-2018 |
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> |
rsi: add support for hardware scan offload
With the current approach of scanning, roaming delays are observed. Firmware has support for back ground scanning. To get this advantage, mac80211 hardware
rsi: add support for hardware scan offload
With the current approach of scanning, roaming delays are observed. Firmware has support for back ground scanning. To get this advantage, mac80211 hardware scan is implemented, which decides type of scan to do based on connected state.
When station is in not connected, driver returns with special value 1 to trigger software scan in mac80211. In case of connected state, background scan will be triggered.
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5 |
|
#
4c837d8c |
| 05-Jul-2018 |
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> |
rsi: fix for WoWLAN wakeup in security mode.
System is unable to wake-up through magic-packet in secured connections. Because key descriptor is getting corrupted and firmware is unable to decrypt th
rsi: fix for WoWLAN wakeup in security mode.
System is unable to wake-up through magic-packet in secured connections. Because key descriptor is getting corrupted and firmware is unable to decrypt the magic packet. Fixed the issue by properly preparing it before sending it to firmware.
Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Sushant Kumar Mishra <sushant.mishra@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
#
38709316 |
| 05-Jul-2018 |
Ganapathi Raju <ganapathi.kondraju@redpinesignals.com> |
rsi: fix for 40MHZ connection issue.
Radio capabilities packet is not prepared properly for 40MHZ case, ppe_ack_rate is a two byte variable which is initialized wrongly, hence we are unable to conne
rsi: fix for 40MHZ connection issue.
Radio capabilities packet is not prepared properly for 40MHZ case, ppe_ack_rate is a two byte variable which is initialized wrongly, hence we are unable to connect, resolved by assigning it properly.
Signed-off-by: Ganapathi Raju <ganapathi.kondraju@redpinesignals.com> Signed-off-by: Sushant Kumar Mishra <sushant.mishra@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
eeed833a |
| 15-May-2018 |
Sanjay Konduri <sanjay.konduri@redpinesignals.com> |
rsi: add fix for corruption of auto rate table
Auto rate table sent to firmware is getting corrupted as memset to zeros is not done. Added memset to skb data before filling auto rate table.
Signed-
rsi: add fix for corruption of auto rate table
Auto rate table sent to firmware is getting corrupted as memset to zeros is not done. Added memset to skb data before filling auto rate table.
Signed-off-by: Sanjay Konduri <sanjay.konduri@redpinesignals.com> Signed-off-by: Sushant Kumar Mishra <sushant.mishra@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.16 |
|
#
4fd6c476 |
| 29-Mar-2018 |
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> |
rsi: roaming enhancements
To support roaming below changes are done: * Station notify frame is send to firmware after sending assoc request. This will avoid dropping of first EAPOL frame due to
rsi: roaming enhancements
To support roaming below changes are done: * Station notify frame is send to firmware after sending assoc request. This will avoid dropping of first EAPOL frame due to delay in creation of station control block in firmware. * Data queues are unblocked after sending station notify in open mode, after configuring key in WEP mode, and after receiving EAPOL4 confirm in WPA mode. * Initial EAPOL frames priority is chaged to MGMT, rekey EAPOL frames priority changed to VO.
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|