kernel/drivers/net/wireless/marvell/mwl8k.c, branch linux-6.2.y

wifi: mac80211: add wake_tx_queue callback to drivers

2022-10-10T09:00:03Z

mac80211 is fully switching over to the internal TX queue (iTXQ) implementation. Update all drivers not yet providing the now mandatory wake_tx_queue() callback. As an side effect the netdev interfaces of all updated drivers will switch to the noqueue qdisc. Signed-off-by: Alexander Wetzel [add staging drivers] Signed-off-by: Johannes Berg

wifi: mwl8k: use time_after to replace "jiffies > a"

2022-07-27T10:58:10Z

time_after deals with timer wrapping correctly. Signed-off-by: Li Qiong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220606135449.23256-1-liqiong@nfschina.com Link: https://lore.kernel.org/r/20220618131305.13101-1-wangxiang@cdjrlc.com Link: https://lore.kernel.org/r/20220715050016.24164-1-wangborong@cdjrlc.com

wifi: mac80211: change QoS settings API to take link into account

2022-07-15T09:43:15Z

Take the link into account in the QoS settings (EDCA parameters) APIs. Signed-off-by: Johannes Berg

wifi: mac80211: return a beacon for a specific link

2022-06-20T10:57:08Z

Pass the link id through to the get_beacon and return the beacon for a specific link id. Signed-off-by: Shaul Triebitz Signed-off-by: Johannes Berg

wifi: mac80211: split bss_info_changed method

2022-06-20T10:55:09Z

Split the bss_info_changed method to vif_cfg_changed and link_info_changed, with the latter getting a link ID. Also change the 'changed' parameter to u64 already, we know we need that. Signed-off-by: Johannes Berg

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

mwl8k: Use named struct for memcpy() region

2021-11-29T10:46:07Z

In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use named struct in struct mwl8k_cmd_set_key around members key_material, tkip_tx_mic_key, and tkip_rx_mic_key so they can be referenced together. This will allow memcpy() and sizeof() to more easily reason about sizes, improve readability, and avoid future warnings about writing beyond the end of key_material. "pahole" shows no size nor member offset changes to struct mwl8k_cmd_set_key. "objdump -d" shows no object code changes. Signed-off-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211119004905.2348143-1-keescook@chromium.org

mwl8k: Fix use-after-free in mwl8k_fw_state_machine()

2021-10-20T08:41:21Z

When the driver fails to request the firmware, it calls its error handler. In the error handler, the driver detaches device from driver first before releasing the firmware, which can cause a use-after-free bug. Fix this by releasing firmware first. The following log reveals it: [ 9.007301 ] BUG: KASAN: use-after-free in mwl8k_fw_state_machine+0x320/0xba0 [ 9.010143 ] Workqueue: events request_firmware_work_func [ 9.010830 ] Call Trace: [ 9.010830 ] dump_stack_lvl+0xa8/0xd1 [ 9.010830 ] print_address_description+0x87/0x3b0 [ 9.010830 ] kasan_report+0x172/0x1c0 [ 9.010830 ] ? mutex_unlock+0xd/0x10 [ 9.010830 ] ? mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] ? mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] __asan_report_load8_noabort+0x14/0x20 [ 9.010830 ] mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] ? mwl8k_load_firmware+0x5f0/0x5f0 [ 9.010830 ] request_firmware_work_func+0x172/0x250 [ 9.010830 ] ? read_lock_is_recursive+0x20/0x20 [ 9.010830 ] ? process_one_work+0x7a1/0x1100 [ 9.010830 ] ? request_firmware_nowait+0x460/0x460 [ 9.010830 ] ? __this_cpu_preempt_check+0x13/0x20 [ 9.010830 ] process_one_work+0x9bb/0x1100 Signed-off-by: Zheyu Ma Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1634356979-6211-1-git-send-email-zheyuma97@gmail.com

mwl8k: Avoid memcpy() over-reading of mcs.rx_mask

2021-06-22T15:23:54Z

In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields. Use the sub-structure address directly. Signed-off-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210617041431.2168953-1-keescook@chromium.org