staging: r8188eu: make _rtw_init_queue a macro

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>