- 13 Sep, 2021 40 commits
-
-
Michael Straube authored
Remove InitSwLeds from hal_ops and remove its wrapper rtw_hal_sw_led_init(). Call rtl8188eu_InitSwLeds() directly instead. Signed-off-by:
Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210906190223.11396-2-straube.linux@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Fabio M. De Francesco authored
Remove _enter_critical_mutex() and _exit_critical_mutex(). They are unnecessary wrappers, respectively to mutex_lock_interruptible() and to mutex_unlock(). They also have an odd interface that takes an unused argument named pirqL of type unsigned long. The original code enters the critical section if the mutex API is interrupted while waiting to acquire the lock; therefore it could lead to a race condition. Use mutex_lock() because it is uninterruptible and so avoid that above-mentioned potential race condition. Tested-by:
Pavel Skripkin <paskripkin@gmail.com> Reviewed-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20210828113656.6963-1-fmdefrancesco@gmail.comSigned-off-by:
-
Pavel Skripkin authored
While testing Fabio's patch I hit lockdep warning about possible deadlock: [ 252.063305] WARNING: possible recursive locking detected [ 252.063642] 5.14.0+ #9 Tainted: G C [ 252.063946] -------------------------------------------- [ 252.064282] ip/335 is trying to acquire lock: [ 252.064560] ffff888009ebad28 (pmutex){+.+.}-{4:4}, at: usbctrl_vendorreq+0xc5/0x4a0 [r8188eu] [ 252.065168] [ 252.065168] but task is already holding lock: [ 252.065536] ffffffffc021b3b8 (pmutex){+.+.}-{4:4}, at: netdev_open+0x3a/0x5f [r8188eu] [ 252.066085] [ 252.066085] other info that might help us debug this: [ 252.066494] Possible unsafe locking scenario: [ 252.066494] [ 252.066866] CPU0 [ 252.067025] ---- [ 252.067184] lock(pmutex); [ 252.067367] lock(pmutex); There is one problem with this warning: there is no pmutex in this driver, *BUT* all mutexes are initialized via private _rtw_mutex_init API, which had struct mutex *pmutex argument. So, all mutexes in this driver had same name in lockdep map. Of course, lockdep will complain about any nested locking. Fix it by open-coding _rtw_mutex_{init,free} wrappers, because we do not need them at all. Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by: -
Pavel Skripkin authored
smatch says: usb_intf.c:326 rtw_hw_suspend() warn: variable dereferenced before check 'padapter' (see line 323) usb_intf.c:387 rtw_hw_resume() warn: variable dereferenced before check 'padapter' (see line 385) There is only one caller of rtw_hw_suspend() and it does not check padapter pointer, so let's just omit this check to make smatch happy. Signed-off-by:
-
Saurav Girepunje authored
Remove below duplicate declaration from rtl8188e_led.h file void SwLedOn(struct adapter *padapter, struct LED_871x *pLed); void SwLedOff(struct adapter *padapter, struct LED_871x *pLed); Signed-off-by:
Saurav Girepunje <saurav.girepunje@gmail.com> Link: https://lore.kernel.org/r/YTRuXTu/kePBDwAF@userSigned-off-by:
-
Phillip Potter authored
Remove c2h_id_filter_ccx function pointer from struct hal_ops, as it is unused. Signed-off-by:
Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210906010106.898-15-phil@philpotter.co.ukSigned-off-by:
-
Phillip Potter authored
Remove rtw_hal_c2h_id_filter_ccx from hal/hal_intf.c and its one caller from core/rtw_cmd.c. This function is a wrapper function which returns the c2h_id_filter_ccx function pointer of struct hal_ops unconditionally. As this function pointer is never set, and the function call's return value is subsequently called inside an if condition, this could lead to an attempt to deference a NULL pointer, which would crash the driver. Signed-off-by:
-
Phillip Potter authored
Remove Efuse_PgPacketWrite_BT function pointer from struct hal_ops, as it is unused. Signed-off-by:
-
Phillip Potter authored
Remove static Efuse_PgPacketWrite_BT and its one caller from core/rtw_efuse.c. This function is a wrapper function which calls the Efuse_PgPacketWrite_BT function pointer of struct hal_ops unconditionally. As this function pointer is never set, and this function call is possible to reach, this could lead to an attempt to deference a NULL pointer, which would crash the driver. Signed-off-by:
-
Phillip Potter authored
Remove hal_xmitframe_enqueue function pointer from struct hal_ops, as it is unused. Signed-off-by:
-
Phillip Potter authored
Remove rtw_hal_xmitframe_enqueue from hal/hal_intf.c and its one caller from core/rtw_recv.c, and remove its declaration from include/hal_intf.h as well. This is just a wrapper function that calls the function pointer hal_xmitframe_enqueue in struct hal_ops if it is set, which it never is. Signed-off-by:
-
Phillip Potter authored
Remove interrupt_handler function pointer from struct hal_ops, as it is unused. Signed-off-by:
-
Phillip Potter authored
Remove rtw_hal_interrupt_handler from hal/hal_intf.c, and remove its declaration from include/hal_intf.h as well. This is just a wrapper function that calls the function pointer interrupt_handler in struct hal_ops if it is set, which it never is. In addition, this wrapper function is unused anyway. Signed-off-by:
-
Phillip Potter authored
Remove disable_interrupt function pointer from struct hal_ops, as it is unused. Signed-off-by:
-
Phillip Potter authored
Remove rtw_hal_disable_interrupt from hal/hal_intf.c, and remove its declaration from include/hal_intf.h as well. This is just a wrapper function that calls the function pointer disable_interrupt in struct hal_ops if it is set, which it never is. In addition, this wrapper function is unused anyway. Signed-off-by:
-
Phillip Potter authored
Remove enable_interrupt function pointer from struct hal_ops, as it is unused. Signed-off-by:
-
Phillip Potter authored
Remove rtw_hal_enable_interrupt from hal/hal_intf.c, and remove its declaration from include/hal_intf.h as well. This is just a wrapper function that calls the function pointer enable_interrupt in struct hal_ops if it is set, which it never is. In addition, this wrapper function is unused anyway. Signed-off-by:
-
Phillip Potter authored
Remove hal_reset_security_engine function pointer from struct hal_ops, as it is unused. Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Phillip Potter authored
Remove rtw_hal_reset_security_engine and its one caller from hal/hal_intf.c, and remove its declaration from include/hal_intf.h as well. This is just a wrapper function that calls the function pointer hal_reset_security_engine in struct hal_ops if it is set, which it never is. Signed-off-by:
-
Saurav Girepunje authored
Remove condition which never get execute. as pattrib->mdata is always zero before if condition check. Acked-by:
-
Michael Straube authored
Remove init_default_value from hal_ops and remove its wrapper rtw_hal_def_value_init(). Call rtl8188eu_init_default_value() directly instead Acked-by:
-
Michael Straube authored
Remove GetHalODMVarHandler from hal_ops ant remove its wrapper rtw_hal_get_odm_var(), both are unused. Acked-by:
-
Michael Straube authored
Function ReadChipVersion8188E() is only called by the wrapper rtl8188e_read_chip_version(). Rename ReadChipVersion8188E() to rtl8188e_read_chip_version() and change the return type to void since the return value is never used. Acked-by:
-
Michael Straube authored
Remove read_chip_version from hal_ops and remove its wrapper rtw_hal_read_chip_version(). Call rtl8188e_read_chip_version() directly instead Acked-by:
-
Michael Straube authored
Remove read_adapter_info from hal_ops and remove its wrapper rtw_hal_read_chip_info(). Call ReadAdapterInfo8188EU() directly instead. Acked-by:
-
Michael Straube authored
Remove intf_chip_configure from hal_ops and remove its wrapper rtw_hal_chip_configure(). Call rtl8188eu_interface_configure() directly instead. Acked-by:
-
Srivathsa Dara authored
Fix coding style error 'trailing statements should be on next line' Signed-off-by:
Srivathsa Dara <srivathsa729.8@gmail.com> Link: https://lore.kernel.org/r/20210904080916.15476-1-srivathsa729.8@gmail.comSigned-off-by:
-
Pavel Skripkin authored
psetkeyparm is kzalloced buffer, there is no need in zeroing it one more time, since kzalloc had already set memory to 0. Fixes: 15865124 ("staging: r8188eu: introduce new core dir for RTL8188eu driver") Signed-off-by:
-
Pavel Skripkin authored
Before returning with an error we should free allocated buffers, since they are not assigned to anywhere. Fixes: 15865124 ("staging: r8188eu: introduce new core dir for RTL8188eu driver") Signed-off-by:
-
Saurav Girepunje authored
Fixes coccicheck warning: Remove the condition with no effect (if == else) in odm.c Signed-off-by:
-
Michael Straube authored
Function rtw_use_tkipkey_handler() is unused, remove it. Signed-off-by:
-
Michael Straube authored
Replace custom arc4 implementation with in-kernel one. Signed-off-by:
-
Michael Straube authored
Remove unused constant CRC32_POLY. Signed-off-by:
-
Michael Straube authored
From enum hardware_type only HARDWARE_TYPE_RTL8188EU is used in the driver. Remove the enum and define HARDWARE_TYPE_RTL8188EU. Signed-off-by:
-
Michael Straube authored
The IS_HARDWARE_TYPE_8188* macros are not needed because the driver is for RTL8188EU chips, remove them. Signed-off-by:
-
Michael Straube authored
Remove unused enum rt_eeprom_type. Signed-off-by:
-
Michael Straube authored
Remove unused enum from ieee80211.h. Signed-off-by:
-
Michael Straube authored
Remove unused defines from mp_custom_oid.h. Signed-off-by:
-
Michael Straube authored
All functions declared in rtw_ioctl_rtl.h are not implemented. Remove rtw_ioctl_rtl.h and its includes. Signed-off-by:
-
Fabio Aiuto authored
when turning off a connection, lockdep complains with the following warning (a modprobe has been done but the same happens with a disconnection from NetworkManager, it's enough to trigger a cfg80211_disconnect call): [ 682.855867] ====================================================== [ 682.855877] WARNING: possible circular locking dependency detected [ 682.855887] 5.14.0-rc6+ #16 Tainted: G C OE [ 682.855898] ------------------------------------------------------ [ 682.855906] modprobe/1770 is trying to acquire lock: [ 682.855916] ffffb6d000332b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.856073] but task is already holding lock: [ 682.856081] ffffb6d0003336a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs] [ 682.856207] which lock already depends on the new lock. [ 682.856215] the existing dependency chain (in reverse order) is: [ 682.856223] -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}: [ 682.856247] _raw_spin_lock_bh+0x34/0x40 [ 682.856265] rtw_get_stainfo+0x9a/0x110 [r8723bs] [ 682.856389] rtw_xmit_classifier+0x27/0x130 [r8723bs] [ 682.856515] rtw_xmitframe_enqueue+0xa/0x20 [r8723bs] [ 682.856642] rtl8723bs_hal_xmit+0x3b/0xb0 [r8723bs] [ 682.856752] rtw_xmit+0x4ef/0x890 [r8723bs] [ 682.856879] _rtw_xmit_entry+0xba/0x350 [r8723bs] [ 682.856981] dev_hard_start_xmit+0xee/0x320 [ 682.856999] sch_direct_xmit+0x8c/0x330 [ 682.857014] __dev_queue_xmit+0xba5/0xf00 [ 682.857030] packet_sendmsg+0x981/0x1b80 [ 682.857047] sock_sendmsg+0x5b/0x60 [ 682.857060] __sys_sendto+0xf1/0x160 [ 682.857073] __x64_sys_sendto+0x24/0x30 [ 682.857087] do_syscall_64+0x3a/0x80 [ 682.857102] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 682.857117] -> #0 (&pxmitpriv->lock){+.-.}-{2:2}: [ 682.857142] __lock_acquire+0xfd9/0x1b50 [ 682.857158] lock_acquire+0xb4/0x2c0 [ 682.857172] _raw_spin_lock_bh+0x34/0x40 [ 682.857185] rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.857308] rtw_free_assoc_resources+0x53/0x110 [r8723bs] [ 682.857415] cfg80211_rtw_disconnect+0x4b/0x70 [r8723bs] [ 682.857522] cfg80211_disconnect+0x12e/0x2f0 [cfg80211] [ 682.857759] cfg80211_leave+0x2b/0x40 [cfg80211] [ 682.857961] cfg80211_netdev_notifier_call+0xa9/0x560 [cfg80211] [ 682.858163] raw_notifier_call_chain+0x41/0x50 [ 682.858180] __dev_close_many+0x62/0x100 [ 682.858195] dev_close_many+0x7d/0x120 [ 682.858209] unregister_netdevice_many+0x416/0x680 [ 682.858225] unregister_netdevice_queue+0xab/0xf0 [ 682.858240] unregister_netdev+0x18/0x20 [ 682.858255] rtw_unregister_netdevs+0x28/0x40 [r8723bs] [ 682.858360] rtw_dev_remove+0x24/0xd0 [r8723bs] [ 682.858463] sdio_bus_remove+0x31/0xd0 [mmc_core] [ 682.858532] device_release_driver_internal+0xf7/0x1d0 [ 682.858550] driver_detach+0x47/0x90 [ 682.858564] bus_remove_driver+0x77/0xd0 [ 682.858579] rtw_drv_halt+0xc/0x678 [r8723bs] [ 682.858685] __x64_sys_delete_module+0x13f/0x250 [ 682.858699] do_syscall_64+0x3a/0x80 [ 682.858715] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 682.858729] other info that might help us debug this: [ 682.858737] Possible unsafe locking scenario: [ 682.858744] CPU0 CPU1 [ 682.858751] ---- ---- [ 682.858758] lock(&pstapriv->sta_hash_lock); [ 682.858772] lock(&pxmitpriv->lock); [ 682.858786] lock(&pstapriv->sta_hash_lock); [ 682.858799] lock(&pxmitpriv->lock); [ 682.858812] *** DEADLOCK *** [ 682.858820] 5 locks held by modprobe/1770: [ 682.858831] #0: ffff8d870697d980 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x1a/0x1d0 [ 682.858869] #1: ffffffffbdbbf1c8 (rtnl_mutex){+.+.}-{3:3}, at: unregister_netdev+0xe/0x20 [ 682.858906] #2: ffff8d87054ee5e8 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: cfg80211_netdev_notifier_call+0x9e/0x560 [cfg80211] [ 682.859131] #3: ffff8d870f2bc8f0 (&wdev->mtx){+.+.}-{3:3}, at: cfg80211_leave+0x20/0x40 [cfg80211] [ 682.859354] #4: ffffb6d0003336a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs] [ 682.859482] stack backtrace: [ 682.859491] CPU: 1 PID: 1770 Comm: modprobe Tainted: G C OE 5.14.0-rc6+ #16 [ 682.859507] Hardware name: LENOVO 80NR/Madrid, BIOS DACN25WW 08/20/2015 [ 682.859517] Call Trace: [ 682.859531] dump_stack_lvl+0x56/0x6f [ 682.859551] check_noncircular+0xdb/0xf0 [ 682.859579] __lock_acquire+0xfd9/0x1b50 [ 682.859606] lock_acquire+0xb4/0x2c0 [ 682.859623] ? rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.859752] ? mark_held_locks+0x48/0x70 [ 682.859769] ? rtw_free_stainfo+0x4a/0x4a0 [r8723bs] [ 682.859898] _raw_spin_lock_bh+0x34/0x40 [ 682.859914] ? rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.860039] rtw_free_stainfo+0x52/0x4a0 [r8723bs] [ 682.860171] rtw_free_assoc_resources+0x53/0x110 [r8723bs] [ 682.860286] cfg80211_rtw_disconnect+0x4b/0x70 [r8723bs] [ 682.860397] cfg80211_disconnect+0x12e/0x2f0 [cfg80211] [ 682.860629] cfg80211_leave+0x2b/0x40 [cfg80211] [ 682.860836] cfg80211_netdev_notifier_call+0xa9/0x560 [cfg80211] [ 682.861048] ? __lock_acquire+0x4dc/0x1b50 [ 682.861070] ? lock_is_held_type+0xa8/0x110 [ 682.861089] ? lock_is_held_type+0xa8/0x110 [ 682.861104] ? find_held_lock+0x2d/0x90 [ 682.861120] ? packet_notifier+0x173/0x300 [ 682.861141] ? lock_release+0xb3/0x250 [ 682.861160] ? packet_notifier+0x192/0x300 [ 682.861184] raw_notifier_call_chain+0x41/0x50 [ 682.861205] __dev_close_many+0x62/0x100 [ 682.861224] dev_close_many+0x7d/0x120 [ 682.861245] unregister_netdevice_many+0x416/0x680 [ 682.861264] ? find_held_lock+0x2d/0x90 [ 682.861284] unregister_netdevice_queue+0xab/0xf0 [ 682.861306] unregister_netdev+0x18/0x20 [ 682.861325] rtw_unregister_netdevs+0x28/0x40 [r8723bs] [ 682.861434] rtw_dev_remove+0x24/0xd0 [r8723bs] [ 682.861542] sdio_bus_remove+0x31/0xd0 [mmc_core] [ 682.861615] device_release_driver_internal+0xf7/0x1d0 [ 682.861637] driver_detach+0x47/0x90 [ 682.861656] bus_remove_driver+0x77/0xd0 [ 682.861674] rtw_drv_halt+0xc/0x678 [r8723bs] [ 682.861782] __x64_sys_delete_module+0x13f/0x250 [ 682.861801] ? lockdep_hardirqs_on_prepare+0xf3/0x170 [ 682.861817] ? syscall_enter_from_user_mode+0x20/0x70 [ 682.861836] do_syscall_64+0x3a/0x80 [ 682.861855] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 682.861873] RIP: 0033:0x7f6dbe85400b [ 682.861890] Code: 73 01 c3 48 8b 0d 6d 1e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 1e 0c 00 f7 d8 64 89 01 48 [ 682.861906] RSP: 002b:00007ffe7a82f538 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 682.861923] RAX: ffffffffffffffda RBX: 000055a64693bd20 RCX: 00007f6dbe85400b [ 682.861935] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055a64693bd88 [ 682.861946] RBP: 000055a64693bd20 R08: 0000000000000000 R09: 0000000000000000 [ 682.861957] R10: 00007f6dbe8c7ac0 R11: 0000000000000206 R12: 000055a64693bd88 [ 682.861967] R13: 0000000000000000 R14: 000055a64693bd88 R15: 00007ffe7a831848 This happens because when we enqueue a frame for transmission we do it under xmit_priv lock, then calling rtw_get_stainfo (needed for enqueuing) takes sta_hash_lock and this leads to the following lock dependency: xmit_priv->lock -> sta_hash_lock Turning off a connection will bring to call rtw_free_assoc_resources which will set up the inverse dependency: sta_hash_lock -> xmit_priv_lock This could lead to a deadlock as lockdep complains. Fix it by removing the xmit_priv->lock around rtw_xmitframe_enqueue call inside rtl8723bs_hal_xmit and put it in a smaller critical section inside rtw_xmit_classifier, the only place where xmit_priv data are actually accessed. Replace spin_{lock,unlock}_bh(pxmitpriv->lock) in other tx paths leading to rtw_xmitframe_enqueue call with spin_{lock,unlock}_bh(psta->sleep_q.lock) - it's not clear why accessing a sleep_q was protected by a spinlock on xmitpriv->lock. This way is avoided the same faulty lock nesting order. CC: Larry Finger <Larry.Finger@lwfinger.net> Tested-on: Lenovo Ideapad MiiX 300-10IBY Signed-off-by:Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210902093559.9779-1-fabioaiuto83@gmail.comSigned-off-by:
-
