summaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2021-12-07iwlwifi: mvm: support RLC configuration commandJohannes Berg4-7/+123
There's an RLC configuration command in the firmware that's going to replace the chain information in the PHY context. Add support for this command, while leaving the PHY context fields unset when we know the RLC command will be used. Also add support to send only the RLC configuration command if only the # of chains used on the PHY context changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.55faa3782bb0.I3f9d0071e680cab513c59b093d0827af99d41c51@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: d3: support v12 wowlan statusJohannes Berg2-29/+235
Newer firmware versions are going to come with a new version of the wowlan status API, which gives us replay counters for both GTKs that might still be in use, as well as unifying the layout of the counters to just be 64-bit quantities. Extend our code to handle this case and be able to install replay counters for both keys, if they're sent up from the firmware. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.73637acafe0b.I33e27712a12fff2816edc0a8abda1759259e20d7@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: parse firmware alive message version 6Johannes Berg3-4/+21
There's a new version with some addition, we'll need to do something with the additional data later, but for now just parse it so we don't fail with the newer firmware. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.f856cb190a4e.I77e3ff5a92b1bcc3e81c1344b046dade0a8b6a24@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: pcie: support Bz suspend/resume triggerHaim Dreyfuss3-34/+52
Instead of using two bits in the doorbell interrupt, the new Bz devices have a new CSR_IPC_SLEEP_CONTROL register to let drivers indicate the desired transition before triggering the doorbell interrupt. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.63f3d150689a.Iaeb6f9b007e81b1a5a02144b0281935e4613cb78@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: d3: move GTK rekeys conditionJohannes Berg1-4/+9
Move the GTK rekeying condition into iwl_mvm_set_key_rx_seq() so we can modify it in the next patch. In the next firmware API revision we'll properly get data for both active GTKs and will have to install it accordingly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.f309942ddd15.Iaa95c602f3a681dd464e10ce2de047aa86fac19c@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: add support for Bz-Z HWMike Golant4-0/+19
Add support for Bz Z step HW with GF RF. Signed-off-by: Mike Golant <michael.golant@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.fc8626515758.Ibfeffc8bb071f9773ea189992ebef056f51be1be@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: support 4-bits in MAC step valueMike Golant9-29/+22
We have a MAC component (which is inside the SoC) and it has several different HW steps. 3 bits used to be enough but now we need 4-bits to represent all the different steps. Properly support 4-bits in the MAC step value by refactoring all the current handling of the MAC step/dash. Already from family 8000 and up the dash (bits 0-1) no longer exists and the step (until 8000 bits 2-3) consists of the dash bits as well. To do this remove the CSR_HW_REV_STEP and the CSR_HW_REV_DASH macros, replace them with CSR_HW_REV_STEP_DASH and add hw_rev_step into the trans struct. In addition remove the CSR_HW_IF_CONFIG_REG_MSK_MAC_STEP and CSR_HW_IF_CONFIG_REG_MSK_MAC_DASH macros and create a new macro combining the 2 (this way we don't need shifting or anything else.) Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: Mike Golant <michael.golant@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211207160459.2e81a14d1f80.Ia5287e37fb3439d805336837361f6491f958e465@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: synchronize with FW after multicast commandsJohannes Berg1-0/+17
If userspace installs a lot of multicast groups very quickly, then we may run out of command queue space as we send the updates in an asynchronous fashion (due to locking concerns), and the CPU can create them faster than the firmware can process them. This is true even when mac80211 has a work struct that gets scheduled. Fix this by synchronizing with the firmware after sending all those commands - outside of the iteration we can send a synchronous echo command that just has the effect of the CPU waiting for the prior asynchronous commands to finish. This also will cause fewer of the commands to be sent to the firmware overall, because the work will only run once when rescheduled multiple times while it's running. Link: https://bugzilla.kernel.org/show_bug.cgi?id=213649 Suggested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reported-by: Maximilian Ernestus <maximilian@ernestus.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083238.51aea5b79ea4.I88a44798efda16e9fe480fb3e94224931d311b29@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: fix delBA vs. NSSN queue sync raceJohannes Berg2-1/+14
If we happen to decide an NSSN queue sync (IWL_MVM_RXQ_NSSN_SYNC) for some remaining packets that are still on the queue, but just after we've decided to do a delBA (which causes its own queues sync with IWL_MVM_RXQ_NOTIF_DEL_BA) we can end up with a sequence of events like this: CPU 1 CPU 2 remove BA session with baid N send IWL_MVM_RXQ_NOTIF_DEL_BA send IWL_MVM_RXQ_NSSN_SYNC get IWL_MVM_RXQ_NOTIF_DEL_BA get IWL_MVM_RXQ_NOTIF_DEL_BA get IWL_MVM_RXQ_NSSN_SYNC complete IWL_MVM_RXQ_NOTIF_DEL_BA remove N from baid_map[] get IWL_MVM_RXQ_NSSN_SYNC WARN_ON(!baid_map[N]) Thus, there's a race that leads in hitting the WARN_ON, but more importantly, it's a race that potentially even results in a new aggregation session getting assigned to baid N. To fix this, remove the WARN_ON() in the NSSN_SYNC case, we can't completely protect against hitting this case, so we shouldn't be warning. However, guard ourselves against BAID reuse by doing yet another round of queue synchronization after the entry is removed from the baid_map, so that it cannot be reused with any in-flight IWL_MVM_RXQ_NSSN_SYNC messages. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20211204083237.44abbbc50f40.I5492600dfe513356555abe2d7df0e2835846e3d8@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: demote non-compliant kernel-doc headerYang Shen1-1/+1
Fixes the following W=1 kernel build warning: drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:11: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> [removed the static const fix, since it's already done and updated the commit message accordingly.] Link: https://lore.kernel.org/r/20210517050141.61488-7-shenyang39@huawei.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07wireless: iwlwifi: Fix a double free in iwl_txq_dyn_alloc_dmaLv Yunlong1-0/+1
In iwl_txq_dyn_alloc_dma, txq->tfds is freed at first time by: iwl_txq_alloc()->goto err_free_tfds->dma_free_coherent(). But it forgot to set txq->tfds to NULL. Then the txq->tfds is freed again in iwl_txq_dyn_alloc_dma by: goto error->iwl_txq_gen2_free_memory()->dma_free_coherent(). My patch sets txq->tfds to NULL after the first free to avoid the double free. Fixes: 0cd1ad2d7fd41 ("iwlwifi: move all bus-independent TX functions to common code") Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Link: https://lore.kernel.org/r/20210403054755.4781-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mvm: fix a possible NULL pointer deferenceEmmanuel Grumbach2-5/+8
Smatch spot a possible NULL pointer dereference. Fix it. __iwl_mvm_mac_set_key can be called with sta = NULL Also add a NULL pointer check after memory allocation. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20211130105951.85539-1-emmanuel.grumbach@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mei: Fix spelling mistake "req_ownserhip" -> "req_ownership"Colin Ian King1-1/+1
There is a spelling mistake in a debugfs filename. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211129124921.11817-1-colin.i.king@gmail.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-07iwlwifi: mei: don't rely on the size from the shared areaEmmanuel Grumbach1-9/+17
If CSME is compromised, it could report a bigger queue size in the share area and make the host perform an out of bound access. Instead of reading the size of the queue from the shared area, store it in the regular context which is not accessible by CSME. While at it, fix a small typo in an error print. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20211128121509.3952-1-emmanuel.grumbach@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2021-12-05iwlwifi: mei: fix linking when tracing is not enabledEmmanuel Grumbach2-0/+27
I forgot to add stubs in case tracing is disabled which caused linking errors: ERROR: modpost: "__SCT__tp_func_iwlmei_sap_data" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__SCT__tp_func_iwlmei_me_msg" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__tracepoint_iwlmei_sap_cmd" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__tracepoint_iwlmei_me_msg" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__SCK__tp_func_iwlmei_me_msg" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__SCK__tp_func_iwlmei_sap_data" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__tracepoint_iwlmei_sap_data" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__SCT__tp_func_iwlmei_sap_cmd" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! ERROR: modpost: "__SCK__tp_func_iwlmei_sap_cmd" [drivers/net/wireless/intel/iwlwifi/mei/iwlmei.ko] undefined! Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Acked-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211201113411.130409-1-emmanuel.grumbach@intel.com
2021-11-29rtlwifi: rtl8192de: Style clean-upsKees Cook2-11/+7
Clean up some style issues: - Use ARRAY_SIZE() even though it's a u8 array. - Remove redundant CHANNEL_MAX_NUMBER_2G define. Additionally fix some dead code WARNs. Acked-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/lkml/57d0d1b6064342309f680f692192556c@realtek.com/ Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211119192233.1021063-1-keescook@chromium.org
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-29intersil: Use struct_group() for memcpy() regionKees Cook2-8/+11
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 hfa384x_tx_frame around members frame_control, duration_id, addr1, addr2, addr3, and seq_ctrl, 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 frame_control. "pahole" shows no size nor member offset changes to struct hfa384x_tx_frame. "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/20211119004646.2347920-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-29wlcore: no need to initialise statics to falseJason Wang1-1/+1
Static variables do not need to be initialized to false. The compiler will do that. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211113063551.257804-1-wangborong@cdjrlc.com
2021-11-29rsi: Fix out-of-bounds read in rsi_read_pkt()Zekun Shen3-1/+6
rsi_get_* functions rely on an offset variable from usb input. The size of usb input is RSI_MAX_RX_USB_PKT_SIZE(3000), while 2-byte offset can be up to 0xFFFF. Thus a large offset can cause out-of-bounds read. The patch adds a bound checking condition when rcv_pkt_len is 0, indicating it's USB. It's unclear whether this is triggerable from other type of bus. The following check might help in that case. offset > rcv_pkt_len - FRAME_DESC_SZ The bug is trigerrable with conpromised/malfunctioning USB devices. I tested the patch with the crashing input and got no more bug report. Attached is the KASAN report from fuzzing. BUG: KASAN: slab-out-of-bounds in rsi_read_pkt+0x42e/0x500 [rsi_91x] Read of size 2 at addr ffff888019439fdb by task RX-Thread/227 CPU: 0 PID: 227 Comm: RX-Thread Not tainted 5.6.0 #66 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? rsi_read_pkt+0x42e/0x500 [rsi_91x] ? rsi_read_pkt+0x42e/0x500 [rsi_91x] __kasan_report.cold+0x37/0x7c ? rsi_read_pkt+0x42e/0x500 [rsi_91x] kasan_report+0xe/0x20 rsi_read_pkt+0x42e/0x500 [rsi_91x] rsi_usb_rx_thread+0x1b1/0x2fc [rsi_usb] ? rsi_probe+0x16a0/0x16a0 [rsi_usb] ? _raw_spin_lock_irqsave+0x7b/0xd0 ? _raw_spin_trylock_bh+0x120/0x120 ? __wake_up_common+0x10b/0x520 ? rsi_probe+0x16a0/0x16a0 [rsi_usb] kthread+0x2b5/0x3b0 ? kthread_create_on_node+0xd0/0xd0 ret_from_fork+0x22/0x40 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/YXxXS4wgu2OsmlVv@10-18-43-117.dynapool.wireless.nyu.edu
2021-11-29rsi: Fix use-after-free in rsi_rx_done_handler()Zekun Shen1-1/+7
When freeing rx_cb->rx_skb, the pointer is not set to NULL, a later rsi_rx_done_handler call will try to read the freed address. This bug will very likley lead to double free, although detected early as use-after-free bug. The bug is triggerable with a compromised/malfunctional usb device. After applying the patch, the same input no longer triggers the use-after-free. Attached is the kasan report from fuzzing. BUG: KASAN: use-after-free in rsi_rx_done_handler+0x354/0x430 [rsi_usb] Read of size 4 at addr ffff8880188e5930 by task modprobe/231 Call Trace: <IRQ> dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] __kasan_report.cold+0x37/0x7c ? dma_direct_unmap_page+0x90/0x110 ? rsi_rx_done_handler+0x354/0x430 [rsi_usb] kasan_report+0xe/0x20 rsi_rx_done_handler+0x354/0x430 [rsi_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __usb_hcd_giveback_urb+0x380/0x380 ? apic_timer_interrupt+0xa/0x20 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 ? handle_irq_event+0xcd/0x157 ? handle_edge_irq+0x1eb/0x7b0 irq_exit+0x114/0x140 do_IRQ+0x91/0x1e0 common_interrupt+0xf/0xf </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/YXxQL/vIiYcZUu/j@10-18-43-117.dynapool.wireless.nyu.edu
2021-11-29brcmfmac: Configure keep-alive packet on suspendLoic Poulain2-0/+40
When entering suspend as a client station with wowlan enabled, the Wi-Fi link is supposed to be maintained. In that state, no more data is generated from client side, and the link stays idle as long the station is suspended and as long the AP as no data to transmit. However, most of the APs kick-off such 'inactive' stations after few minutes, causing unexpected disconnect (reconnect, etc...). The usual way to prevent this is to submit a Null function frame periodically as a keep-alive. This is something that can be host /software generated (e.g. wpa_supplicant), but that needs to be offloaded to the Wi-Fi controller in case of suspended host. This change enables firmware generated keep-alive frames when entering wowlan suspend, using the 'mkeep_alive' IOVAR. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1637596046-21651-1-git-send-email-loic.poulain@linaro.org
2021-11-26wilc1000: remove '-Wunused-but-set-variable' warning in chip_wakeup()Ajay Singh1-5/+0
Remove unused variables to avoid the below warnings: drivers/net/wireless/microchip/wilc1000/wlan.c: In function 'chip_wakeup': >> drivers/net/wireless/microchip/wilc1000/wlan.c:620:34: warning: variable 'to_host_from_fw_bit' set but not used [-Wunused-but-set-variable] 620 | u32 to_host_from_fw_reg, to_host_from_fw_bit; | ^~~~~~~~~~~~~~~~~~~ >> drivers/net/wireless/microchip/wilc1000/wlan.c:620:13: warning: variable 'to_host_from_fw_reg' set but not used [-Wunused-but-set-variable] 620 | u32 to_host_from_fw_reg, to_host_from_fw_bit; | ^~~~~~~~~~~~~~~~~~~ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211115102809.1408267-1-ajay.kathat@microchip.com
2021-11-26iwlwifi: mvm: read the rfkill state and feed it to iwlmeiEmmanuel Grumbach3-2/+13
Read the rfkill state upon boot, mac start and mac stop. Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211112062814.7502-6-emmanuel.grumbach@intel.com
2021-11-26iwlwifi: mvm: add vendor commands needed for iwlmeiEmmanuel Grumbach4-6/+168
Add the vendor commands that must be used by the network manager to allow proper operation of iwlmei. * Send information on the AP CSME is connected to * Notify the userspace when roaming is forbidden * Allow the userspace to require ownership Co-Developed-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> v6: remove the VENDOR_CMDS Kconfig option and make the whole infra depend on IWLMEI directly v7: remove // comments remove an unneeded function Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211112062814.7502-5-emmanuel.grumbach@intel.com
2021-11-26iwlwifi: integrate with iwlmeiEmmanuel Grumbach11-29/+481
iwlmei needs to know about the follwing events: * Association * De-association * Country Code change * SW Rfkill change * SAR table changes iwlmei can take the device away from us, so report the new rfkill type when this happens. Advertise the required data from the CSME firmware to the usersapce: mostly, the AP that the CSME firmware is currently associated to in case there is an active link protection session. Generate the HOST_ASSOC / HOST_DISSASSOC messages. Don't support WPA1 (non-RSNA) for now. Don't support shared wep either. We can then determine the AUTH parameter by checking the AKM. Feed the cipher from the key installation. SW Rfkill will be implemented later when cfg80211 will allow us to read the SW Rfkill state. Co-Developed-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> v7: Ayala added her signed-off remove pointless function declaration fix a bug due to merge conflict in the HOST_ASSOC message v8: leave a print if we have a SAP connection on a device we do not support (yet) Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211112062814.7502-4-emmanuel.grumbach@intel.com
2021-11-26iwlwifi: mei: add debugfs hooksEmmanuel Grumbach1-2/+83
Add three debugfs hooks: * status: Check if we have a connection with the CSME firwmare. This hook is a read only. * req_ownership: Send a SAP command to request ownership. This flow should be triggered by iwlwifi (from user space through vendor commands really), but being able to trigger an ownership request from debugfs allows us to request ownership without connecting afterwards. This is an "error" flow that the CSME firmware is designed to handle this way: + Grant ownership since the host asked for it + Wait 3 seconds to let the host connect + If the host didn't connect, take the device back (forcefully). + Don't grant any new ownership request in the following 30 seconds. This debugfs hook allows us to test this flow. * send_start_message: Restart the communication with the CSME firmware from the very beginning. At the very beginning (upon iwlwifi start), iwlmei send a special message: SAP_ME_MSG_START. This hook allows to send it again and this will retrigger the whole flow. It is important to test this restart in the middle of normal operation since it can happen (in case the CSME firmware decided to reset for example). Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211112062814.7502-3-emmanuel.grumbach@intel.com
2021-11-26iwlwifi: mei: add the driver to allow cooperation with CSMEEmmanuel Grumbach11-0/+3749
CSME in two words ----------------- CSME stands for Converged Security and Management Engine. It is a CPU on the chipset and runs a dedicated firmware. AMT (Active Management Technology) is one of the applications that run on that CPU. AMT allows to control the platform remotely. Here is a partial list of the use cases: * View the screen of the plaform, with keyboard and mouse (KVM) * Attach a remote IDE device * Have a serial console to the device * Query the state of the platform * Reset / shut down / boot the platform Networking in CSME ------------------ For those uses cases, CSME's firmware has an embedded network stack and is able to use the network devices of the system: LAN and WLAN. This is thanks to the CSME's firmware WLAN driver. One can add a profile (SSID / key / certificate) to the CSME's OS and CSME will connect to that profile. Then, one can use the WLAN link to access the applications that run on CSME (AMT is one of them). Note that CSME is active during power state and power state transitions. For example, it is possible to have a KVM session open to the system while the system is rebooting and actually configure the BIOS remotely over WLAN thanks to AMT. How all this is related to Linux -------------------------------- In Linux, there is a driver that allows the OS to talk to the CSME firmware, this driver is drivers/misc/mei. This driver advertises a bus that allows other kernel drivers or even user space) to talk to components inside the CSME firmware. In practice, the system advertises a PCI device that allows to send / receive data to / from the CSME firmware. The mei bus drivers in drivers/misc/mei is an abstration on top of this PCI device. The driver being added here is called iwlmei and talks to the WLAN driver inside the CSME firmware through the mei bus driver. Note that the mei bus driver only gives bus services, it doesn't define the content of the communication. Why do we need this driver? -------------------------- CSME uses the same WLAN device that the OS is expecting to see hence we need an arbitration mechanism. This is what iwlmei is in charge of. iwlmei maintains the communication with the CSME firmware's WLAN driver. The language / protocol that is used between the CSME's firmware WLAN driver and iwlmei is OS agnostic and is called SAP which stands for Software Abritration Protocol. With SAP, iwlmei will be able to tell the CSME firmware's WLAN driver: 1) Please give me the device. 2) Please note that the SW/HW rfkill state change. 3) Please note that I am now associated to X. 4) Please note that I received this packet. etc... There are messages that go the opposite direction as well: 1) Please note that AMT is en/disable. 2) Please note that I believe the OS is broken and hence I'll take the device *now*, whether you like it or not, to make sure that connectivity is preserved. 3) Please note that I am willing to give the device if the OS needs it. 4) Please give me any packet that is sent on UDP / TCP on IP address XX.XX.XX.XX and an port ZZ. 5) Please send this packet. etc... Please check drivers/net/wireless/intel/iwlwifi/mei/sap.h for the full protocol specification. Arbitration is not the only purpose of iwlmei and SAP. SAP also allows to maintain the AMT's functionality even when the OS owns the device. To connect to AMT, one needs to initiate an HTTP connection to port 16992. iwlmei will listen to the Rx path and forward (through SAP) to the CSME firmware the data it got. Then, the embedded HTTP server in the chipset will reply to the request and send a SAP notification to ask iwlmei to send the reply. This way, AMT running on the CSME can still work. In practice this means that all the use cases quoted above (KVM, remote IDE device, etc...) will work even when the OS uses the WLAN device. How to disable all this? --------------------------- iwlmei won't be able to do anything if the CSME's networking stack is not enabled. By default, CSME's networking stack is disabled (this is a BIOS setting). In case the CSME's networking stack is disabled, iwlwifi will just get access to the device because there is no contention with any other actor and, hence, no arbitration is needed. In this patch, I only add the iwlmei driver. Integration with iwlwifi will be implemented in the next one. Co-Developed-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> v2: fix a few warnings raised by the different bots v3: rewrite the commit message v4: put the debugfs content in a different patch v5: fix a NULL pointer dereference upon DHCP TX if SAP is connected since we now have the required cfg80211 bits in wl-drv-next, add the RFKILL handling patch to this series. v6: change the SAP API to inherit the values from iwl-mei.h removing the need to ensure the values are equal with a BUILD_BUG_ON. This was suggested by Arend v7: * fix a locking issue in case of CSME firmware reset: When the CSME firmware resets, we need to unregister the netdev, first take the mutex, and only then, rely on it being taken. * Add a comment to explain why it is ok to have static variables (iwlmei can't have more than a single instance). * Add a define for 26 + 8 + 8 * Add a define SEND_SAP_MAX_WAIT_ITERATION * make struct const * Reword a bit the Kconfig help message * Ayala added her Signed-off * fixed an RCU annotation v8: do not require ownership upfront, use NIC_OWNER instead. This fixes a deadlock when CSME does not have the right WiFi FW. Add more documentation about the owernship transition Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211112062814.7502-2-emmanuel.grumbach@intel.com
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-26rtw88: add quirk to disable pci caps on HP 250 G7 Notebook PCPing-Ke Shih1-0/+9
8821CE causes random freezes on HP 250 G7 Notebook PC. Add a quirk to disable pci ASPM capability. Reported-by: rtl8821cerfe2 <rtl8821cerfe2@protonmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211119052437.8671-1-pkshih@realtek.com
2021-11-26rtw88: add debugfs to force lowest basic rateYu-Yen Ting3-1/+42
The management frame with high rate e.g. 24M may not be transmitted smoothly in long range environment. Add a debugfs to force to use the lowest basic rate in order to debug the reachability of transmitting management frame. obtain current setting cat /sys/kernel/debug/ieee80211/phyX/rtw88/force_lowest_basic_rate force lowest rate: echo 1 > /sys/kernel/debug/ieee80211/phyX/rtw88/force_lowest_basic_rate Signed-off-by: Yu-Yen Ting <steventing@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211102022454.10944-2-pkshih@realtek.com
2021-11-26rtw88: follow the AP basic rates for tx mgmt frameYu-Yen Ting1-5/+21
By default the driver uses the 1M and 6M rate for managemnt frames in 2G and 5G bands respectively. But when the basic rates is configured from the mac80211, we need to send the management frames according to the basic rates. This commit makes the driver use the lowest basic rates to send the management frames. Signed-off-by: Yu-Yen Ting <steventing@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211102022454.10944-1-pkshih@realtek.com
2021-11-26rtw89: add AXIDMA and TX FIFO dump in mac_mem_dumpChia-Yuan Li2-0/+15
The AXIDMA is tx/rx packet transmission between PCIE host and device, and TX FIFO is MAC TX data. We dump them to verify that these memory buffers are correct. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211122021129.4339-1-pkshih@realtek.com
2021-11-26rtw89: fix potentially access out of range of RF register arrayPing-Ke Shih1-14/+19
The RF register array is used to help firmware to restore RF settings. The original code can potentially access out of range, if the size is between (RTW89_H2C_RF_PAGE_SIZE * RTW89_H2C_RF_PAGE_NUM + 1) to ((RTW89_H2C_RF_PAGE_SIZE + 1) * RTW89_H2C_RF_PAGE_NUM). Fortunately, current used size doesn't fall into the wrong case, and the size will not change if we don't update RF parameter. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211119055729.12826-1-pkshih@realtek.com
2021-11-26rtw89: remove unneeded variableChangcheng Deng1-2/+1
Fix the following coccicheck review: ./drivers/net/wireless/realtek/rtw89/mac.c: 1096: 5-8: Unneeded variable Remove unneeded variable used to store return value. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211110121135.151187-1-deng.changcheng@zte.com.cn
2021-11-26rtw89: remove unnecessary conditional operatorsYe Guojin4-5/+5
The conditional operator is unnecessary while assigning values to the bool variables. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211104061119.1685-1-ye.guojin@zte.com.cn
2021-11-26rtw89: update rtw89_regulatory map to R58-R31Zong-Zhe Yang1-187/+188
Start to configure entries with RTW89_QATAR, RTW89_UKRAINE, RTW89_CN. Adjust some entries with explicit rtw89_regulatory instead of RTW89_WW. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211101093106.28848-5-pkshih@realtek.com
2021-11-26rtw89: update tx power limit/limit_ru tables to R54Zong-Zhe Yang1-670/+2413
Update tx power limit table and tx power limit_ru table to R54. Configure entries for MEXICO, CN, QATAR, and adjust some values of original entries. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211101093106.28848-4-pkshih@realtek.com
2021-11-26rtw89: update rtw89 regulation definition to R58-R31Zong-Zhe Yang2-4/+17
Support QATAR in rtw89_regulation_type and reorder the enum to align realtek R58-R31 regulation definition. Besides, if an unassigned entry of limit/limit_ru tables is read, return the corresponding WW value for the unconfigured case. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211101093106.28848-3-pkshih@realtek.com
2021-11-26rtw89: fill regd field of limit/limit_ru tables by enumZong-Zhe Yang1-5229/+5229
This modification just replaces the number filled in the regd field with the corresponding enum. No assignment of a value in a table is changed. Doing this first is because the follow-up patches may adjust the order of enum declarations. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211101093106.28848-2-pkshih@realtek.com
2021-11-19Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo40-405/+1352
ath.git patches for v5.17. Major changes: ath10k * fetch (pre-)calibration data via nvmem subsystem ath11k * enable 802.11 power save mode in station mode for qca6390 and wcn6855 * trace log support * proper board file detection for WCN6855 based on PCI ids * BSS color change support
2021-11-19ath9k: fix intr_txqs settingPeter Seiderer1-1/+1
The struct ath_hw member intr_txqs is never reset/assigned outside of ath9k_hw_init_queues() and with the used bitwise-or in the interrupt handling ar9002_hw_get_isr() accumulates all ever set interrupt flags. Fix this by using a pure assign instead of bitwise-or for the first line (note: intr_txqs is only evaluated in case ATH9K_INT_TX bit is set). Signed-off-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211116220720.30145-1-ps.report@gmx.net
2021-11-19ath11k: add hw_param for wakeup_mhiSeevalamuthu Mariappan3-4/+14
Wakeup mhi is needed before pci_read/write only for QCA6390 and WCN6855. Since wakeup & release mhi is enabled for all hardwares, below mhi assert is seen in QCN9074 when doing 'rmmod ath11k_pci': Kernel panic - not syncing: dev_wake != 0 CPU: 2 PID: 13535 Comm: procd Not tainted 4.4.60 #1 Hardware name: Generic DT based system [<80316dac>] (unwind_backtrace) from [<80313700>] (show_stack+0x10/0x14) [<80313700>] (show_stack) from [<805135dc>] (dump_stack+0x7c/0x9c) [<805135dc>] (dump_stack) from [<8032136c>] (panic+0x84/0x1f8) [<8032136c>] (panic) from [<80549b24>] (mhi_pm_disable_transition+0x3b8/0x5b8) [<80549b24>] (mhi_pm_disable_transition) from [<80549ddc>] (mhi_power_down+0xb8/0x100) [<80549ddc>] (mhi_power_down) from [<7f5242b0>] (ath11k_mhi_op_status_cb+0x284/0x3ac [ath11k_pci]) [E][__mhi_device_get_sync] Did not enter M0 state, cur_state:RESET pm_state:SHUTDOWN Process [E][__mhi_device_get_sync] Did not enter M0 state, cur_state:RESET pm_state:SHUTDOWN Process [E][__mhi_device_get_sync] Did not enter M0 state, cur_state:RESET pm_state:SHUTDOWN Process [<7f5242b0>] (ath11k_mhi_op_status_cb [ath11k_pci]) from [<7f524878>] (ath11k_mhi_stop+0x10/0x20 [ath11k_pci]) [<7f524878>] (ath11k_mhi_stop [ath11k_pci]) from [<7f525b94>] (ath11k_pci_power_down+0x54/0x90 [ath11k_pci]) [<7f525b94>] (ath11k_pci_power_down [ath11k_pci]) from [<8056b2a8>] (pci_device_shutdown+0x30/0x44) [<8056b2a8>] (pci_device_shutdown) from [<805cfa0c>] (device_shutdown+0x124/0x174) [<805cfa0c>] (device_shutdown) from [<8033aaa4>] (kernel_restart+0xc/0x50) [<8033aaa4>] (kernel_restart) from [<8033ada8>] (SyS_reboot+0x178/0x1ec) [<8033ada8>] (SyS_reboot) from [<80301b80>] (ret_fast_syscall+0x0/0x34) Hence, disable wakeup/release mhi using hw_param for other hardwares. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01060-QCAHKSWPL_SILICONZ-1 Fixes: a05bd8513335 ("ath11k: read and write registers below unwindowed address") Signed-off-by: Seevalamuthu Mariappan <quic_seevalam@quicinc.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1636702019-26142-1-git-send-email-quic_seevalam@quicinc.com
2021-11-18Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski44-311/+482
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-05-03 16:47:57 +0000