Loading
staging: r8188eu: make _rtw_init_queue a macro
While testing latest updates I hit lockdep warning:
[ 42.694425] ============================================
[ 42.694785] WARNING: possible recursive locking detected
[ 42.695120] 5.14.0+ #25 Tainted: G C
[ 42.695422] --------------------------------------------
[ 42.695747] RTW_CMD_THREAD/317 is trying to acquire lock:
[ 42.696078] ffffc900006c90b0 (&pqueue->lock){+.-.}-{3:3}, at: _rtw_alloc_network+0x1e/0x321 [r8188eu]
[ 42.696686]
[ 42.696686] but task is already holding lock:
[ 42.697148] ffffc900006c9100 (&pqueue->lock){+.-.}-{3:3}, at: rtw_update_scanned_network+0x31/0x76b [r8188eu]
[ 42.697758]
[ 42.697758] other info that might help us debug this:
[ 42.698326] Possible unsafe locking scenario:
[ 42.698326]
[ 42.698696] CPU0
[ 42.698847] ----
[ 42.698997] lock(&pqueue->lock);
[ 42.699209] lock(&pqueue->lock);
[ 42.699418]
[ 42.699418] *** DEADLOCK ***
[ 42.699418]
[ 42.699768] May be due to missing lock nesting notation
It's false positive, since all queue spinlocks are initialized via
private API which has pqueue as agrument. Fix it by making
_rtw_init_queue a macro instead of function + removed unneeded _ prefix.
Signed-off-by: 
Pavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/20210908194309.9086-1-paskripkin@gmail.com
Signed-off-by: 
Greg Kroah-Hartman <gregkh@linuxfoundation.org>