Enabling CONFIG_PROVE_RCU_LIST raises many warnings in wilc driver, even on
some places already protected by a read critical section. An example of
such case is in wilc_get_available_idx:
=============================
WARNING: suspicious RCU usage
6.8.0-rc1+ #32 Not tainted
-----------------------------
drivers/net/wireless/microchip/wilc1000/netdev.c:944 RCU-list traversed in non-reader section!!
[...]
stack backtrace:
CPU: 0 PID: 26 Comm: kworker/0:3 Not tainted 6.8.0-rc1+ #32
Hardware name: Atmel SAMA5
Workqueue: events_freezable mmc_rescan
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x58
dump_stack_lvl from wilc_netdev_ifc_init+0x788/0x8ec
wilc_netdev_ifc_init from wilc_cfg80211_init+0x690/0x910
wilc_cfg80211_init from wilc_sdio_probe+0x168/0x490
wilc_sdio_probe from sdio_bus_probe+0x230/0x3f4
sdio_bus_probe from really_probe+0x270/0xdf4
really_probe from __driver_probe_device+0x1dc/0x580
__driver_probe_device from driver_probe_device+0x60/0x140
driver_probe_device from __device_attach_driver+0x268/0x364
__device_attach_driver from bus_for_each_drv+0x15c/0x1cc
bus_for_each_drv from __device_attach+0x1ec/0x3e8
__device_attach from bus_probe_device+0x190/0x1c0
bus_probe_device from device_add+0x10dc/0x18e4
device_add from sdio_add_func+0x1c0/0x2c0
sdio_add_func from mmc_attach_sdio+0xa08/0xe1c
mmc_attach_sdio from mmc_rescan+0xa00/0xfe0
mmc_rescan from process_one_work+0x8d4/0x169c
process_one_work from worker_thread+0x8cc/0x1340
worker_thread from kthread+0x448/0x510
kthread from ret_from_fork+0x14/0x28
This warning is due to the section being protected by a srcu critical read
section, but the list traversal being done with classic RCU API. Fix the
warning by using corresponding SRCU read lock/unlock APIs. While doing so,
since we always manipulate the same list (managed through a pointer
embedded in struct_wilc), add a macro to reduce the corresponding
boilerplate in each call site.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240215-wilc_fix_rcu_usage-v1-2-f610e46c6f82@bootlin.com
Enabling KASAN and running some iperf tests raises some memory issues with
vmm_table:
BUG: KASAN: slab-out-of-bounds in wilc_wlan_handle_txq+0x6ac/0xdb4
Write of size 4 at addr c3a61540 by task wlan0-tx/95
KASAN detects that we are writing data beyond range allocated to vmm_table.
There is indeed a mismatch between the size passed to allocator in
wilc_wlan_init, and the range of possible indexes used later: allocation
size is missing a multiplication by sizeof(u32)
Fixes: 40b717bfce ("wifi: wilc1000: fix DMA on stack objects")
Cc: stable@vger.kernel.org
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231017-wilc1000_tx_oops-v3-1-b2155f1f7bee@bootlin.com
'vmm_table' array contains the size of data buffer length including host
header length. In 'vmm_table' array, the Zero value means the end of
vmm_entries that needs to transfer to firmware which is calculated based on
VMM free size in firmware.
Use 'vmm_table' valid entry check before fetching the entry from TX queue to
only copy valid number of entries to avoid possible NULL pointer exception
observed sometimes during large file transfers.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220504161924.2146601-5-ajay.kathat@microchip.com
For the SDIO driver, the RESET/ENABLE pins of WILC1000 are controlled
through the SDIO power sequence driver. This commit adds analogous
support for the SPI driver. Specifically, during initialization, the
chip will be ENABLEd and taken out of RESET and during
deinitialization, the chip will be placed back into RESET and disabled
(both to reduce power consumption and to ensure the WiFi radio is
off).
Both RESET and ENABLE GPIOs are optional. However, if the ENABLE GPIO
is specified, then the RESET GPIO should normally also be specified as
otherwise there is no way to ensure proper timing of the ENABLE/RESET
sequence.
Signed-off-by: David Mosberger-Tang <davidm@egauge.net>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221212531.4011609-2-davidm@egauge.net
The wakeup and sleep commands need to be sent to the WILC chip only
when it is in power save mode (PSM, as controlled by "iw dev wlan0 set
power_save on/off"). The commands are relatively costly, so it pays
to skip them when possible.
iperf3 without this patch (no significant different with PSM on/off):
TX 0.00-120.01 sec 140 MBytes 9.82 Mbits/sec
RX 0.00-120.69 sec 283 MBytes 19.6 Mbits/sec
with this patch applied:
PSM off (TX is 46% improved, RX slightly improved; may not be significant):
TX 0.00-120.00 sec 206 MBytes 14.4 Mbits/sec
RX 0.00-120.48 sec 322 MBytes 22.4 Mbits/sec
PSM on (no significant change):
TX 0.00-120.00 sec 140 MBytes 9.78 Mbits/sec
RX 0.00-120.08 sec 257 MBytes 18.0 Mbits/sec
Signed-off-by: David Mosberger-Tang <davidm@egauge.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211210203016.3680425-2-davidm@egauge.net
When deinitializing the driver, one or more "FW not responding" error
appears on the console. This appears to be due to wilc_wlan_stop()
disabling host/WILC1000 communication, but then right afterwards, it
tries to release the bus with chip-sleep enabled. The problem is
enabling the chip-sleep cannot success once host/WILC1000
communication is disabled. Fix by only releasing the bus.
Signed-off-by: David Mosberger-Tang <davidm@egauge.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211208062747.3405221-1-davidm@egauge.net
Remove unused variables to avoid the below warnings:
drivers/net/wireless/microchip/wilc1000/wlan.c: In function 'chip_wakeup':
>> drivers/net/wireless/microchip/wilc1000/wlan.c:620:34: warning: variable 'to_host_from_fw_bit' set but not used [-Wunused-but-set-variable]
620 | u32 to_host_from_fw_reg, to_host_from_fw_bit;
| ^~~~~~~~~~~~~~~~~~~
>> drivers/net/wireless/microchip/wilc1000/wlan.c:620:13: warning: variable 'to_host_from_fw_reg' set but not used [-Wunused-but-set-variable]
620 | u32 to_host_from_fw_reg, to_host_from_fw_bit;
| ^~~~~~~~~~~~~~~~~~~
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211115102809.1408267-1-ajay.kathat@microchip.com
Use the correct sequence to configure clockless registers for chip wake-up.
The following sequence is expected from WILC chip for wakeup:
- set wakeup bit in wakeup_reg register
- after setting the wakeup bit, read back the clock status bit for wakeup
complete.
For SDIO/SPI modules, the wakeup sequence is the same except uses different
register values so refactored the code to use common function for both
SDIO/SPI bus.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210916164902.74629-5-ajay.kathat@microchip.com
If the loop fails, the "while(trials--) {" loop will exit with "trials"
set to -1. The test for that expects it to end with "trials" set to 0
so the warning message will not be printed.
Fix this by changing from a post-op to a pre-op. This does mean that
we only make 99 attempts instead of 100 but that's okay.
Fixes: f135a1571a ("wilc1000: Support chip sleep over SPI")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YFS5gx/gi70zlIaO@mwanda
ac_classify() expects a struct sk_buff* as its second argument, which is
a member of struct tx_complete_data. priv happens to be a pointer to
struct tx_complete_data, so passing it directly to ac_classify() leads
to wrong behaviour and occasional panics.
Since there is only one caller of wilc_wlan_txq_add_net_pkt and it
already knows the type behind this pointer, and the structure is already
in the header file, change the function signature to use the real type
instead of void* in order to prevent confusion.
Signed-off-by: Vsevolod Kozlov <zaba@mm.st>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YCQomJ1mO5BLxYOT@Vsevolods-Mini.lan
Added multiple queues[BK,BE,VI,VO] to handle different priority data
packets. Before adding a packet to the queue, checked its priority from
the header, and then add to the suitable queue. The limit for each queue
is maintained separately. Also while passing the packets to the firmware
via VMM take care to select data packets based on priority and available
space.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201125114059.10006-6-ajay.kathat@microchip.com
