The 'channel' argument of hif_join() should never be NULL. hif_join()
does not have the responsibility to recover bug of caller.
In current code, if the argument channel is NULL, memory leaks. The new
code just emit a warning and does not give the illusion that it is
supported (and indeed a Oops will probably raise a few lines below).
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-13-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The PDS file contains antenna parameters. The file is specific to each
hardware design. Normally, the board designer should add a line in the
of_device_id table with his own antenna parameters.
Until, now the absence of PDS file is a hard fatal error. However,
during the development, in most of the cases, an empty PDS file is
sufficient to start WiFi communication.
This patch keep an error, but allow the user to play with the device.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the environment is noisy, the device may take time to send scan
requests. Thus, scan requests durations > 5s have already been observed.
During the scan, traffic is neither received, neither sent. From the
user point-of-view, the traffic is frozen for a long time.
This patch reworks the scan processing. It gives to the device a smaller
time budget than previously. However, it does not expect the scan to be
complete and it is able to send another scan request to finish the work.
A big part of the patch aims to avoid an infinite loop if the device
goes crazy.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-6-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the device has finished a scan request, it send a scan complete
("SCAN_COMPL") indication. It is also possible to abort a scan request
with a "SCAN_STOP" message. A SCAN_COMPL is also send in this case.
The driver limits the delay to make a scan request. A timeout happens
almost never but is theoretically possible. Currently, if it happens
the driver does not wait for the SCAN_COMPL. Then, when the driver
starts the next scan request, the device may return -EBUSY (scan
requests often occur back-to-back).
This patch give a chance to the device to send a SCAN_COMPL after a scan
timeout.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When multiple interface are in use. One is always AP while the other is
always station. When the two interface use the same channel, it makes no
sense to enabled Power Saving (PS) on the station. Indeed, because of
the AP, the device will be kept awake on this channel anyway.
In add, when multiple interface are in use, mac80211 does not update the
PS information and delegate to the driver responsibility to do the
right thing.
Thus, in the current code, when the user enable PS in this
configuration, the driver finally enable PS-Poll which is probably not
what the user expected.
This patch detect this case and applies a sane configuration in all
cases.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-4-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During the scan requests, the Tx traffic is suspended. This lock is
shared by all the network interfaces. So, a scan request on one
interface will block the traffic on a second interface. This causes
trouble when the queued traffic contains CAB (Content After DTIM Beacon)
since this traffic cannot be delayed.
It could be possible to make the lock local to each interface. But It
would only push the problem further. The device won't be able to send
the CAB before the end of the scan.
So, this patch just ignore the DTIM indication when a scan is in
progress. The firmware will send another indication on the next DTIM and
this time the system will be able to send the traffic just behind the
beacon.
The only drawback of this solution is that the stations connected to
the AP will wait for traffic after the DTIM for nothing. But since the
case is really rare it is not a big deal.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-3-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The wfx driver checks carefully the coherency of of the DTIM
notifications. We have noticed several times some small inconsistencies
from the firmware on these notification. They have never been critical.
However on the driver side they lead to big fat warnings. Worse, if
these warning are displayed on UART console, they can be long to display
(several hundreds of millisecs). Since, this warning is generated from a
work queue, it can delay all the workqueue users. Especially, it can
drastically slow down the frame management of the driver and then
generate errors that are serious this time (eg. an overflow of the
indication queue of the device).
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
