forked from Minki/linux
c70ca8cb9a
Releasing the scan_pending lock in mwifiex_check_next_scan_command introduces a short window where pending scan commands can be removed or added before removing them all in mwifiex_cancel_pending_scan_cmd. I think this is safe, since the worst thing to happen is that a pending scan cmd is removed by the command handler. Adding new scan commands is not possible while one is pending, see scan_processing flag. Since all commands are removed from the queue anyway, we don't care if some commands are removed by a different code path earlier, the final state remains the same. I assume, that the critical section needed for the check has been extended over clearing the pending scan queue out of convenience. The lock was already held and releasing it and grab it again was just more work. It doesn't seem to be necessary because of concurrency. Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> |
||
|---|---|---|
| .. | ||
| admtek | ||
| ath | ||
| atmel | ||
| broadcom | ||
| cisco | ||
| intel | ||
| intersil | ||
| marvell | ||
| mediatek | ||
| ralink | ||
| realtek | ||
| rsi | ||
| st | ||
| ti | ||
| zydas | ||
| Kconfig | ||
| mac80211_hwsim.c | ||
| mac80211_hwsim.h | ||
| Makefile | ||
| ray_cs.c | ||
| ray_cs.h | ||
| rayctl.h | ||
| rndis_wlan.c | ||
| wl3501_cs.c | ||
| wl3501.h | ||