Hi Luca,
On 29.11.2020 16:30, Luca Coelho wrote:
> From: Ilan Peer <ilan.peer@xxxxxxxxx>
>
> When custom regulatory was set, only the channels setting was updated, but
> the regulatory domain was not saved. Fix it by saving it.
>
> Signed-off-by: Ilan Peer <ilan.peer@xxxxxxxxx>
> Signed-off-by: Luca Coelho <luciano.coelho@xxxxxxxxx>
This patch landed recently in linux-next as commit beee24695157
("cfg80211: Save the regulatory domain when setting custom regulatory").
It triggers the following warning on all boards I have, which use
Broadcom chips. Here is an example from Raspberry Pi4:
cfg80211: Loading compiled-in X.509 certificates for regulatory database
cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip
BCM4345/6
brcmfmac mmc1:0001:1: Direct firmware load for
brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2
brcmfmac mmc1:0001:1: Falling back to sysfs fallback for:
brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip
BCM4345/6
brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11),
device may have limited channels available
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 1 2015
07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
Bluetooth: hci0: BCM: chip id 107
Bluetooth: hci0: BCM: features 0x2f
Bluetooth: hci0: BCM4345C0
Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.hcd' Patch
=============================
WARNING: suspicious RCU usage
5.10.0-next-20201215+ #9962 Not tainted
-----------------------------
net/wireless/reg.c:144 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by kworker/1:1/32:
#0: ffff000003405738 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x200/0x728
#1: ffff80001321bdc0 ((work_completion)(&fw_work->work)){+.+.}-{0:0},
at: process_one_work+0x200/0x728
stack backtrace:
CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.10.0-next-20201215+ #9962
Hardware name: Raspberry Pi 4 Model B (DT)
Workqueue: events request_firmware_work_func
Call trace:
dump_backtrace+0x0/0x1d0
show_stack+0x14/0x60
dump_stack+0xf4/0x15c
lockdep_rcu_suspicious+0xd4/0xf8
get_wiphy_regdom+0x6c/0x70 [cfg80211]
wiphy_apply_custom_regulatory+0x80/0xc8 [cfg80211]
brcmf_cfg80211_attach+0xb44/0x1330 [brcmfmac]
brcmf_attach+0x174/0x4b8 [brcmfmac]
brcmf_sdio_firmware_callback+0x670/0x7c8 [brcmfmac]
brcmf_fw_request_done+0x7c/0x100 [brcmfmac]
request_firmware_work_func+0x4c/0xd8
process_one_work+0x2a8/0x728
worker_thread+0x48/0x460
kthread+0x134/0x160
ret_from_fork+0x10/0x18
Reverting this patch on top of linux next-20201215 hides this issue.
I compiled kernel for arm64 with defconfig with some additional options
(I left only those that might be relevant to this issue):
./scripts/config --set-val CMA_SIZE_MBYTES 96 -e PROVE_LOCKING -e
DEBUG_ATOMIC_SLEEP -e COMPILE_TEST -e PM_DEBUG -e PM_ADVANCED_DEBUG -e
CONFIG_BRCMFMAC_PCIE
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
