Age | Commit message (Collapse) | Author |
|
rtw_mlme.h has a comment which briefly describes the locking rules for
the rtl8723bs driver, improve this to also mention the locking order
of xmit_priv.lock vs the lock(s) embedded in the various queues.
Cc: Fabio Aiuto <fabioaiuto83@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220302101637.26542-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 54659ca026e5 ("staging: rtl8723bs: remove possible deadlock when
disconnect (v2)") split the locking of pxmitpriv->lock vs sleep_q/lock
into 2 locks in attempt to fix a lockdep reported issue with the locking
order of the sta_hash_lock vs pxmitpriv->lock.
But in the end this turned out to not fully solve the sta_hash_lock issue
so commit a7ac783c338b ("staging: rtl8723bs: remove a second possible
deadlock") was added to fix this in another way.
The original fix was kept as it was still seen as a good thing to have,
but now it turns out that it creates a deadlock in access-point mode:
[Feb20 23:47] ======================================================
[ +0.074085] WARNING: possible circular locking dependency detected
[ +0.074077] 5.16.0-1-amd64 #1 Tainted: G C E
[ +0.064710] ------------------------------------------------------
[ +0.074075] ksoftirqd/3/29 is trying to acquire lock:
[ +0.060542] ffffb8b30062ab00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_xmit_classifier+0x8a/0x140 [r8723bs]
[ +0.114921]
but task is already holding lock:
[ +0.069908] ffffb8b3007ab704 (&psta->sleep_q.lock){+.-.}-{2:2}, at: wakeup_sta_to_xmit+0x3b/0x300 [r8723bs]
[ +0.116976]
which lock already depends on the new lock.
[ +0.098037]
the existing dependency chain (in reverse order) is:
[ +0.089704]
-> #1 (&psta->sleep_q.lock){+.-.}-{2:2}:
[ +0.077232] _raw_spin_lock_bh+0x34/0x40
[ +0.053261] xmitframe_enqueue_for_sleeping_sta+0xc1/0x2f0 [r8723bs]
[ +0.082572] rtw_xmit+0x58b/0x940 [r8723bs]
[ +0.056528] _rtw_xmit_entry+0xba/0x350 [r8723bs]
[ +0.062755] dev_hard_start_xmit+0xf1/0x320
[ +0.056381] sch_direct_xmit+0x9e/0x360
[ +0.052212] __dev_queue_xmit+0xce4/0x1080
[ +0.055334] ip6_finish_output2+0x18f/0x6e0
[ +0.056378] ndisc_send_skb+0x2c8/0x870
[ +0.052209] ndisc_send_ns+0xd3/0x210
[ +0.050130] addrconf_dad_work+0x3df/0x5a0
[ +0.055338] process_one_work+0x274/0x5a0
[ +0.054296] worker_thread+0x52/0x3b0
[ +0.050124] kthread+0x16c/0x1a0
[ +0.044925] ret_from_fork+0x1f/0x30
[ +0.049092]
-> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[ +0.074101] __lock_acquire+0x10f5/0x1d80
[ +0.054298] lock_acquire+0xd7/0x300
[ +0.049088] _raw_spin_lock_bh+0x34/0x40
[ +0.053248] rtw_xmit_classifier+0x8a/0x140 [r8723bs]
[ +0.066949] rtw_xmitframe_enqueue+0xa/0x20 [r8723bs]
[ +0.066946] rtl8723bs_hal_xmitframe_enqueue+0x14/0x50 [r8723bs]
[ +0.078386] wakeup_sta_to_xmit+0xa6/0x300 [r8723bs]
[ +0.065903] rtw_recv_entry+0xe36/0x1160 [r8723bs]
[ +0.063809] rtl8723bs_recv_tasklet+0x349/0x6c0 [r8723bs]
[ +0.071093] tasklet_action_common.constprop.0+0xe5/0x110
[ +0.070966] __do_softirq+0x16f/0x50a
[ +0.050134] __irq_exit_rcu+0xeb/0x140
[ +0.051172] irq_exit_rcu+0xa/0x20
[ +0.047006] common_interrupt+0xb8/0xd0
[ +0.052214] asm_common_interrupt+0x1e/0x40
[ +0.056381] finish_task_switch.isra.0+0x100/0x3a0
[ +0.063670] __schedule+0x3ad/0xd20
[ +0.048047] schedule+0x4e/0xc0
[ +0.043880] smpboot_thread_fn+0xc4/0x220
[ +0.054298] kthread+0x16c/0x1a0
[ +0.044922] ret_from_fork+0x1f/0x30
[ +0.049088]
other info that might help us debug this:
[ +0.095950] Possible unsafe locking scenario:
[ +0.070952] CPU0 CPU1
[ +0.054282] ---- ----
[ +0.054285] lock(&psta->sleep_q.lock);
[ +0.047004] lock(&pxmitpriv->lock);
[ +0.074082] lock(&psta->sleep_q.lock);
[ +0.077209] lock(&pxmitpriv->lock);
[ +0.043873]
*** DEADLOCK ***
[ +0.070950] 1 lock held by ksoftirqd/3/29:
[ +0.049082] #0: ffffb8b3007ab704 (&psta->sleep_q.lock){+.-.}-{2:2}, at: wakeup_sta_to_xmit+0x3b/0x300 [r8723bs]
Analysis shows that in hindsight the splitting of the lock was not
a good idea, so revert this to fix the access-point mode deadlock.
Note this is a straight-forward revert done with git revert, the commented
out "/* spin_lock_bh(&psta_bmc->sleep_q.lock); */" lines were part of the
code before the reverted changes.
Fixes: 54659ca026e5 ("staging: rtl8723bs: remove possible deadlock when disconnect (v2)")
Cc: stable <stable@vger.kernel.org>
Cc: Fabio Aiuto <fabioaiuto83@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215542
Link: https://lore.kernel.org/r/20220302101637.26542-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Deleted the commented if blocks that weren't being used as suggested by
the maintainers.
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
Link: https://lore.kernel.org/r/b4652b7490f3574445d567ef662270605533bfa4.1640197297.git.ismayilmirzeli@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The double `for' in the comment in line 2203 is repeated. Remove one
of them from the comment.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Link: https://lore.kernel.org/r/20211211091632.264035-1-wangborong@cdjrlc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In function rtw_lps_change_dtim_hdl remove the if condition check
to compare the pwrpriv->dtim to dtim . If both are not equal dtim
is getting assign to pwrpriv->dtim. But if both are equal assigning
dtim to pwrpriv->dtim will not make any difference on value. So remove
the unnecessary if condition check.
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/YYgWHt+PpyqOv40R@Sauravs-MacBook-Air.local
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove the unused variable padapter from Efuse_Write1ByteToFakeContent
This variable is not used in the function.
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/20211105165330.78524-3-saurav.girepunje@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove the unused variable pAdapter from Efuse_Read1ByteFromFakeContent
This variable is not used in the function.
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/20211105165330.78524-2-saurav.girepunje@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
Pull exit cleanups from Eric Biederman:
"While looking at some issues related to the exit path in the kernel I
found several instances where the code is not using the existing
abstractions properly.
This set of changes introduces force_fatal_sig a way of sending a
signal and not allowing it to be caught, and corrects the misuse of
the existing abstractions that I found.
A lot of the misuse of the existing abstractions are silly things such
as doing something after calling a no return function, rolling BUG by
hand, doing more work than necessary to terminate a kernel thread, or
calling do_exit(SIGKILL) instead of calling force_sig(SIGKILL).
In the review a deficiency in force_fatal_sig and force_sig_seccomp
where ptrace or sigaction could prevent the delivery of the signal was
found. I have added a change that adds SA_IMMUTABLE to change that
makes it impossible to interrupt the delivery of those signals, and
allows backporting to fix force_sig_seccomp
And Arnd found an issue where a function passed to kthread_run had the
wrong prototype, and after my cleanup was failing to build."
* 'exit-cleanups-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (23 commits)
soc: ti: fix wkup_m3_rproc_boot_thread return type
signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed
signal: Replace force_sigsegv(SIGSEGV) with force_fatal_sig(SIGSEGV)
exit/r8188eu: Replace the macro thread_exit with a simple return 0
exit/rtl8712: Replace the macro thread_exit with a simple return 0
exit/rtl8723bs: Replace the macro thread_exit with a simple return 0
signal/x86: In emulate_vsyscall force a signal instead of calling do_exit
signal/sparc32: In setup_rt_frame and setup_fram use force_fatal_sig
signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails
exit/syscall_user_dispatch: Send ordinary signals on failure
signal: Implement force_fatal_sig
exit/kthread: Have kernel threads return instead of calling do_exit
signal/s390: Use force_sigsegv in default_trap_handler
signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved.
signal/vm86_32: Replace open coded BUG_ON with an actual BUG_ON
signal/sparc: In setup_tsb_params convert open coded BUG into BUG
signal/powerpc: On swapcontext failure force SIGSEGV
signal/sh: Use force_sig(SIGKILL) instead of do_group_exit(SIGKILL)
signal/mips: Update (_save|_restore)_fp_context to fail with -EFAULT
signal/sparc32: Remove unreachable do_exit in do_sparc_fault
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver updates from Greg KH:
"Here is the big set of staging driver updates and cleanups for
5.16-rc1.
Overall we ended up removing a lot of code this time, a bit over
20,000 lines are now gone thanks to a lot of cleanup work by many
developers.
Nothing huge in here functionality wise, just loads of cleanups:
- r8188eu driver major cleanups and removal of unused and dead code
- wlan-ng minor cleanups
- fbtft driver cleanups
- most driver cleanups
- rtl8* drivers cleanups
- rts5208 driver cleanups
- vt6655 driver cleanups
- vc04_services drivers cleanups
- wfx cleanups on the way to almost getting this merged out of
staging (it's close!)
- tiny mips changes needed for the mt7621 drivers, they have been
acked by the respective subsystem maintainers to go through this
tree.
All of these have been in linux-next for a while with no reported
issues"
* tag 'staging-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (622 commits)
staging: r8188eu: hal: remove goto statement and local variable
staging: rtl8723bs: hal remove the assignment to itself
staging: rtl8723bs: fix unmet dependency on CRYPTO for CRYPTO_LIB_ARC4
staging: vchiq_core: get rid of typedef
staging: fieldbus: anybus: reframe comment to avoid warning
staging: r8188eu: fix missing unlock in rtw_resume()
staging: r8188eu: core: remove the goto from rtw_IOL_accquire_xmit_frame
staging: r8188eu: core: remove goto statement
staging: vt6655: Rename `dwAL7230InitTable` array
staging: vt6655: Rename `dwAL2230PowerTable` array
staging: vt6655: Rename `dwAL7230InitTableAMode` array
staging: vt6655: Rename `dwAL7230ChannelTable2` array
staging: vt6655: Rename `dwAL7230ChannelTable1` array
staging: vt6655: Rename `dwAL7230ChannelTable0` array
staging: vt6655: Rename `dwAL2230ChannelTable1` array
staging: vt6655: Rename `dwAL2230ChannelTable0` array
staging: r8712u: fix control-message timeout
staging: rtl8192u: fix control-message timeouts
staging: mt7621-dts: add missing SPDX license to files
staging: vchiq_core: fix quoted strings split across lines
...
|
|
Remove the assignment of variable to itself.
Assigning the variable to itself not make any difference on value.
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/YXoq2ViLxPVwAgLq@Sauravs-MacBook-Air.local
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When RTL8723BS is selected, and CRYPTO is not selected,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for CRYPTO_LIB_ARC4
Depends on [n]: CRYPTO [=n]
Selected by [m]:
- RTL8723BS [=m] && STAGING [=y] && WLAN [=y] && MMC [=y] && CFG80211 [=y] && m && MODULES [=y]
- RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m]
This is because RTL8723BS selects CRYPTO_LIB_ARC4
without selecting CRYPTO, despite CRYPTO_LIB_ARC4
depending on CRYPTO.
This unmet dependency bug was detected by Kismet,
a static analysis tool for Kconfig. Please advise
if this is not the appropriate solution.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://lore.kernel.org/r/20211029214244.17341-1-julianbraha@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Every place thread_exit is called is at the end of a function started
with kthread_run. The code in kthread_run has arranged things so a
kernel thread can just return and do_exit will be called.
So just have the threads return instead of calling complete_and_exit.
Link: https://lkml.kernel.org/r/20211020174406.17889-18-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
Remove useless blank lines
Signed-off-by: Kushal Kothari <kushalkothari285@gmail.com>
Link: https://lore.kernel.org/r/78aabc0031d43c21ef06ae8d70f79412142d0784.1634967010.git.kushalkothari285@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove useless space after cast
Signed-off-by: Kushal Kothari <kushalkothari285@gmail.com>
Link: https://lore.kernel.org/r/baa1703e0c202dfb90e215b63b535161bd3ccccb.1634967010.git.kushalkothari285@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Issue found with checkpatch.pl.
CHECK: Remove unnecessary parentheses
Signed-off-by: Kushal Kothari <kushalkothari285@gmail.com>
Link: https://lore.kernel.org/r/f4df671b9bf23f9e8995dd03472a520d40377d7a.1634967010.git.kushalkothari285@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove comparison to true and false in if statement.
Issue found with checkpatch.pl.
CHECK: Using comparison to true is error prone
CHECK: Using comparison to false is error prone
Signed-off-by: Kushal Kothari <kushalkothari285@gmail.com>
Link: https://lore.kernel.org/r/47dd38847c4e36742f88f4493773fef602ca079b.1634967010.git.kushalkothari285@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove comparison to true and false in if statement.
Issue found with checkpatch.pl.
CHECK: Using comparison to true is error prone
CHECK: Using comparison to false is error prone
Signed-off-by: Kushal Kothari <kushalkothari285@gmail.com>
Link: https://lore.kernel.org/r/20211020115621.132500-1-kushalkothari285@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20211019171243.1412240-8-kuba@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Convert staging drivers from memcpy(... ETH_ADDR) to eth_hw_addr_set():
@@
expression dev, np;
@@
- memcpy(dev->dev_addr, np, ETH_ALEN)
+ eth_hw_addr_set(dev, np)
@@
- memcpy(dev->dev_addr, np, 6)
+ eth_hw_addr_set(dev, np)
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20211019171243.1412240-2-kuba@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The 0-element arrays that are used as memcpy() destinations are actually
flexible arrays. Adjust their structures accordingly so that memcpy()
can better reason able their destination size (i.e. they need to be seen
as "unknown" length rather than "zero").
In some cases, use of the DECLARE_FLEX_ARRAY() helper is needed when a
flexible array is alone in a struct.
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Manish Rangankar <mrangankar@marvell.com>
Cc: GR-QLogic-Storage-Upstream@marvell.com
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Phillip Potter <phil@philpotter.co.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Florian Schilhabel <florian.c.schilhabel@googlemail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Fabio Aiuto <fabioaiuto83@gmail.com>
Cc: Ross Schmidt <ross.schm.dev@gmail.com>
Cc: Marco Cesati <marcocesati@gmail.com>
Cc: ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-staging@lists.linux.dev
Signed-off-by: Kees Cook <keescook@chromium.org>
|
|
Remove 'bPerformance' from if condition check. As on previous
if condition it is already check for same variable.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/YWKRfYpTioAmTWa0@user
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove reassignment of same value to variable pstat->auth_seq.
On if (seq == 1) assigning the value 2. At the end of if statement
also assigning the value pstat->auth_seq = seq + 1 that is again
assigning the value 2.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/YVnX1HIYoisW621x@user
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove condition which never get execute.
as pattrib->mdata is always zero before if condition check.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/YVnTJCoz2qsXDXGc@user
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
One-element and zero-length arrays are deprecated and should be
replaced with flexible-array members[1].
Replace zero-length array with flexible-array member and make use
of the struct_size() helper.
[1] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/78
Link: https://github.com/KSPP/linux/issues/160
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20210929194118.GA340431@embeddedor
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
kfree(NULL) is safe and the check 'if (pstat->passoc_req)' before kfree
is not necessary.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Longji Guo <guolongji@uniontech.com>
Link: https://lore.kernel.org/r/20210929110613.29979-1-guolongji@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:
[ 363.139361] ======================================================
[ 363.139377] WARNING: possible circular locking dependency detected
[ 363.139396] 5.15.0-rc1+ #470 Tainted: G C E
[ 363.139413] ------------------------------------------------------
[ 363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[ 363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[ 363.139598]
but task is already holding lock:
[ 363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[ 363.139673]
which lock already depends on the new lock.
[ 363.139684]
the existing dependency chain (in reverse order) is:
[ 363.139696]
-> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[ 363.139734] del_timer_sync+0x59/0x100
[ 363.139762] rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[ 363.139870] report_join_res+0xdf/0x110 [r8723bs]
[ 363.139980] OnAssocRsp+0x17a/0x200 [r8723bs]
[ 363.140092] rtw_recv_entry+0x190/0x1120 [r8723bs]
[ 363.140209] rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[ 363.140318] tasklet_action_common.constprop.0+0xe8/0x110
[ 363.140345] __do_softirq+0xde/0x485
[ 363.140372] __irq_exit_rcu+0xd0/0x100
[ 363.140393] irq_exit_rcu+0xa/0x20
[ 363.140413] common_interrupt+0x83/0xa0
[ 363.140440] asm_common_interrupt+0x1e/0x40
[ 363.140463] finish_task_switch.isra.0+0x157/0x3d0
[ 363.140492] __schedule+0x447/0x1880
[ 363.140516] schedule+0x59/0xc0
[ 363.140537] smpboot_thread_fn+0x161/0x1c0
[ 363.140565] kthread+0x143/0x160
[ 363.140585] ret_from_fork+0x22/0x30
[ 363.140614]
-> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[ 363.140653] _raw_spin_lock_bh+0x34/0x40
[ 363.140675] rtw_free_network_queue+0x31/0x80 [r8723bs]
[ 363.140776] rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[ 363.140869] rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[ 363.140973] rdev_scan+0x42/0x1a0 [cfg80211]
[ 363.141307] nl80211_trigger_scan+0x566/0x660 [cfg80211]
[ 363.141635] genl_family_rcv_msg_doit+0xcd/0x110
[ 363.141661] genl_rcv_msg+0xce/0x1c0
[ 363.141680] netlink_rcv_skb+0x50/0xf0
[ 363.141699] genl_rcv+0x24/0x40
[ 363.141717] netlink_unicast+0x16d/0x230
[ 363.141736] netlink_sendmsg+0x22b/0x450
[ 363.141755] sock_sendmsg+0x5e/0x60
[ 363.141781] ____sys_sendmsg+0x22f/0x270
[ 363.141803] ___sys_sendmsg+0x81/0xc0
[ 363.141828] __sys_sendmsg+0x49/0x80
[ 363.141851] do_syscall_64+0x3b/0x90
[ 363.141873] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 363.141895]
-> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[ 363.141930] __lock_acquire+0x1158/0x1de0
[ 363.141954] lock_acquire+0xb5/0x2b0
[ 363.141974] _raw_spin_lock_bh+0x34/0x40
[ 363.141993] _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[ 363.142097] call_timer_fn+0x94/0x260
[ 363.142122] __run_timers.part.0+0x1bf/0x290
[ 363.142147] run_timer_softirq+0x26/0x50
[ 363.142171] __do_softirq+0xde/0x485
[ 363.142193] __irq_exit_rcu+0xd0/0x100
[ 363.142215] irq_exit_rcu+0xa/0x20
[ 363.142235] sysvec_apic_timer_interrupt+0x72/0x90
[ 363.142260] asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 363.142283] __module_address.part.0+0x0/0xd0
[ 363.142309] is_module_address+0x25/0x40
[ 363.142334] static_obj+0x4f/0x60
[ 363.142361] lockdep_init_map_type+0x47/0x220
[ 363.142382] __init_swait_queue_head+0x45/0x60
[ 363.142408] mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[ 363.142504] mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[ 363.142592] mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[ 363.142691] sdio_writeb+0x2e/0x50 [mmc_core]
[ 363.142788] _sd_cmd52_write+0x62/0x80 [r8723bs]
[ 363.142885] sd_cmd52_write+0x6c/0xb0 [r8723bs]
[ 363.142981] rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[ 363.143089] rtw_write16+0x1e/0x30 [r8723bs]
[ 363.143184] SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[ 363.143294] mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[ 363.143405] rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[ 363.143507] mlme_evt_hdl+0x4d/0x70 [r8723bs]
[ 363.143620] rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[ 363.143712] kthread+0x143/0x160
[ 363.143732] ret_from_fork+0x22/0x30
[ 363.143757]
other info that might help us debug this:
[ 363.143768] Chain exists of:
&pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)
[ 363.143809] Possible unsafe locking scenario:
[ 363.143819] CPU0 CPU1
[ 363.143831] ---- ----
[ 363.143841] lock((&pmlmepriv->assoc_timer));
[ 363.143862] lock(&pmlmepriv->scanned_queue.lock);
[ 363.143882] lock((&pmlmepriv->assoc_timer));
[ 363.143902] lock(&pmlmepriv->lock);
[ 363.143921]
*** DEADLOCK ***
Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:
[ 103.849756] ======================================================
[ 103.849761] WARNING: possible circular locking dependency detected
[ 103.849767] 5.15.0-rc1+ #470 Tainted: G C E
[ 103.849773] ------------------------------------------------------
[ 103.849776] wpa_supplicant/695 is trying to acquire lock:
[ 103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[ 103.849840]
but task is already holding lock:
[ 103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[ 103.849881]
which lock already depends on the new lock.
[ 103.849884]
the existing dependency chain (in reverse order) is:
[ 103.849887]
-> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[ 103.849898] _raw_spin_lock_bh+0x34/0x40
[ 103.849913] rtw_get_stainfo+0x93/0x110 [r8723bs]
[ 103.849948] rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[ 103.849983] rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[ 103.850019] rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[ 103.850050] kthread+0x143/0x160
[ 103.850058] ret_from_fork+0x22/0x30
[ 103.850067]
-> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[ 103.850077] __lock_acquire+0x1158/0x1de0
[ 103.850084] lock_acquire+0xb5/0x2b0
[ 103.850090] _raw_spin_lock_bh+0x34/0x40
[ 103.850095] rtw_free_stainfo+0x8a/0x510 [r8723bs]
[ 103.850130] rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[ 103.850159] PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[ 103.850189] cfg80211_disconnect+0x173/0x320 [cfg80211]
[ 103.850331] nl80211_disconnect+0x6e/0xb0 [cfg80211]
[ 103.850422] genl_family_rcv_msg_doit+0xcd/0x110
[ 103.850430] genl_rcv_msg+0xce/0x1c0
[ 103.850435] netlink_rcv_skb+0x50/0xf0
[ 103.850441] genl_rcv+0x24/0x40
[ 103.850446] netlink_unicast+0x16d/0x230
[ 103.850452] netlink_sendmsg+0x22b/0x450
[ 103.850457] sock_sendmsg+0x5e/0x60
[ 103.850465] ____sys_sendmsg+0x22f/0x270
[ 103.850472] ___sys_sendmsg+0x81/0xc0
[ 103.850479] __sys_sendmsg+0x49/0x80
[ 103.850485] do_syscall_64+0x3b/0x90
[ 103.850493] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 103.850500]
other info that might help us debug this:
[ 103.850504] Possible unsafe locking scenario:
[ 103.850507] CPU0 CPU1
[ 103.850510] ---- ----
[ 103.850512] lock(&pstapriv->sta_hash_lock);
[ 103.850518] lock(&pxmitpriv->lock);
[ 103.850524] lock(&pstapriv->sta_hash_lock);
[ 103.850530] lock(&pxmitpriv->lock);
[ 103.850535]
*** DEADLOCK ***
Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.
This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.
Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.
Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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.
Extra changes in v2 by Hans de Goede:
-Lift the taking of the struct __queue.lock spinlock out of
rtw_free_xmitframe_queue() into the callers this allows also
protecting a bunch of related state in rtw_free_stainfo():
-Protect psta->sleepq_len on rtw_free_xmitframe_queue(&psta->sleep_q);
-Protect struct tx_servq.tx_pending and tx_servq.qcnt when
calling rtw_free_xmitframe_queue(&tx_servq.sta_pending)
-This also allows moving the spin_lock_bh(&pxmitpriv->lock); to below
the sleep_q free-ing code, avoiding another ABBA locking issue
CC: Larry Finger <Larry.Finger@lwfinger.net>
Co-developed-by: Hans de Goede <hdegoede@redhat.com>
Tested-on: Lenovo Ideapad MiiX 300-10IBY
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The wake-on-wlan stub is unused when the device power management
functionality is disabled in the kernel, creating a warning when
building the driver.
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:50:42: warning: ‘wowlan_stub’ defined but not used [-Wunused-const-variable=]
Add the __maybe_unused annotation to silence this warning.
Signed-off-by: Bryan Brattlof <hello@bryanbrattlof.com>
Link: https://lore.kernel.org/r/20210916231928.2021584-1-hello@bryanbrattlof.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 78a1614a81f06032055a25b7acd9965a81196433.
There's been attempts to fix this, but it's not quite right yet, so just
remove the original commit.
Link: https://lore.kernel.org/r/20210913130346.2390-1-fabioaiuto83@gmail.com
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Fabio Aiuto <fabioaiuto83@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
These macros are not used in the driver, remove them.
Found with GCC -Wunused-macros.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20210909211922.24872-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Clean up comparsions to NULL reported by checkpatch.
x == NULL -> !x
x != NULL -> x
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20210829154533.11054-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove _rtw_init_queue() left unused by previous commit
in this series.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/3c03fcfbe799195c84608b05fc54efe921bef4de.1630307025.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Fix the following post commit hook checkpatch issues:
CHECK: Unnecessary parentheses around pcmdpriv->cmd_queue
103: FILE: drivers/staging/rtl8723bs/core/rtw_cmd.c:169:
+ INIT_LIST_HEAD(&(pcmdpriv->cmd_queue).queue);
CHECK: Unnecessary parentheses around pcmdpriv->cmd_queue
104: FILE: drivers/staging/rtl8723bs/core/rtw_cmd.c:170:
+ spin_lock_init(&(pcmdpriv->cmd_queue).lock);
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/de4fcdb3ff45671333713b27f1dcf376b22f3978.1630307025.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
unwrap initialization of queues to avoid false positive
lockdep warning:
[ 27.350258] ============================================
[ 27.350267] WARNING: possible recursive locking detected
[ 27.350276] 5.14.0-rc6+ #16 Tainted: G C OE
[ 27.350288] --------------------------------------------
[ 27.350295] RTW_CMD_THREAD/679 is trying to acquire lock:
[ 27.350306] ffffa846c03290c8 (&(pqueue->lock)){+.-.}-{2:2},
at: rtw_alloc_network+0x1b/0xa0 [r8723bs]
[ 27.350441]
but task is already holding lock:
[ 27.350448] ffffa846c0329118 (&(pqueue->lock)){+.-.}-{2:2},
at: rtw_update_scanned_network+0x33/0x1d0 [r8723bs]
[ 27.350573]
other info that might help us debug this:
[ 27.350581] Possible unsafe locking scenario:
[ 27.350588] CPU0
[ 27.350594] ----
[ 27.350600] lock(&(pqueue->lock));
[ 27.350614] lock(&(pqueue->lock));
[ 27.350627]
*** DEADLOCK ***
[ 27.350634] May be due to missing lock nesting notation
[ 27.350641] 2 locks held by RTW_CMD_THREAD/679:
[ 27.350652] #0: ffffa846c0329038 (&pmlmepriv->lock){+...}-{2:2},
at: rtw_survey_event_callback+0x2d/0xe0 [r8723bs]
[ 27.350780] #1: ffffa846c0329118 (&(pqueue->lock)){+.-.}-{2:2},
at: rtw_update_scanned_network+0x33/0x1d0 [r8723bs]
[ 27.350907]
stack backtrace:
[ 27.350916] CPU: 3 PID: 679 Comm: RTW_CMD_THREAD Tainted: G
C OE 5.14.0-rc6+ #16
[ 27.350933] Hardware name: LENOVO 80NR/Madrid, BIOS DACN25WW
08/20/2015
[ 27.350943] Call Trace:
[ 27.350959] dump_stack_lvl+0x56/0x6f
[ 27.350982] __lock_acquire.cold.79+0x137/0x298
[ 27.351012] lock_acquire+0xb4/0x2c0
[ 27.351031] ? rtw_alloc_network+0x1b/0xa0 [r8723bs]
[ 27.351140] ? rtw_update_scanned_network+0x33/0x1d0 [r8723bs]
[ 27.351254] _raw_spin_lock_bh+0x34/0x40
[ 27.351271] ? rtw_alloc_network+0x1b/0xa0 [r8723bs]
[ 27.351378] rtw_alloc_network+0x1b/0xa0 [r8723bs]
[ 27.351488] rtw_update_scanned_network+0xa5/0x1d0 [r8723bs]
[ 27.351605] rtw_survey_event_callback+0x54/0xe0 [r8723bs]
[ 27.351719] mlme_evt_hdl+0x4e/0x70 [r8723bs]
[ 27.351839] rtw_cmd_thread+0x16c/0x3d0 [r8723bs]
[ 27.351945] ? rtw_stop_cmd_thread+0x50/0x50 [r8723bs]
[ 27.352045] kthread+0x136/0x160
[ 27.352064] ? set_kthread_struct+0x40/0x40
[ 27.352083] ret_from_fork+0x22/0x30
This happens because the wrapping function _rtw_init_queues()
bring lockdep considering all queues as a single one. But
all queues are different with their own lock.
Applied the following semantic patch:
@@
expression a;
@@
- _rtw_init_queue(&a);
+ INIT_LIST_HEAD(&a.queue);
+ spin_lock_init(&a.lock);
Reported-by: Hans De Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/c2c3a18cc2b883feab74f150ccbaa4f2cc11995c.1630307025.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The header file ehternet.h defines only two constants.
#define ETHERNET_HEADER_SIZE 14 /* Ethernet Header Length */
#define LLC_HEADER_SIZE 6 /* LLC Header Length */
Both are only used in the file core/rtw_recv.c and ETHERNET_HEADER_SIZE
just duplicates the in-kernel constant ETH_HLEN. Replace the usage of
ETHERNET_HEADER_SIZE with ETH_HLEN, move the definition of LLC_HEADER_SIZE
into rtw_rev.h (renamed to LLC_HEADER_LENGTH) and remove the now unused
header file ethernet.h.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20210825100842.13217-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove rtw_set_802_11_bssid() function left unused
after wext routines removal.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/b3d1756b6ae4be7ca4fc50e12bd7e10587a6020c.1629727333.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove functions that once were meant to notify
wext events to userspace. Now they are donig nothing
useful so just remove them.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/0d745350ff3d411dda329b8c1e2261361570db6e.1629727333.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
fix the following post-commit hook checkpatch issue:
CHECK: Logical continuations should be on the previous line
52: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:389:
+ if (padapter->securitypriv.dot11PrivacyAlgrthm == _TKIP_
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _TKIP_WTMIC_
CHECK: Logical continuations should be on the previous line
53: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:390:
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _TKIP_WTMIC_
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _AES_)
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/5d4e7ab18005e69e8cc162619149d6fa93568875.1629727333.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
fix the following post commit hook checkpatch issues:
ERROR: code indent should use tabs where possible
2463: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:388:
+ if (padapter->securitypriv.dot11PrivacyAlgrthm == _TKIP_$
ERROR: code indent should use tabs where possible
2464: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:389:
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _TKIP_WTMIC_$
ERROR: code indent should use tabs where possible
2465: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:390:
+ || padapter->securitypriv.dot11PrivacyAlgrthm == _AES_)$
ERROR: code indent should use tabs where possible
2466: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:391:
+ /* WPS open need to enable multicast */$
ERROR: code indent should use tabs where possible
2467: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:392:
+ /* check_fwstate(&padapter->mlmepriv,
WIFI_UNDER_WPS) == true) */$
ERROR: code indent should use tabs where possible
2468: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:393:
+ rtw_hal_set_hwreg(padapter, HW_VAR_OFF_RCR_AM,
null_addr);$
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/aa394052c8d81b4a00356adf5f98fc3c81f8b1d9.1629727333.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
cfg80211 has been fully implemented so
remove all wext and wext private handlers and their
registration.
Now wext userspace calls can be managed via
cfg80211 wext compatibility.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/61c4bb20bbb6ce30e4ddd01aa73de3f686a99445.1629727333.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove below unused static variable from os_intfs.c
rtw_enusbss
rtw_hwpdn_mode
rtw_hwpwrp_detect
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/20210807102232.6674-5-saurav.girepunje@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove unused RF_*T*R enum, for rtl8723bs is
only capable of 1T1R rf path so selection is not needed.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/2f2f185a80fbec71af4a165180ed0156d194c96e.1628329348.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
fix sizes of tx power tables to the real used
values (i.e. 2 bandwidth, 3 rate sections).
Delete MAX_BASE_NUM_IN_PHY_REG_PG_2_4 macro in
this process, for it expands to a larger than
needed rate section index value.
Modify comments accordingly.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/5f52295a8b17f68ad80ffb7b6301da83bfc11a68.1628329348.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
use MAX_RF_PATH_NUM as ceiling to rf path index.
Only 2 rf paths are used, not 4. Remove also
TX_POWER_BY_RATE_NUM_RF left unused.
Use RF_PATH_A as loop starting point instead of
hardcoded 0, as in other places.
Related comments modified accordingly.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/88da23cef57131b39a63b2757b91f959553dd65d.1628329348.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove RF_*TX enum, its only used value is RF_1TX.
So remove it and remove all indexes and loop over
these enum items.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/3acc624742a933d90e83a83babb4eecb193cf869.1628329348.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove unused macro in include/hal_data.h
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/13b4f41247d1b8bc10f0576d82e4dc9a285d88e1.1628329348.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove unused rtw_rf_config module param and struct field
used to store the param value.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/a83eaa9b2350d3d16f5b1dddc40870e0f0a6df06.1628329348.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
remove all function calls to rtw_get_hw_reg made to
read HW_VAR_RF_TYPE and get value of rt_type, which
is always 1T1R. Clean up code on removal sites,
keeping 1T1R code unconditionally.
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/8ca2f788c42d81b9cb4dbc46e23c7549dc27d081.1628329348.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|