summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-11-08wifi: rtw89: dump dispatch status via debug portChia-Yuan Li
Dispatch is a component to decide packets forward to host, DMAC or HAXIDMA. It contains CDT standing for CPU dispatcher, HDT standing for host dispatcher, WDE standing for descriptor engine and PLE standing for payload engine. STF is one kind of modes, it can be used if packet send to hardware and doesn't need release report. These debug port information can help to clarify the reason if packets stuck in dispatch. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221102014300.14091-2-pkshih@realtek.com
2022-11-08wifi: Use kstrtobool() instead of strtobool()Christophe JAILLET
strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. While at it, include the corresponding header file (<linux/kstrtox.h>) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/1ff34549af5ad6f7c80d5b9e11872b5499065fc1.1667336095.git.christophe.jaillet@wanadoo.fr
2022-11-08wifi: brcmfmac: Avoiding Connection delayPrasanna Kerekoppa
Channel info passed by supplicant is not given to firmware. This causes delay (about 3seconds) due to full scan. Supplicant already provides the channel info for the specific SSID. channel_hint carries this channel info for the connect call back. Patch has been verified on 43012 and 43455. Signed-off-by: Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com> Signed-off-by: Chung-Hsien Hsu <chung-hsien.hsu@infineon.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@infineon.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221024085215.27616-4-ian.lin@infineon.com
2022-11-08wifi: brcmfmac: Fix for when connect request is not successWataru Gohda
Currently brcmfmac is expecting to be set for both BRCMF_VIF_STATUS_EAP_SUCCESS and BRCMF_VIF_STATUS_EAP status bit based on dongle event and those bits are cleared to complete connect request successfully. But when connect request is finished unsuccessfully, either BRCMF_VIF_STATUS_EAP_SUCCESS / BRCMF_VIF_STATUS_EAP bits are not cleared depending on how the connect fail event happens. These status bits are carried over to following new connect request and this will lead to generate below kernel warning for some case. Worst case status mismatch happens between dongle and wpa_supplicant. WARNING: ../net/wireless/sme.c:756 __cfg80211_connect_result+0x42c/0x4a0 [cfg80211] The fix is to clear the BRCMF_VIF_STATUS_EAP_SUCCESS / BRCMF_VIF_STATUS_EAP bits during the link down process and add to call link down process when link down event received during BRCMF_VIF_STATUS_CONNECTING as well as BRCMF_VIF_STATUS_CONNECTED state. Signed-off-by: Wataru Gohda <wataru.gohda@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@infineon.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221024085215.27616-3-ian.lin@infineon.com
2022-11-08wifi: brcmfmac: correctly remove all p2p vifBrian Henriquez
When deleting a P2P AGO interface we should make sure that relevant entry in bss_idx[] array is removed. We were always removing only 'vif' at P2PAPI_BSSCFG_CONNECTION before, regardless of the number of created P2P AGO interfaces. brcmfmac: correctly remove all p2p vif Signed-off-by: Brian Henriquez <brian.henriquez@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@infineon.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221024085215.27616-2-ian.lin@infineon.com
2022-11-04wifi: rtl8xxxu: Use dev_* instead of pr_infoBitterblue Smith
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
2022-11-04wifi: rtl8xxxu: Set IEEE80211_HW_SUPPORT_FAST_XMITBitterblue Smith
According to commit 60d7900dcb98 ("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 <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/9b59e735-6b89-a557-fafc-2da87fdd5b48@gmail.com
2022-11-04wifi: rtl8xxxu: Recognise all possible chip cutsBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/1559c705-0b0b-8dcb-7596-fbb85844d3d9@gmail.com
2022-11-04wifi: rtl8xxxu: Fix the CCK RSSI calculationBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/926c838f-4997-698b-4da9-44582e2af99a@gmail.com
2022-11-04wifi: rtl8xxxu: Add central frequency offset trackingBitterblue Smith
According to Realtek programmers, "to adjust oscillator to align central frequency of connected AP. Then, it can yield better performance." From commit fb8517f4fade ("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: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/80aba428-0aff-f4b2-dea5-35d1425982b6@gmail.com
2022-11-04wifi: brcmfmac: Fix potential NULL pointer dereference in ↵Jisoo Jang
'brcmf_c_preinit_dcmds()' 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: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221101183642.166450-1-jisoo.jang@yonsei.ac.kr
2022-11-04wifi: brcmfmac: Fix a typo "unknow"Jonathan Neuschäfer
It should be "unknown". Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221101170252.1032085-1-j.neuschaefer@gmx.net
2022-11-04wifi: rtlwifi: rtl8192ee: remove static variable stop_report_cntColin Ian King
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: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221031155637.871164-1-colin.i.king@gmail.com
2022-11-04bcma: Fail probe if GPIO subdriver failsLinus Walleij
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: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221028093000.239020-1-linus.walleij@linaro.org
2022-11-04bcma: Use the proper gpio includeLinus Walleij
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: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221028092332.238728-1-linus.walleij@linaro.org
2022-11-04wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()Minsuk Kang
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: 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: Minsuk Kang <linuxlovemin@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221024071329.504277-1-linuxlovemin@yonsei.ac.kr
2022-11-01wifi: wilc1000: sdio: fix module autoloadingMichael Walle
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: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027171221.491937-1-michael@walle.cc
2022-11-01wifi: atmel: Fix atmel_private_handler array sizeKees Cook
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: 8af9d4068e86 ("wifi: atmel: Avoid clashing function prototypes") Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221018023732.never.700-kees@kernel.org
2022-11-01wifi: ipw2200: Remove the unused function ipw_alive()Jiapeng Chong
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=2410 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221017071746.118685-1-jiapeng.chong@linux.alibaba.com
2022-11-01wifi: rtw89: 8852b: Fix spelling mistake KIP_RESOTRE -> KIP_RESTOREColin Ian King
Ther is a spelling mistake in a rtw89_debug message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221020072646.1513307-1-colin.i.king@gmail.com
2022-11-01wifi: rtw89: add WoWLAN pattern match supportChin-Yen Lee
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: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-8-pkshih@realtek.com
2022-11-01wifi: rtw89: add WoWLAN function supportChin-Yen Lee
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 <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-7-pkshih@realtek.com
2022-11-01wifi: rtw89: add related H2C for WoWLAN modeChin-Yen Lee
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: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-6-pkshih@realtek.com
2022-11-01wifi: rtw89: add drop tx packet functionChih-Kang Chang
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: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-5-pkshih@realtek.com
2022-11-01wifi: rtw89: add function to adjust and restore PLE quotaChih-Kang Chang
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 <gary.chang@realtek.com> Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-4-pkshih@realtek.com
2022-11-01wifi: rtw89: move enable_cpu/disable_cpu into fw_downloadChih-Kang Chang
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 <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-3-pkshih@realtek.com
2022-11-01wifi: rtw89: collect and send RF parameters to firmware for WoWLANChih-Kang Chang
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: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-2-pkshih@realtek.com
2022-11-01wifi: rtw89: check if sta's mac_id is valid under AP/TDLSZong-Zhe Yang
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: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221021091828.40157-1-pkshih@realtek.com
2022-11-01wifi: rtw89: add BW info for both TX and RX in phy_infoEric Huang
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 <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221021091601.39884-1-pkshih@realtek.com
2022-11-01wifi: rtw89: 8852c: make table of RU mask constantPing-Ke Shih
This table must be constant, so change it as expectation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221020052702.33988-2-pkshih@realtek.com
2022-11-01wifi: rtw89: declare support bands with constZong-Zhe Yang
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: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221020052702.33988-1-pkshih@realtek.com
2022-11-01wifi: rtw89: fw: adapt to new firmware format of dynamic headerPing-Ke Shih
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: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221020052549.33783-1-pkshih@realtek.com
2022-10-29Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for v6.2. Major changes: ath11k * support configuring channel dwell time during scan
2022-10-28ice: Add additional CSR registers to ETHTOOL_GREGSLukasz Czapnik
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.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28Merge branch 'clean-up-sfp-register-definitions'Jakub Kicinski
Russell King says: ==================== Clean up SFP register definitions This two-part patch series cleans up the SFP register definitions by 1. converting them from hex to decimal, as all the definitions in the documents use decimal, this makes it easier to cross-reference. 2. moving the bit definitions for each register along side their register address definition ==================== Link: https://lore.kernel.org/r/Y1qFvaDlLVM1fHdG@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: sfp: move field definitions along side register indexRussell King (Oracle)
Just as we do for the A2h enum, arrange the A0h enum to have the field definitions next to their corresponding register index. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: sfp: convert register indexes from hex to decimalRussell King (Oracle)
The register indexes in the standards are in decimal rather than hex, so lets specify them in decimal in the header file so we can easily cross-reference without converting between hex and decimal. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28Merge branch 'net-mtk_eth_soc-improve-pcs-implementation'Jakub Kicinski
Russell King says: ==================== net: mtk_eth_soc: improve PCS implementation As a result of invesigations from Frank Wunderlich, we know a lot more about the Mediatek "SGMII" PCS block, and can implement the PCS support correctly. This series achieves that, and Frank has tested the final result and reports that it works for him. The series could do with further testing by others, but I suspect that is unlikely to happen until it is merged based on past performances with this driver. Briefly, the patches in order: 1. Add a new helper to get the link timer duration in nanoseconds 2. Add definitions for the newly discovered registers and updates to bit definitions, including bitmasks for the BMCR, BMSR and two advertisement registers. 3. Remove unnecessary/unused error handling (functions always returning zero.) 4. Adding the missing pcs_get_state() implementation. 5. Converting the code to use regmap_update_bits() rather than open-coding read-modify-write sequences. 6. Adding out-of-band speed and duplex forcing for all non-inband modes not just the 802.3z link modes the code currently does. 7. Moving the release of the PHY power down to the main pcs_config() function. 8. Moving the interface speed selection to the main pcs_config() function. 9. Adding advertisement programming. 10. Adding correct link timer programming using the new helper in the first patch. 11. Adding support for 802.3z negotiation. There is one remaining issue - when configuring the PCS for in-band, for some reason the AN restart bit is always set. This should not be necessary, but requires further investigation with the hardware to find out whether it is really necessary. I suspect this was a work around for a previous poor implementation. ==================== Link: https://lore.kernel.org/r/Y1qDMw+DJLAJHT40@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: add support for in-band 802.3z negotiationRussell King (Oracle)
As a result of help from Frank Wunderlich to investigate and test, we now know how to program this PCS for in-band 802.3z negotiation. Add support for this by moving the contents of the two functions into the common mtk_pcs_config() function and adding the register settings for 802.3z negotiation. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: move and correct link timer programmingRussell King (Oracle)
Program the link timer appropriately for the interface mode being used, using the newly introduced phylink helper that provides the nanosecond link timer interval. The intervals are 1.6ms for SGMII based protocols and 10ms for 802.3z based protocols. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: add advertisement programmingRussell King (Oracle)
Program the advertisement into the mtk PCS block. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: move interface speed selectionRussell King (Oracle)
Move the selection of the underlying interface speed to the pcs_config function, so we always program the interface speed. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: move PHY power upRussell King (Oracle)
The PHY power up is common to both configuration paths, so move it into the parent function. We need to do this for all serdes modes. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: add out of band forcing of speed and duplex in pcs_link_upRussell King (Oracle)
Add support for forcing the link speed and duplex setting in the pcs_link_up() method for out of band modes, which will be useful when we finish converting the pcs_config() method. Until then, we still have to force duplex for 802.3z modes to work correctly. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: convert mtk_sgmii to use regmap_update_bits()Russell King (Oracle)
mtk_sgmii does a lot of read-modify-write operations, for which there is a specific regmap function. Use this function instead of open-coding the operations. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: add pcs_get_state() implementationRussell King (Oracle)
Add a pcs_get_state() implementation which uses the advertisements to compute the resulting link modes, and BMSR contents to determine negotiation and link status. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: eliminate unnecessary error handlingRussell King (Oracle)
The functions called by the pcs_config() method always return zero, so there is no point trying to handle an error from these functions. Make these functions void, eliminate the "err" variable and simply return zero from the pcs_config() function itself. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: mtk_eth_soc: add definitions for PCSRussell King (Oracle)
As a result of help from Frank Wunderlich to investigate and test, we know a bit more about the PCS on the Mediatek platforms. Update the definitions from this investigation. This PCS appears similar, but not identical to the Lynx PCS. Although not included in this patch, but for future reference, the PHY ID registers at offset 4 read as 0x4d544950 'MTIP'. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28net: phylink: add phylink_get_link_timer_ns() helperRussell King (Oracle)
Add a helper to convert the PHY interface mode to the required link timer setting as stated by the appropriate standard. Inappropriate interface modes return an error. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-28Merge branch 'net-remove-the-obsolte-u64_stats_fetch_-_irq'Jakub Kicinski
Sebastian Andrzej Siewior says: ==================== net: Remove the obsolte u64_stats_fetch_*_irq() This is the removal of u64_stats_fetch_*_irq() users in networking. The prerequisites are part of v6.1-rc1. The spi and bpf bits are not part of the series and have been routed directly. ==================== Link: https://lore.kernel.org/r/20221026132215.696950-1-bigeasy@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 05:48:23 +0000