summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/marvell
AgeCommit message (Collapse)AuthorFilesLines
2022-05-03Merge tag 'wireless-next-2022-05-03' of ↵Jakub Kicinski4-25/+54
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v5.19 First set of patches for v5.19 and this is a big one. We have two new drivers, a change in mac80211 STA API affecting most drivers and ath11k getting support for WCN6750. And as usual lots of fixes and cleanups all over. Major changes: new drivers - wfx: silicon labs devices - plfxlc: pureLiFi X, XL, XC devices mac80211 - host based BSS color collision detection - prepare sta handling for IEEE 802.11be Multi-Link Operation (MLO) support rtw88 - support TP-Link T2E devices rtw89 - support firmware crash simulation - preparation for 8852ce hardware support ath11k - Wake-on-WLAN support for QCA6390 and WCN6855 - device recovery (firmware restart) support for QCA6390 and WCN6855 - support setting Specific Absorption Rate (SAR) for WCN6855 - read country code from SMBIOS for WCN6855/QCA6390 - support for WCN6750 wcn36xx - support for transmit rate reporting to user space * tag 'wireless-next-2022-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (228 commits) rtw89: 8852c: rfk: add DPK rtw89: 8852c: rfk: add IQK rtw89: 8852c: rfk: add RX DCK rtw89: 8852c: rfk: add RCK rtw89: 8852c: rfk: add TSSI rtw89: 8852c: rfk: add LCK rtw89: 8852c: rfk: add DACK rtw89: 8852c: rfk: add RFK tables plfxlc: fix le16_to_cpu warning for beacon_interval rtw88: remove a copy of the NAPI_POLL_WEIGHT define carl9170: tx: fix an incorrect use of list iterator wil6210: use NAPI_POLL_WEIGHT for napi budget ath10k: remove a copy of the NAPI_POLL_WEIGHT define ath11k: Add support for WCN6750 device ath11k: Datapath changes to support WCN6750 ath11k: HAL changes to support WCN6750 ath11k: Add QMI changes for WCN6750 ath11k: Fetch device information via QMI for WCN6750 ath11k: Add register access logic for WCN6750 ath11k: Add HW params for WCN6750 ... ==================== Link: https://lore.kernel.org/r/20220503153622.C1671C385A4@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-27mwifiex: Add SD8997 SDIO-UART firmwareAndrejs Cainikovs2-0/+3
With a recent change now it is possible to detect the strapping option on SD8997, which allows to pick up a correct firmware for either SDIO-SDIO or SDIO-UART. This commit enables SDIO-UART firmware on SD8997. Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220422090313.125857-3-andrejs.cainikovs@toradex.com
2022-04-27mwifiex: Select firmware based on strappingAndrejs Cainikovs2-1/+25
Some WiFi/Bluetooth modules might have different host connection options, allowing to either use SDIO for both WiFi and Bluetooth, or SDIO for WiFi and UART for Bluetooth. It is possible to detect whether a module has SDIO-SDIO or SDIO-UART connection by reading its host strap register. This change introduces a way to automatically select appropriate firmware depending of the connection method, and removes a need of symlinking or overwriting the original firmware file with a required one. Host strap register used in this commit comes from the NXP driver [1] hosted at Code Aurora. [1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/mlinux/moal_sdio_mmc.c?h=rel_imx_5.4.70_2.3.2&id=688b67b2c7220b01521ffe560da7eee33042c7bd#n1274 Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220422090313.125857-2-andrejs.cainikovs@toradex.com
2022-04-11mac80211: prepare sta handling for MLO supportSriram R1-24/+24
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>
2022-04-08mmc: core: improve API to make clear mmc_hw_reset is for cardsWolfram Sang1-1/+1
To make it unambiguous that mmc_hw_reset() is for cards and not for controllers, we make the function argument mmc_card instead of mmc_host. Also, all users are converted. Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220408080045.6497-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-04-06mwifiex: add mutex lock for call in mwifiex_dfs_chan_sw_work_queueNiels Dossche1-0/+2
cfg80211_ch_switch_notify uses ASSERT_WDEV_LOCK to assert that net_device->ieee80211_ptr->mtx (which is the same as priv->wdev.mtx) is held during the function's execution. mwifiex_dfs_chan_sw_work_queue is one of its callers, which does not hold that lock, therefore violating the assertion. Add a lock around the call. Disclaimer: I am currently working on a static analyser to detect missing locks. This was a reported case. I manually verified the report by looking at the code, so that I do not send wrong information or patches. After concluding that this seems to be a true positive, I created this patch. However, as I do not in fact have this particular hardware, I was unable to test it. Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Niels Dossche <dossche.niels@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220321225515.32113-1-dossche.niels@gmail.com
2022-03-16mwifiex: make read-only array wmm_oui static constColin Ian King1-1/+1
Don't populate the read-only array wmm_oui on the stack but instead make it static const. Also makes the object code a little smaller. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220311225610.10895-1-colin.i.king@gmail.com
2022-03-06wireless: Marvell: Use netif_rx().Sebastian Andrzej Siewior3-4/+4
Since commit baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any context.") the function netif_rx() can be used in preemptible/thread context as well as in interrupt context. Use netif_rx(). Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Ganapathi Bhat <ganapathi017@gmail.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: Sharvari Harisangam <sharvari.harisangam@nxp.com> Cc: Xinming Hu <huxinming820@gmail.com> Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-09spi: make remove callback a void functionUwe Kleine-König1-3/+1
The value returned by an spi driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Claudius Heine <ch@denx.de> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC Acked-by: Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by: Łukasz Stelmach <l.stelmach@samsung.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-08libertas_tf: Add missing __packed annotationsKees Cook1-14/+14
The earlier __packed annotations added in commit d71038c05970 ("libertas: Fix alignment issues in libertas core") were not duplicated when libertas_af was added in commit 7670e62c7ed6 ("libertas_tf: header file"), even though they share several structure definitions. Add the missing annotations which commit 642a57475b30 ("libertas_tf: Use struct_group() for memcpy() region") exposed. Quoting the prior libertas fix: "Data structures that come over the wire from the WLAN firmware must be packed." Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-mm/202111302102.apaePz2J-lkp@intel.com Fixes: 642a57475b30 ("libertas_tf: Use struct_group() for memcpy() region") Fixes: 7670e62c7ed6 ("libertas_tf: header file") Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211201173234.578124-3-keescook@chromium.org
2021-12-08libertas: Add missing __packed annotation with struct_group()Kees Cook1-1/+1
Build testing of the newly added struct_group() usage missed smaller architecture width tests for changes to pahole output. Add the missed __packed annotation with struct_group() usage in a __packed struct. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-mm/202111302102.apaePz2J-lkp@intel.com Fixes: 5fd32ae0433a ("libertas: Use struct_group() for memcpy() region") Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211201173234.578124-2-keescook@chromium.org
2021-12-08mwifiex: Fix possible ABBA deadlockBrian Norris1-2/+6
Quoting Jia-Ju Bai <baijiaju1990@gmail.com>: mwifiex_dequeue_tx_packet() spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 1432 (Lock A) mwifiex_send_addba() spin_lock_bh(&priv->sta_list_spinlock); --> Line 608 (Lock B) mwifiex_process_sta_tx_pause() spin_lock_bh(&priv->sta_list_spinlock); --> Line 398 (Lock B) mwifiex_update_ralist_tx_pause() spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 941 (Lock A) Similar report for mwifiex_process_uap_tx_pause(). While the locking expectations in this driver are a bit unclear, the Fixed commit only intended to protect the sta_ptr, so we can drop the lock as soon as we're done with it. IIUC, this deadlock cannot actually happen, because command event processing (which calls mwifiex_process_sta_tx_pause()) is sequentialized with TX packet processing (e.g., mwifiex_dequeue_tx_packet()) via the main loop (mwifiex_main_process()). But it's good not to leave this potential issue lurking. Fixes: f0f7c2275fb9 ("mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c") Cc: Douglas Anderson <dianders@chromium.org> Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Link: https://lore.kernel.org/linux-wireless/0e495b14-efbb-e0da-37bd-af6bd677ee2c@gmail.com/ Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YaV0pllJ5p/EuUat@google.com
2021-11-29mwl8k: Use named struct for memcpy() regionKees Cook1-4/+6
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 <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211119004905.2348143-1-keescook@chromium.org
2021-11-29libertas_tf: Use struct_group() for memcpy() regionKees Cook2-5/+8
In preparation for FORTIFY_SOURCE performing compile-time and run-time field array bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use struct_group() in struct txpd around members tx_dest_addr_high and tx_dest_addr_low 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 tx_dest_addr_high. "pahole" shows no size nor member offset changes to struct txpd. "objdump -d" shows no object code changes. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211118184121.1283821-1-keescook@chromium.org
2021-11-29libertas: Use struct_group() for memcpy() regionKees Cook2-6/+9
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 struct_group() in struct txpd around members tx_dest_addr_high and tx_dest_addr_low 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 queue_id. "pahole" shows no size nor member offset changes to struct txpd. "objdump -d" shows no object code changes. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211118184104.1283637-1-keescook@chromium.org
2021-11-26mwifiex: Ignore BTCOEX events from the 88W8897 firmwareJonas Dreßler3-0/+8
The firmware of the 88W8897 PCIe+USB card sends those events very unreliably, sometimes bluetooth together with 2.4ghz-wifi is used and no COEX event comes in, and sometimes bluetooth is disabled but the coexistance mode doesn't get disabled. This means we sometimes end up capping the rx/tx window size while bluetooth is not enabled anymore, artifically limiting wifi speeds even though bluetooth is not being used. Since we can't fix the firmware, let's just ignore those events on the 88W8897 device. From some Wireshark capture sessions it seems that the Windows driver also doesn't change the rx/tx window sizes when bluetooth gets enabled or disabled, so this is fairly consistent with the Windows driver. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211103205827.14559-1-verdre@v0yd.nl
2021-11-26mwifiex: Ensure the version string from the firmware is 0-terminatedJonas Dreßler1-0/+3
We assume at a few places that priv->version_str is 0-terminated, but right now we trust the firmware that this is the case with the version string we get from it. Let's rather ensure this ourselves and replace the last character with '\0'. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211103201800.13531-4-verdre@v0yd.nl
2021-11-26mwifiex: Add quirk to disable deep sleep with certain hardware revisionJonas Dreßler3-0/+39
The 88W8897 PCIe+USB card in the hardware revision 20 apparently has a hardware issue where the card wakes up from deep sleep randomly and very often, somewhat depending on the card activity, maybe the hardware has a floating wakeup pin or something. This was found by comparing two MS Surface Book 2 devices, where one devices wifi card experienced spurious wakeups, while the other one didn't. Those continuous wakeups prevent the card from entering host sleep when the computer suspends. And because the host won't answer to events from the card anymore while it's suspended, the firmwares internal power saving state machine seems to get confused and the card can't sleep anymore at all after that. Since we can't work around that hardware bug in the firmware, let's get the hardware revision string from the firmware and match it with known bad revisions. Then disable auto deep sleep for those revisions, which makes sure we no longer get those spurious wakeups. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211103201800.13531-3-verdre@v0yd.nl
2021-11-26mwifiex: Use a define for firmware version string lengthJonas Dreßler3-4/+7
Since the version string we get from the firmware is always 128 characters long, use a define for this size instead of having the number 128 copied all over the place. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211103201800.13531-2-verdre@v0yd.nl
2021-11-26mwifiex: Fix skb_over_panic in mwifiex_usb_recv()Zekun Shen1-1/+2
Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic. The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input. Attached is the panic report from fuzzing. skbuff: skb_over_panic: text:000000003bf1b5fa len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev:<NULL> kernel BUG at net/core/skbuff.c:109! invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: <IRQ> ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 </IRQ> Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/YX4CqjfRcTa6bVL+@Zekuns-MBP-16.fios-router.home
2021-11-17net: annotate accesses to queue->trans_startEric Dumazet1-1/+1
In following patches, dev_watchdog() will no longer stop all queues. It will read queue->trans_start locklessly. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-28mwifiex: fix division by zero in fw download pathJohan Hovold1-0/+16
Add the missing endpoint sanity checks to probe() to avoid division by zero in mwifiex_write_data_sync() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Only add checks for the firmware-download boot stage, which require both command endpoints, for now. The driver looks like it will handle a missing endpoint during normal operation without oopsing, albeit not very gracefully as it will try to submit URBs to the default pipe and fail. Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset") Cc: stable@vger.kernel.org # 3.5 Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027080819.6675-4-johan@kernel.org
2021-10-27libertas: replace snprintf in show functions with sysfs_emitYe Guojin1-9/+9
coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211022090438.1065286-1-ye.guojin@zte.com.cn
2021-10-27libertas: Fix possible memory leak in probe and disconnectWang Hai1-0/+2
I got memory leak as follows when doing fault injection test: unreferenced object 0xffff88812c7d7400 (size 512): comm "kworker/6:1", pid 176, jiffies 4295003332 (age 822.830s) hex dump (first 32 bytes): 00 68 1e 04 81 88 ff ff 01 00 00 00 00 00 00 00 .h.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490 [<ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470 [<ffffffffa02c9873>] if_usb_probe+0x63/0x446 [usb8xxx] [<ffffffffa022668a>] usb_probe_interface+0x1aa/0x3c0 [usbcore] [<ffffffff82b59630>] really_probe+0x190/0x480 [<ffffffff82b59a19>] __driver_probe_device+0xf9/0x180 [<ffffffff82b59af3>] driver_probe_device+0x53/0x130 [<ffffffff82b5a075>] __device_attach_driver+0x105/0x130 [<ffffffff82b55949>] bus_for_each_drv+0x129/0x190 [<ffffffff82b593c9>] __device_attach+0x1c9/0x270 [<ffffffff82b5a250>] device_initial_probe+0x20/0x30 [<ffffffff82b579c2>] bus_probe_device+0x142/0x160 [<ffffffff82b52e49>] device_add+0x829/0x1300 [<ffffffffa02229b1>] usb_set_configuration+0xb01/0xcc0 [usbcore] [<ffffffffa0235c4e>] usb_generic_driver_probe+0x6e/0x90 [usbcore] [<ffffffffa022641f>] usb_probe_device+0x6f/0x130 [usbcore] cardp is missing being freed in the error handling path of the probe and the path of the disconnect, which will cause memory leak. This patch adds the missing kfree(). Fixes: 876c9d3aeb98 ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211020120345.2016045-3-wanghai38@huawei.com
2021-10-27libertas_tf: Fix possible memory leak in probe and disconnectWang Hai1-0/+2
I got memory leak as follows when doing fault injection test: unreferenced object 0xffff88810a2ddc00 (size 512): comm "kworker/6:1", pid 176, jiffies 4295009893 (age 757.220s) hex dump (first 32 bytes): 00 50 05 18 81 88 ff ff 00 00 00 00 00 00 00 00 .P.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490 [<ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470 [<ffffffffa02a1530>] if_usb_probe+0x60/0x37c [libertas_tf_usb] [<ffffffffa022668a>] usb_probe_interface+0x1aa/0x3c0 [usbcore] [<ffffffff82b59630>] really_probe+0x190/0x480 [<ffffffff82b59a19>] __driver_probe_device+0xf9/0x180 [<ffffffff82b59af3>] driver_probe_device+0x53/0x130 [<ffffffff82b5a075>] __device_attach_driver+0x105/0x130 [<ffffffff82b55949>] bus_for_each_drv+0x129/0x190 [<ffffffff82b593c9>] __device_attach+0x1c9/0x270 [<ffffffff82b5a250>] device_initial_probe+0x20/0x30 [<ffffffff82b579c2>] bus_probe_device+0x142/0x160 [<ffffffff82b52e49>] device_add+0x829/0x1300 [<ffffffffa02229b1>] usb_set_configuration+0xb01/0xcc0 [usbcore] [<ffffffffa0235c4e>] usb_generic_driver_probe+0x6e/0x90 [usbcore] [<ffffffffa022641f>] usb_probe_device+0x6f/0x130 [usbcore] cardp is missing being freed in the error handling path of the probe and the path of the disconnect, which will cause memory leak. This patch adds the missing kfree(). Fixes: c305a19a0d0a ("libertas_tf: usb specific functions") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211020120345.2016045-2-wanghai38@huawei.com
2021-10-20wireless: use eth_hw_addr_set() instead of ether_addr_copy()Jakub Kicinski1-1/+1
Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Convert wireless from ether_addr_copy() to eth_hw_addr_set(): @@ expression dev, np; @@ - ether_addr_copy(dev->dev_addr, np) + eth_hw_addr_set(dev, np) Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-3-kuba@kernel.org
2021-10-20wireless: use eth_hw_addr_set()Jakub Kicinski3-7/+5
Convert all WiFi drivers from memcpy(... ETH_ADDR) to eth_hw_addr_set(): @@ expression dev, np; @@ - memcpy(dev->dev_addr, np, ETH_ALEN) + eth_hw_addr_set(dev, np) Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018235021.1279697-2-kuba@kernel.org
2021-10-20mwifiex: Deactive host sleep using HSCFG after it was activated manuallyJonas Dreßler4-0/+44
When powersaving (so either wifi powersaving or deep sleep, depending on which state the firmware is in) is disabled, the way the firmware goes into host sleep is different: Usually the firmware implicitely enters host sleep on the next SLEEP event we get when we configured host sleep via HSCFG before. When powersaving is disabled though, there are no SLEEP events, the way we enter host sleep in that case is different: The firmware will send us a HS_ACT_REQ event and after that we "manually" make the firmware enter host sleep by sending it another HSCFG command with the action HS_ACTIVATE. Now waking up from host sleep appears to be different depending on whether powersaving is enabled again: When powersaving is enabled, the firmware implicitely leaves host sleep as soon as it wakes up and sends us an AWAKE event. When powersaving is disabled though, it apparently doesn't implicitely leave host sleep, but instead we need to send it a HSCFG command with the HS_CONFIGURE action and the HS_CFG_CANCEL condition. We didn't do that so far, which is why waking up from host sleep was broken when powersaving is disabled. So add some additional state to mwifiex_adapter where we keep track of whether host sleep was activated manually via HS_ACTIVATE, and if that was the case, deactivate it manually again via HS_CFG_CANCEL. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-6-verdre@v0yd.nl
2021-10-20mwifiex: Send DELBA requests according to specJonas Dreßler1-2/+3
While looking at on-air packets using Wireshark, I noticed we're never setting the initiator bit when sending DELBA requests to the AP: While we set the bit on our del_ba_param_set bitmask, we forget to actually copy that bitmask over to the command struct, which means we never actually set the initiator bit. Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command struct. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Acked-by: Pali Rohár <pali@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl
2021-10-20mwifiex: Fix an incorrect commentJonas Dreßler1-1/+1
We're sending DELBA requests here, not ADDBA requests. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-4-verdre@v0yd.nl
2021-10-20mwifiex: Log an error on command failure during key-material uploadJonas Dreßler1-2/+8
Sometimes the KEY_MATERIAL command can fail with the 88W8897 firmware (when this happens exactly seems pretty random). This appears to prevent the access point from starting, so it seems like a good idea to log an error in that case. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-3-verdre@v0yd.nl
2021-10-20mwifiex: Don't log error on suspend if wake-on-wlan is disabledJonas Dreßler1-1/+1
It's not an error if someone chooses to put their computer to sleep, not wanting it to wake up because the person next door has just discovered what a magic packet is. So change the loglevel of this annoying message from ERROR to INFO. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211016153244.24353-2-verdre@v0yd.nl
2021-10-20mwl8k: Fix use-after-free in mwl8k_fw_state_machine()Zheyu Ma1-1/+1
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 <zheyuma97@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634356979-6211-1-git-send-email-zheyuma97@gmail.com
2021-10-18mwifiex: Try waking the firmware until we get an interruptJonas Dreßler1-5/+23
It seems that the PCIe+USB firmware (latest version 15.68.19.p21) of the 88W8897 card sometimes ignores or misses when we try to wake it up by writing to the firmware status register. This leads to the firmware wakeup timeout expiring and the driver resetting the card because we assume the firmware has hung up or crashed. Turns out that the firmware actually didn't hang up, but simply "missed" our wakeup request and didn't send us an interrupt with an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake up as expected, so add a small retry loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to check whether the card woke up. The number of tries and timeout lengths for this were determined experimentally: The firmware usually takes about 500 us to wake up after we attempt to read the status register. In some cases where the firmware is very busy (for example while doing a bluetooth scan) it might even miss our requests for multiple milliseconds, which is why after 15 tries the waiting time gets increased to 10 ms. The maximum number of tries it took to wake the firmware when testing this was around 20, so a maximum number of 50 tries should give us plenty of safety margin. Here's a reproducer for those firmware wakeup failures I've found: 1) Make sure wifi powersaving is enabled (iw dev wlp1s0 set power_save on) 2) Connect to any wifi network (makes firmware go into wifi powersaving mode, not deep sleep) 3) Make sure bluetooth is turned off (to ensure the firmware actually enters powersave mode and doesn't keep the radio active doing bluetooth stuff) 4) To confirm that wifi powersaving is entered ping a device on the LAN, pings should be a few ms higher than without powersaving 5) Run "while true; do iwconfig; sleep 0.0001; done", this wakes and suspends the firmware extremely often 6) Wait until things explode, for me it consistently takes <5 minutes BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011133224.15561-3-verdre@v0yd.nl
2021-10-18mwifiex: Read a PCI register after writing the TX ring write pointerJonas Dreßler1-0/+8
On the 88W8897 PCIe+USB card the firmware randomly crashes after setting the TX ring write pointer. The issue is present in the latest firmware version 15.68.19.p21 of the PCIe+USB card. Those firmware crashes can be worked around by reading any PCI register of the card after setting that register, so read the PCI_VENDOR_ID register here. The reason this works is probably because we keep the bus from entering an ASPM state for a bit longer, because that's what causes the cards firmware to crash. This fixes a bug where during RX/TX traffic and with ASPM L1 substates enabled (the specific substates where the issue happens appear to be platform dependent), the firmware crashes and eventually a command timeout appears in the logs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011133224.15561-2-verdre@v0yd.nl
2021-10-13wireless: Remove redundant 'flush_workqueue()' callsChristophe JAILLET2-4/+0
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/0855d51423578ad019c0264dad3fe47a2e8af9c7.1633849511.git.christophe.jaillet@wanadoo.fr
2021-10-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2-4/+4
No conflicts. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-09-28mwifiex: avoid null-pointer-subtraction warningArnd Bergmann2-4/+4
clang complains about some NULL pointer arithmetic in this driver: drivers/net/wireless/marvell/mwifiex/sta_tx.c:65:59: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] pad = ((void *)skb->data - (sizeof(*local_tx_pd) + hroom)- ^ drivers/net/wireless/marvell/mwifiex/uap_txrx.c:478:53: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] pad = ((void *)skb->data - (sizeof(*txpd) + hroom) - NULL) & Rework that expression to do the same thing using a uintptr_t. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210927121656.940304-1-arnd@kernel.org
2021-09-21mwifiex: Fix copy-paste mistake when creating virtual interfaceJonas Dreßler1-1/+1
The BSS priority here for a new P2P_CLIENT device was accidentally set to an enum that's certainly not meant for this. Since MWIFIEX_BSS_ROLE_STA is 0 anyway, we can just set the bss_priority to 0 instead here. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-10-verdre@v0yd.nl
2021-09-21mwifiex: Properly initialize private structure on interface type changesJonas Dreßler1-3/+7
When creating a new virtual interface in mwifiex_add_virtual_intf(), we update our internal driver states like bss_type, bss_priority, bss_role and bss_mode to reflect the mode the firmware will be set to. When switching virtual interface mode using mwifiex_init_new_priv_params() though, we currently only update bss_mode and bss_role. In order for the interface mode switch to actually work, we also need to update bss_type to its proper value, so do that. This fixes a crash of the firmware (because the driver tries to execute commands that are invalid in AP mode) when switching from station mode to AP mode. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-9-verdre@v0yd.nl
2021-09-21mwifiex: Handle interface type changes from AP to STATIONJonas Dreßler1-0/+1
Looks like this case was simply overseen, so handle it, too. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-8-verdre@v0yd.nl
2021-09-21mwifiex: Allow switching interface type from P2P_CLIENT to P2P_GOJonas Dreßler1-0/+36
It's possible to change virtual interface type between P2P_CLIENT and P2P_GO, the card supports that just fine, and it happens for example when using miracast with the miraclecast software. So allow type changes between P2P_CLIENT and P2P_GO and simply call into mwifiex_change_vif_to_p2p(), which handles this just fine. We have to call mwifiex_cfg80211_deinit_p2p() before though to make sure the old p2p mode is properly uninitialized. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-7-verdre@v0yd.nl
2021-09-21mwifiex: Update virtual interface counters right after setting bss_typeJonas Dreßler1-11/+14
In mwifiex_init_new_priv_params() we update our private driver state to reflect the currently selected virtual interface type. Most notably we set the bss_mode to the mode we're going to put the firmware in. Now after we updated the driver state we actually start talking to the firmware and instruct it to set up the new mode. Those commands can and will sometimes fail, in which case we return with an error from mwifiex_change_vif_to_*. We currently update our virtual interface type counters after this return, which means the code is never reached when a firmware error happens and we never update the counters. Since we have updated our bss_mode earlier though, the counters now no longer reflect the actual state of the driver. This will break things on the next virtual interface change, because the virtual interface type we're switching away from didn't get its counter incremented, and we end up decrementing a 0-counter. To fix this, simply update the virtual interface type counters right after updating our driver structures, so that they are always in sync. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-6-verdre@v0yd.nl
2021-09-21mwifiex: Use helper function for counting interface typesJonas Dreßler1-75/+35
Use a small helper function to increment and decrement the counter of the interface types we currently manage. This makes the code that actually changes and sets up the interface type a bit less messy and also helps avoiding mistakes in case someone increments/decrements a counter wrongly. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-5-verdre@v0yd.nl
2021-09-21mwifiex: Run SET_BSS_MODE when changing from P2P to STATION vif-typeJonas Dreßler1-18/+4
We currently handle changing from the P2P to the STATION virtual interface type slightly different than changing from P2P to ADHOC: When changing to STATION, we don't send the SET_BSS_MODE command. We do send that command on all other type-changes though, and it probably makes sense to send the command since after all we just changed our BSS_MODE. Looking at prior changes to this part of the code, it seems that this is simply a leftover from old refactorings. Since sending the SET_BSS_MODE command is the only difference between mwifiex_change_vif_to_sta_adhoc() and the current code, we can now use mwifiex_change_vif_to_sta_adhoc() for both switching to ADHOC and STATION interface type. This does not fix any particular bug and just "looked right", so there's a small chance it might be a regression. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-4-verdre@v0yd.nl
2021-09-21mwifiex: Use function to check whether interface type change is allowedJonas Dreßler1-47/+92
Instead of bailing out in the function which is supposed to do the type change, detect invalid changes beforehand using a generic function and return an error if the change is not allowed. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-3-verdre@v0yd.nl
2021-09-21mwifiex: Small cleanup for handling virtual interface type changesJonas Dreßler1-25/+14
Handle the obvious invalid virtual interface type changes with a general check instead of looking at the individual change. For type changes from P2P_CLIENT to P2P_GO and the other way round, this changes the behavior slightly: We now still do nothing, but return -EOPNOTSUPP instead of 0. Now that behavior was incorrect before and still is, because type changes between these two types are actually possible and supported, which we'll fix in a following commit. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-2-verdre@v0yd.nl
2021-08-29mwifiex: pcie: add reset_d3cold quirk for Surface gen4+ devicesTsuchiya Yuto3-0/+133
To reset mwifiex on Surface gen4+ (Pro 4 or later gen) devices, it seems that putting the wifi device into D3cold is required according to errata.inf file on Windows installation (Windows/INF/errata.inf). This patch adds a function that performs power-cycle (put into D3cold then D0) and call the function at the end of reset_prepare(). Note: Need to also reset the parent device (bridge) of wifi on SB1; it might be because the bridge of wifi always reports it's in D3hot. When I tried to reset only the wifi device (not touching parent), it gave the following error and the reset failed: acpi device:4b: Cannot transition to power state D0 for parent in D3hot mwifiex_pcie 0000:03:00.0: can't change power state from D3cold to D0 (config space inaccessible) Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210820142050.35741-3-verdre@v0yd.nl
2021-08-29mwifiex: pcie: add DMI-based quirk implementation for Surface devicesJonas Dreßler5-0/+64
This commit adds the ability to apply device-specific quirks to the mwifiex driver. It uses DMI matching similar to the quirks brcmfmac uses with dmi.c. We'll add identifiers to match various MS Surface devices, which this is primarily meant for, later. This commit is a slightly modified version of a previous patch sent in by Tsuchiya Yuto. Co-developed-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210820142050.35741-2-verdre@v0yd.nl
2021-08-21mwifiex: make arrays static const, makes object smallerColin Ian King1-2/+2
Don't populate the arrays wpa_oui and wps_oui on the stack but instead them static const. Makes the object code smaller by 63 bytes: Before: text data bss dec hex filename 29453 5451 64 34968 8898 .../wireless/marvell/mwifiex/sta_ioctl.o After: text data bss dec hex filename 29356 5611 64 35031 88d7 ../wireless/marvell/mwifiex/sta_ioctl.o (gcc version 10.3.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210819121651.7566-1-colin.king@canonical.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-20 13:13:14 +0000