staging: r8188eu: remove _rtw_mutex_{init,free}
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 <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/20210904124747.30050-1-paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>