[ Upstream commit baaf965f94308301d2dc554d72a87d7432cd5ce6 ]
The following KASAN BUG is observed when testing the rpc-if driver on
rcar-gen3:
root@rcar-gen3:~# modprobe -r rpc-if
[ 101.930146] ==================================================================
[ 101.937408] BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x518/0x25d0
[ 101.944240] Read of size 8 at addr ffff0004c5be2750 by task modprobe/664
[ 101.950959]
[ 101.952466] CPU: 2 PID: 664 Comm: modprobe Not tainted 5.14.0-rc1-00342-g1a1464d7aa31 #1
[ 101.960578] Hardware name: Renesas H3ULCB board based on r8a77951 (DT)
[ 101.967120] Call trace:
[ 101.969580] dump_backtrace+0x0/0x2c0
[ 101.973275] show_stack+0x1c/0x30
[ 101.976616] dump_stack_lvl+0x9c/0xd8
[ 101.980301] print_address_description.constprop.0+0x74/0x2b8
[ 101.986071] kasan_report+0x1f4/0x26c
[ 101.989757] __asan_load8+0x98/0xd4
[ 101.993266] __lock_acquire+0x518/0x25d0
[ 101.997215] lock_acquire.part.0+0x18c/0x360
[ 102.001506] lock_acquire+0x74/0x90
[ 102.005013] _raw_spin_lock_irq+0x98/0x130
[ 102.009131] __pm_runtime_disable+0x30/0x210
[ 102.013427] rpcif_hb_remove+0x5c/0x70 [rpc_if]
[ 102.018001] platform_remove+0x40/0x80
[ 102.021771] __device_release_driver+0x234/0x350
[ 102.026412] driver_detach+0x158/0x20c
[ 102.030179] bus_remove_driver+0xa0/0x140
[ 102.034212] driver_unregister+0x48/0x80
[ 102.038153] platform_driver_unregister+0x18/0x24
[ 102.042879] rpcif_platform_driver_exit+0x1c/0x34 [rpc_if]
[ 102.048400] __arm64_sys_delete_module+0x210/0x310
[ 102.053212] invoke_syscall+0x60/0x190
[ 102.056986] el0_svc_common+0x12c/0x144
[ 102.060844] do_el0_svc+0x88/0xac
[ 102.064181] el0_svc+0x24/0x3c
[ 102.067257] el0t_64_sync_handler+0x1a8/0x1b0
[ 102.071634] el0t_64_sync+0x198/0x19c
[ 102.075315]
[ 102.076815] Allocated by task 628:
[ 102.080781]
[ 102.082280] Last potentially related work creation:
[ 102.087524]
[ 102.089022] The buggy address belongs to the object at ffff0004c5be2000
[ 102.089022] which belongs to the cache kmalloc-2k of size 2048
[ 102.101555] The buggy address is located 1872 bytes inside of
[ 102.101555] 2048-byte region [ffff0004c5be2000, ffff0004c5be2800)
[ 102.113486] The buggy address belongs to the page:
[ 102.118409]
[ 102.119908] Memory state around the buggy address:
[ 102.124711] ffff0004c5be2600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.131947] ffff0004c5be2680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.139181] >ffff0004c5be2700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.146412] ^
[ 102.152257] ffff0004c5be2780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.159491] ffff0004c5be2800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.166723] ==================================================================
The above bug is caused by use of the wrong pointer in the
rpcif_disable_rpm() call. Fix the bug by using the correct pointer.
Fixes: 5de15b610f ("mtd: hyperbus: add Renesas RPC-IF driver")
Signed-off-by: George G. Davis <davis.george@siemens.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210716204935.25859-1-george_davis@mentor.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e9c195aaeed1b45c9012adbe29dedb6031e85aa8 ]
Pointer alg points to sub field of tmpl, it
is dereferenced after tmpl is freed. Fix
this by accessing alg before free tmpl.
Fixes: ec8f5d8f ("crypto: qce - Qualcomm crypto engine driver")
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
Acked-by: Thara Gopinath <thara.gopinath@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b4cb4d31631912842eb7dce02b4350cbb7562d5e ]
Pointer base points to sub field of tmpl, it
is dereferenced after tmpl is freed. Fix
this by accessing base before free tmpl.
Fixes: ec8f5d8f ("crypto: qce - Qualcomm crypto engine driver")
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
Acked-by: Thara Gopinath <thara.gopinath@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4a9dbd021970ffe1b92521328377b699acba7c52 ]
Pointer alg points to sub field of tmpl, it
is dereferenced after tmpl is freed. Fix
this by accessing alg before free tmpl.
Fixes: 9363efb4 ("crypto: qce - Add support for AEAD algorithms")
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
Acked-by: Thara Gopinath <thara.gopinath@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6d48de655917a9d782953eba65de4e3db593ddf0 ]
In case there were more requests from different tfms in the crypto
queue, only the context of the last initialized tfm was considered.
Fixes: ec2088b66f ("crypto: atmel-aes - Allocate aes dev at tfm init time")
Reported-by: Wolfgang Ocker <weo@reccoware.de>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ab599eb11882f834951c436cc080c3455ba32b9b ]
I got a use-after-free report:
dvbdev: dvb_register_device: failed to create device dvb1.dvr0 (-12)
...
==================================================================
BUG: KASAN: use-after-free in dvb_dmxdev_release+0xce/0x2f0
...
Call Trace:
dump_stack_lvl+0x6c/0x8b
print_address_description.constprop.0+0x48/0x70
kasan_report.cold+0x82/0xdb
__asan_load4+0x6b/0x90
dvb_dmxdev_release+0xce/0x2f0
...
Allocated by task 7666:
kasan_save_stack+0x23/0x50
__kasan_kmalloc+0x83/0xa0
kmem_cache_alloc_trace+0x22e/0x470
dvb_register_device+0x12f/0x980
dvb_dmxdev_init+0x1f3/0x230
...
Freed by task 7666:
kasan_save_stack+0x23/0x50
kasan_set_track+0x20/0x30
kasan_set_free_info+0x24/0x40
__kasan_slab_free+0xf2/0x130
kfree+0xd1/0x5c0
dvb_register_device.cold+0x1ac/0x1fa
dvb_dmxdev_init+0x1f3/0x230
...
When dvb_register_device() in dvb_dmxdev_init() fails, dvb_dmxdev_init()
does not return a failure, and the memory pointed to by dvbdev or
dvr_dvbdev is invalid at this point. If they are used subsequently, it
will result in UFA or null-ptr-deref.
If dvb_register_device() in dvb_dmxdev_init() fails, fix the bug by making
dvb_dmxdev_init() return an error as well.
Link: https://lore.kernel.org/linux-media/20211015085741.1203283-1-wanghai38@huawei.com
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e1a9faddffe7e555304dc2e3284c84fbee0679ee ]
The CAT875 sub board from Silicon Linux uses a Realtek PHY.
The phy driver commit bbc4d71d63 ("net: phy: realtek: fix
rtl8211e rx/tx delay config") introduced NFS mount failures. Now it
needs both rx/tx delays for the NFS mount to work.
This patch fixes the NFS mount failure issue by adding "rgmii-id" mode
to the avb device node.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Fixes: bbc4d71d63 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
Link: https://lore.kernel.org/r/20211115142830.12651-1-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 081e2d6476e30399433b509684d5da4d1844e430 ]
Wakeup mhi is needed before pci_read/write only for QCA6390 and WCN6855. Since
wakeup & release mhi is enabled for all hardwares, below mhi assert is seen in
QCN9074 when doing 'rmmod ath11k_pci':
Kernel panic - not syncing: dev_wake != 0
CPU: 2 PID: 13535 Comm: procd Not tainted 4.4.60 #1
Hardware name: Generic DT based system
[<80316dac>] (unwind_backtrace) from [<80313700>] (show_stack+0x10/0x14)
[<80313700>] (show_stack) from [<805135dc>] (dump_stack+0x7c/0x9c)
[<805135dc>] (dump_stack) from [<8032136c>] (panic+0x84/0x1f8)
[<8032136c>] (panic) from [<80549b24>] (mhi_pm_disable_transition+0x3b8/0x5b8)
[<80549b24>] (mhi_pm_disable_transition) from [<80549ddc>] (mhi_power_down+0xb8/0x100)
[<80549ddc>] (mhi_power_down) from [<7f5242b0>] (ath11k_mhi_op_status_cb+0x284/0x3ac [ath11k_pci])
[E][__mhi_device_get_sync] Did not enter M0 state, cur_state:RESET pm_state:SHUTDOWN Process
[E][__mhi_device_get_sync] Did not enter M0 state, cur_state:RESET pm_state:SHUTDOWN Process
[E][__mhi_device_get_sync] Did not enter M0 state, cur_state:RESET pm_state:SHUTDOWN Process
[<7f5242b0>] (ath11k_mhi_op_status_cb [ath11k_pci]) from [<7f524878>] (ath11k_mhi_stop+0x10/0x20 [ath11k_pci])
[<7f524878>] (ath11k_mhi_stop [ath11k_pci]) from [<7f525b94>] (ath11k_pci_power_down+0x54/0x90 [ath11k_pci])
[<7f525b94>] (ath11k_pci_power_down [ath11k_pci]) from [<8056b2a8>] (pci_device_shutdown+0x30/0x44)
[<8056b2a8>] (pci_device_shutdown) from [<805cfa0c>] (device_shutdown+0x124/0x174)
[<805cfa0c>] (device_shutdown) from [<8033aaa4>] (kernel_restart+0xc/0x50)
[<8033aaa4>] (kernel_restart) from [<8033ada8>] (SyS_reboot+0x178/0x1ec)
[<8033ada8>] (SyS_reboot) from [<80301b80>] (ret_fast_syscall+0x0/0x34)
Hence, disable wakeup/release mhi using hw_param for other hardwares.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01060-QCAHKSWPL_SILICONZ-1
Fixes: a05bd85133 ("ath11k: read and write registers below unwindowed address")
Signed-off-by: Seevalamuthu Mariappan <quic_seevalam@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1636702019-26142-1-git-send-email-quic_seevalam@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6452f0a3d5651bb7edfd9c709e78973aaa4d3bfc ]
tcl_data and reo_dst rings are currently being allocated using
dma_allocate_coherent() which is non cacheable.
Allocating ring memory from cacheable memory area allows cached descriptor
access and prefetch next descriptors to optimize CPU usage during
descriptor processing on NAPI. Based on the hardware param we can enable
or disable this feature for the corresponding platform.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01695-QCAHKSWPL_SILICONZ-1
Co-developed-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Co-developed-by: Sriram R <srirrama@codeaurora.org>
Signed-off-by: Sriram R <srirrama@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: P Praneesh <ppranees@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1630560820-21905-3-git-send-email-ppranees@codeaurora.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 82c434c103408842a87404e873992b7698b6df2b ]
Commit 6f4d70308e ("ath11k: support SMPS configuration for 6 GHz") changed
"if (ht_cap & WMI_HT_CAP_DYNAMIC_SMPS)" to "if (ht_cap &
WMI_HT_CAP_DYNAMIC_SMPS || ar->supports_6ghz)" which means
NL80211_FEATURE_DYNAMIC_SMPS is enabled for all chips which support 6 GHz.
However, WCN6855 supports 6 GHz but it does not support feature
NL80211_FEATURE_DYNAMIC_SMPS, and this can lead to MU-MIMO test failures for
WCN6855.
Disable NL80211_FEATURE_DYNAMIC_SMPS for WCN6855 since its ht_cap does not
support WMI_HT_CAP_DYNAMIC_SMPS. Enable the feature only on QCN9074 as that's
the only other device supporting 6 GHz band.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210914163726.38604-3-jouni@codeaurora.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f6ef47e5bdc6f652176e433b02317fc83049f8d7 ]
In 99ce45d5e, we moved a route refcount decrement from
mctp_do_fragment_route into the caller. This invalidates the assumption
that the route test makes about refcount behaviour, so the route tests
fail.
This change fixes the test case to suit the new refcount behaviour.
Fixes: 99ce45d5e7 ("mctp: Implement extended addressing")
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit dd7f091fd22b1dce6c20e8f7769aa068ed88ac6d ]
xsk_configure_umem() needs hugepages to work in unaligned mode. So when
hugepages are not configured, 'unaligned' tests should be skipped which
is determined by the helper function hugepages_present(). This function
erroneously returns true with MAP_NORESERVE flag even when no hugepages
are configured. The removal of this flag fixes the issue.
The test TEST_TYPE_UNALIGNED_INV_DESC also needs to be skipped when
there are no hugepages. However, this was not skipped as there was no
check for presence of hugepages and hence was failing. The check to skip
the test has now been added.
Fixes: a4ba98dd0c (selftests: xsk: Add test for unaligned mode)
Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20211117123613.22288-1-tirthendu.sarkar@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 646596485e1ed2182adf293dfd5aec4a96c46330 ]
As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking behavior when adjusting the backlight.
So, let's fix this by just not reading back the current backlight mode on
initial enable. I don't think there should really be any downsides to this,
and this will ensure we don't leave any unsupported functionality enabled.
This should fix at least one (but not all) of the issues seen with DPCD
backlight support on fi-bdw-samus
v5:
* Just avoid reading back DPCD register - Doug Anderson
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 867cf9cd73 ("drm/dp: Extract i915's eDP backlight code into DRM helpers")
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211105183342.130810-4-lyude@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1b9beda83e27a0c2cd75d1cb743c297c7b36c844 ]
This patch will surround the AF_INET6 case in sk_error_report() of dlm
with a #if IS_ENABLED(CONFIG_IPV6). The field sk->sk_v6_daddr is not
defined when CONFIG_IPV6 is disabled. If CONFIG_IPV6 is disabled, the
socket creation with AF_INET6 should already fail because a runtime
check if AF_INET6 is registered. However if there is the possibility
that AF_INET6 is set as sk_family the sk_error_report() callback will
print then an invalid family type error.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 4c3d90570bcc ("fs: dlm: don't call kernel_getpeername() in error_report()")
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f18397ab3ae23e8e43bba9986e66af6d4497f2ad ]
Prior to this patch was teedev_close_context() calling tee_device_put()
before teedev_ctx_put() leading to teedev_ctx_release() accessing
ctx->teedev just after the reference counter was decreased on the
teedev. Fix this by calling teedev_ctx_put() before tee_device_put().
Fixes: 217e0250cc ("tee: use reference counting for tee_context")
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 64bc3aa02ae78b1fcb1b850e0eb1f0622002bfaa ]
The ath11k driver is caching the information about RSN/WPA IE in the
configured beacon template. The cached information is used during
associations to figure out whether 4-way PKT/2-way GTK peer flags need to
be set or not.
But the code never cleared the state when no such IE was found. This can
for example happen when moving from an WPA/RSN to an open setup. The
(seemingly connected) peer was then not able to communicate over the
link because the firmware assumed a different (encryption enabled) state
for the peer.
Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Fixes: 01e34233c6 ("ath11k: fix wmi peer flags in peer assoc command")
Cc: Venkateswara Naralasetty <vnaralas@codeaurora.org>
Reported-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Karthikeyan Kathirvel <kathirve@codeaurora.org>
[sven@narfation.org: split into separate patches, clean up commit message]
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211115100441.33771-2-sven@narfation.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 436a4e88659842a7cf634d7cc088c8f2cc94ebf5 ]
DISABLE_KEY sets the key_len to 0, firmware will not delete the keys if
key_len is 0. Changing from security mode to open mode will cause mcast
to be still encrypted without vdev restart.
Set the proper key_len for DISABLE_KEY cmd to clear the keys in
firmware.
Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Reported-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Karthikeyan Kathirvel <kathirve@codeaurora.org>
[sven@narfation.org: split into separate patches, clean up commit message]
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211115100441.33771-1-sven@narfation.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 086c921a354089f209318501038d43c98d3f409f ]
Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
channel (5590-5650). A good example is Australia:
country AU: DFS-ETSI
(2400 - 2483.5 @ 40), (36)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
If the firmware (or the BDF) is shipped with these rules then there is only
a 10 MHz overlap with the weather radar:
* below: 5470 - 5590
* weather radar: 5590 - 5600
* above: (none for the rule "5470 - 5600 @ 80")
There are several wrong assumption in the ath11k code:
* there is always a valid range below the weather radar
(actually: there could be no range below the weather radar range OR range
could be smaller than 20 MHz)
* intersected range in the weather radar range is valid
(actually: the range could be smaller than 20 MHz)
* range above weather radar is either empty or valid
(actually: the range could be smaller than 20 MHz)
These wrong assumption will lead in this example to a rule
(5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
which is invalid according to is_valid_reg_rule() because the freq_diff is
only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
rejection like:
WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
[...]
Call trace:
[<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
[<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
[<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
[<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
[<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
[<ffffffc0000a9784>] worker_thread+0x25c/0x448
[<ffffffc0000aedc8>] kthread+0xd0/0xd8
[<ffffffc000085550>] ret_from_fork+0x10/0x40
ath11k c000000.wifi: failed to perform regd update : -22
Invalid regulatory domain detected
To avoid this, the algorithm has to be changed slightly. Instead of
splitting a rule which overlaps with the weather radar range into 3 pieces
and accepting the first two parts blindly, it must actually be checked for
each piece whether it is a valid range. And only if it is valid, add it to
the output array.
When these checks are in place, the processed rules for AU would end up as
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
(5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
and will be accepted by the wireless regulatory code.
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a27c519a816437ec92f0ffa3adbc168c2c08725b ]
Coverity Scan report:
[...]
*** CID 1493985: Uninitialized variables (UNINIT)
/net/bluetooth/hci_event.c: 4535 in hci_sync_conn_complete_evt()
4529
4530 /* Notify only in case of SCO over HCI transport data path which
4531 * is zero and non-zero value shall be non-HCI transport data path
4532 */
4533 if (conn->codec.data_path == 0) {
4534 if (hdev->notify)
>>> CID 1493985: Uninitialized variables (UNINIT)
>>> Using uninitialized value "notify_evt" when calling "*hdev->notify".
4535 hdev->notify(hdev, notify_evt);
4536 }
4537
4538 hci_connect_cfm(conn, ev->status);
4539 if (ev->status)
4540 hci_conn_del(conn);
[...]
Although only btusb uses air_mode, and he only handles HCI_NOTIFY_ENABLE_SCO_CVSD
and HCI_NOTIFY_ENABLE_SCO_TRANSP, there is still a very small chance that
ev->air_mode is not equal to 0x2 and 0x3, but notify_evt is initialized to
HCI_NOTIFY_ENABLE_SCO_CVSD or HCI_NOTIFY_ENABLE_SCO_TRANSP. the context is
maybe not correct.
Let us directly use the required function instead of re-initializing it,
so as to restore the original logic and make the code more correct.
Addresses-Coverity: ("Uninitialized variables")
Fixes: f4f9fa0c07 ("Bluetooth: Allow usb to auto-suspend when SCO use non-HCI transport")
Suggested-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>