- 10 Nov, 2022 11 commits
-
-
Rotem Saado authored
The failed_alloc variable is used as a bitmask in the loop where we check DRAM allocations. But erroneously, we were clearing the DRAM alloc IDs we removed as an integer. Fix that by clearing them as bits instead. Signed-off-by:
Rotem Saado <rotem.saado@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221102165239.688dec28b1d9.I470b8d29c28d16f25f4192773f075940de7ed33c@changeid
-
Luca Coelho authored
In some rare occasions, the firmware may let some frames with invalid rates, such as CCK rates on the high band, come through. This causes the driver to issue a warning, but since this is a possible issue and it's not really a bug in the driver, convert the warning into an error. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Luca Coelho authored
The A step of BL devices doesn't support STBC, so we need to disable it. Create new HT params and a macro to use specifically with BL A-step devices where STBC is disabled. Signed-off-by:
-
Rotem Saado authored
Update the for loop that iterates over all the DBGCs to include DBGC4. DBGC4 is only supported staring from the BZ family of devices, so check the family before accepting it. Signed-off-by:
-
Johannes Berg authored
For Bz A-step hardware, the checksum offload is broken and we need to use the old way, which is still there. Do that, which requires taking the checksum capability bits out of the IWL_DEVICE_BZ macro and listing them individually. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
If cloning the SKB fails, don't try to use it, but rather return as if we should pass it. Coverity CID: 1503456 Fixes: 2da4366f ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by:
-
Avraham Stern authored
The AMT_STATE sap message handler tries to take the rtnl lock. This means that in case the rtnl lock is already taken, sap messages will not be processed. When an interface is brought up, the host requests ownership from csme. However, since the rtnl lock is already held, if there is a pending amt state message, the host will not be able to read the ownership confirm message because the amt state message handler is pending. As a result, the host fails to get ownership although csme granted it. Fix it by moving the part that needs the rtnl lock into a dedicated worker, so handling sap messages can continue. Fixes: 2da4366f ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
Devices with new Tx API have the IV introduced by the HW and it is not present in the skb at all. Hence we don't need to tell iwl_mvm_mei_tx_copy_to_csme to jump over 8 bytes to get to the ethernet header. Fixes: 2da4366f ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
We should not send any SAP command to CSME if AMT is disabled. Reported-by:
Toke Høiland-Jørgensen <toke@toke.dk> Fixes: 2da4366f ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by:
-
Avraham Stern authored
It is possible that CSME will try to take ownership while the driver is stopping. In this case, if the CSME takes ownership message arrives after the driver started unregistering, the iwl_mei_cache->ops is already invalid, so the host will not answer with the ownership confirmed message. Similarly, if the take ownership message arrived after the mac was stopped or when iwl_mvm_up() failed, setting rfkill will not trigger sending the confirm message. As a result, CSME will not take ownership, which will result in a disconnection. Fix it by sending the ownership confirmed message immediately in such cases. Fixes: 2da4366f ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by:
-
Avraham Stern authored
Notify csme when associated with TKIP cipher. TKIP is supported by csme. Signed-off-by:
-
- 04 Nov, 2022 11 commits
-
-
Bitterblue Smith authored
Replace two instances of bare pr_info with dev_info and dev_warn. Also make their messages a little more informative. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/c9f3ebb2-769b-7d80-cac2-5a9d1bcc010a@gmail.com
-
Bitterblue Smith authored
According to commit 60d7900d ("wlcore: enable IEEE80211_HW_SUPPORT_FAST_XMIT"), we can use this because all the chips have hardware rate control. This is one of the things mac80211 requires before it will handle MSDU aggregation for us. Signed-off-by:
-
Bitterblue Smith authored
The chip cut, also known as the chip version, is a letter from A (0) to P (15). Recognise them all instead of printing "unknown" when it's greater than E. Signed-off-by:
-
Bitterblue Smith authored
The CCK RSSI calculation is incorrect for the RTL8723BU, RTL8192EU, and RTL8188FU. Add new functions for these chips with code copied from their vendor drivers. Use the old code only for the RTL8723AU and RTL8192CU. I didn't notice any difference in the reported signal strength with my RTL8188FU, but I didn't look very hard either. Signed-off-by:
-
Bitterblue Smith authored
According to Realtek programmers, "to adjust oscillator to align central frequency of connected AP. Then, it can yield better performance." From commit fb8517f4 ("rtw88: 8822c: add CFO tracking"). The RTL8192CU and a version of RTL8723AU apparently don't have the ability to adjust the oscillator, so this doesn't apply to them. This also doesn't apply to the wifi + bluetooth combo chips (RTL8723AU and RTL8723BU) because the CFO tracking should only be done when bluetooth is disabled, and determining that looked complicated. That leaves only the RTL8192EU and RTL8188FU chips. I tested this with the latter. Signed-off-by:
-
Jisoo Jang authored
This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when ptr which is NULL pointer passed as an argument of strlcpy() in brcmf_c_preinit_dcmds(). This happens when the driver passes a firmware version string that does not contain a space " ", making strrchr() return a null pointer. This patch adds a null pointer check. Found by a modified version of syzkaller. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 1983 Comm: kworker/0:2 Not tainted 5.14.0+ #79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event RIP: 0010:strlen+0x1a/0x90 Code: 23 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 48 b8 00 00 00 00 00 fc ff df 48 89 fa 55 48 89 fd 48 c1 ea 03 53 48 83 ec 08 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 04 84 c0 75 48 80 7d 00 00 RSP: 0018:ffffc90002bfedd8 EFLAGS: 00010296 RAX: dffffc0000000000 RBX: 1ffff9200057fdc1 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000020 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000039 R09: ffffed1023549801 R10: ffff88811aa4c007 R11: ffffed1023549800 R12: ffff88800bc68d6c R13: ffffc90002bfef08 R14: ffff88800bc6bc7c R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020546180 CR3: 0000000117ff1000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: brcmf_c_preinit_dcmds+0x9f2/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1703/0x1dd0 ? kmemdup+0x43/0x50 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x2aa/0x760 ? usb_probe_device+0x250/0x250 really_probe+0x205/0xb70 ? driver_allows_async_probing+0x130/0x130 __driver_probe_device+0x311/0x4b0 ? driver_allows_async_probing+0x130/0x130 driver_probe_device+0x4e/0x150 __device_attach_driver+0x1cc/0x2a0 bus_for_each_drv+0x156/0x1d0 ? bus_rescan_devices+0x30/0x30 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x46/0x160 __device_attach+0x23f/0x3a0 ? device_bind_driver+0xd0/0xd0 ? kobject_uevent_env+0x287/0x14b0 bus_probe_device+0x1da/0x290 device_add+0xb7b/0x1eb0 ? wait_for_completion+0x290/0x290 ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 usb_set_configuration+0xf59/0x16f0 usb_generic_driver_probe+0x82/0xa0 usb_probe_device+0xbb/0x250 ? usb_suspend+0x590/0x590 really_probe+0x205/0xb70 ? driver_allows_async_probing+0x130/0x130 __driver_probe_device+0x311/0x4b0 ? usb_generic_driver_match+0x75/0x90 ? driver_allows_async_probing+0x130/0x130 driver_probe_device+0x4e/0x150 __device_attach_driver+0x1cc/0x2a0 bus_for_each_drv+0x156/0x1d0 ? bus_rescan_devices+0x30/0x30 ? _raw_spin_unlock_irqrestore+0x47/0x50 __device_attach+0x23f/0x3a0 ? device_bind_driver+0xd0/0xd0 ? kobject_uevent_env+0x287/0x14b0 bus_probe_device+0x1da/0x290 device_add+0xb7b/0x1eb0 ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 ? kfree+0x14a/0x6b0 ? __usb_get_extra_descriptor+0x116/0x160 usb_new_device.cold+0x49c/0x1029 ? hub_disconnect+0x450/0x450 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_unlock_irq+0x24/0x30 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 hub_event+0x248b/0x31c9 ? usb_port_suspend.cold+0x139/0x139 ? check_irq_usage+0x861/0xf20 ? drain_workqueue+0x280/0x360 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x92b/0x1460 ? pwq_dec_nr_in_flight+0x330/0x330 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x95/0xe00 ? __kthread_parkme+0x115/0x1e0 ? process_one_work+0x1460/0x1460 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30 Modulesdd linked in: ---[ end trace c112c68924ddd800 ]--- RIP: 0010:strlen+0x1a/0x90 Code: 23 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 48 b8 00 00 00 00 00 fc ff df 48 89 fa 55 48 89 fd 48 c1 ea 03 53 48 83 ec 08 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 04 84 c0 75 48 80 7d 00 00 RSP: 0018:ffffc90002bfedd8 EFLAGS: 00010296 RAX: dffffc0000000000 RBX: 1ffff9200057fdc1 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000020 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000039 R09: ffffed1023549801 R10: ffff88811aa4c007 R11: ffffed1023549800 R12: ffff88800bc68d6c R13: ffffc90002bfef08 R14: ffff88800bc6bc7c R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020546180 CR3: 0000000117ff1000 CR4: 0000000000750ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Reported-by:
Dokyung Song <dokyungs@yonsei.ac.kr> Reported-by:
Jisoo Jang <jisoo.jang@yonsei.ac.kr> Reported-by:
Minsuk Kang <linuxlovemin@yonsei.ac.kr> Signed-off-by:
-
Jonathan Neuschäfer authored
It should be "unknown". Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Colin Ian King authored
Variable stop_report_cnt is being set or incremented but is never being used for anything meaningful. The variable and code relating to it's use is redundant and can be removed. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Linus Walleij authored
We currently register the BCMA core even if the GPIO portions fail. There is no reason for this: the GPIO should register just fine, if it fails the BCMA driver should fail. We already gracefully handle the case where the GPIO driver is not compiled in. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
The <linux/bcma/bcma_driver_chipcommon.h> is including the legacy header <linux/gpio.h> to obtain struct gpio_chip. Instead, include <linux/gpio/driver.h> where this struct is defined. It turns out that the brcm80211 brcmsmac depends on this to bring in the symbol gpio_is_valid(). The driver looks up the BCMA parent GPIO driver and checks that this succeeds, but then it goes on to use the deprecated GPIO call gpio_is_valid() to check the consistency of the .base member of the BCMA GPIO struct. The whole check can be dropped because the bcma_gpio is initialized in the declarations: struct gpio_chip *bcma_gpio = &cc_drv->gpio; And this can never be NULL. Cc: Jonas Gorski <jonas.gorski@gmail.com> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Minsuk Kang authored
This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITS_PER_TYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example. Found by a modified version of syzkaller. UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? process_one_work+0x13e0/0x13e0 kthread+0x379/0x450 ? _raw_spin_unlock_irq+0x24/0x30 ? set_kthread_struct+0x100/0x100 ret_from_fork+0x1f/0x30 Reported-by:
-
- 01 Nov, 2022 16 commits
-
-
Michael Walle authored
There are no SDIO module aliases included in the driver, therefore, module autoloading isn't working. Add the proper MODULE_DEVICE_TABLE(). Cc: stable@vger.kernel.org Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Kees Cook authored
Fix the atmel_private_handler to correctly sized (1 element) again. (I should have checked the data segment for differences.) This had no behavioral impact (no private callbacks), but it made a very large zero-filled array. Cc: Simon Kelley <simon@thekelleys.org.uk> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Fixes: 8af9d406 ("wifi: atmel: Avoid clashing function prototypes") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Jiapeng Chong authored
The function ipw_alive() is defined in the ipw2200.c file, but not called elsewhere, so delete this unused function. drivers/net/wireless/intel/ipw2x00/ipw2200.c:3007:19: warning: unused function 'ipw_alive'. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2410Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Colin Ian King authored
Ther is a spelling mistake in a rtw89_debug message. Fix it. Signed-off-by:
-
Chin-Yen Lee authored
Pattern match is an option of WoWLAN to allow the device to be woken up from suspend mode when receiving packets matched user-designed patterns. The patterns are written into hardware via WoWLAN firmware in suspend flow if users have set up them. If packets matched designed pattern are received, WoWLAN firmware will send an interrupt and then wake up the device. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Chin-Yen Lee authored
WoWLAN is a feature which allows devices to be woken up from suspend state through WLAN events. When user enables WoWLAN feature and then let the device enter suspend state, WoWLAN firmware will be loaded by the driver and periodically monitors WiFi packets. Power consumption of WiFi chip will be reduced in this state. We now implement WoWLAN function in rtw8852ae and rtw8852ce chip. Currently supported WLAN events include receiving magic packet, rekey packet and deauth packet, and disconnecting from AP. Signed-off-by:
-
Chin-Yen Lee authored
In this patch we define some H2C, which will be called during suspend flow, to enable WoWLAN function provided by WoWLAN firmware. These H2C includes keep alive used to send null packet to AP periodically to avoid being disconnected by AP, disconnect detection used to configure how we check if AP is offline, wake up control used to decide which WiFi events could trigger resume flow, and global control used to enable WoWLAN function. Signed-off-by:
-
Chih-Kang Chang authored
When entering WoWLAN mode, we need to drop all transmit packets, including those in mac buffer, to avoid memory leakage, so implement the drop_tx function. Signed-off-by:
Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by:
-
Chih-Kang Chang authored
PLE RX quota, which is the setting of RX buffer, is needed to be adjusted dynamically for WoWLAN mode, and restored when back to normal mode. The action is not needed for rtw8852c chip. Signed-off-by:
-
Chih-Kang Chang authored
For WoWLAN mode, we need to download WoWLAN firmware by calling fw_download(). Another, to disable/enable WiFi CPU is needed before calling fw_download. Since Firmware runs on WiFi CPU, it is intuitive to combine enable_cpu/disable_cpu functions into fw_download. Signed-off-by:
-
Chih-Kang Chang authored
For WoWLAN mode, we only collect and send RF parameters to Firmware without writing RF registers. So we add one function to practice it. Signed-off-by:
-
Zong-Zhe Yang authored
Add boundary check of mac_id when adding sta under AP/TDLS. And, return -ENOSPC if the acquired mac_id is invalid. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Eric Huang authored
In order to debug performance issue intuitively, add bandwidth information into debugfs entry phy_info. After applying this patch, it looks like: TX rate [0]: HE 2SS MCS-11 GI:0.8 BW:80 (hw_rate=0x19b) ==> agg_wait=1 (3500) RX rate [0]: HE 2SS MCS-9 GI:0.8 BW:80 (hw_rate=0x199) Signed-off-by:
Eric Huang <echuang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
This table must be constant, so change it as expectation. Signed-off-by:
-
Zong-Zhe Yang authored
They are just default declarations and we won't modify them directly. Instead, we actually do moification on their memdup now. So, they should be declared with const. Signed-off-by:
-
Ping-Ke Shih authored
Since firmware size is limited, we create variant firmwares for variant application areas. To help driver to know firmware's capabilities, firmware dynamic header is introduced to have more information, such as firmware features and firmware compile flags. Since this driver rtw89 only uses single one specific firmware at runtime, this patch is just to ignore this dynamic header, not actually use the content. This patch can be backward compatible, and no this kind of firmware is added to linux-firmware yet, so I can prepare this in advance. Signed-off-by:
-
- 29 Oct, 2022 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v6.2. Major changes: ath11k * support configuring channel dwell time during scan
-
Lukasz Czapnik authored
In the event of a Tx hang it can be useful to read a variety of hardware registers to capture some state about why the transmit queue got stuck. Extend the ETHTOOL_GREGS dump provided by the ice driver with several CSR registers that provide such relevant information regarding the hardware Tx state. This enables capturing relevant data to enable debugging such a Tx hang. Signed-off-by:
Lukasz Czapnik <lukasz.czapnik@intel.com> Signed-off-by:
Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Link: https://lore.kernel.org/r/20221027104239.1691549-1-jacob.e.keller@intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
