kernel/linux.git/drivers/net/wireless/ath/dfs_pattern_detector.c, branch linux-7.0.y

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

wifi: ath: dfs_pattern_detector: Use flex array to simplify code

2023-10-02T16:58:33+00:00

At the time of the writing, the value of 'num_radar_types' is 7 or 9. So on a 64 bits system, only 56 or 72 bytes are allocated for the 'detectors' array. Turn it into a flex array, in order to simplify memory management and save an indirection when the array is used. Doing so, cd->detectors can't be NULL, and channel_detector_exit() can be simplified as well. Signed-off-by: Christophe JAILLET Reviewed-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1920cc38db2e570633e13b37d50852f3202a7270.1695538105.git.christophe.jaillet@wanadoo.fr

wifi: ath: dfs_pattern_detector: Fix a memory initialization issue

2023-10-02T16:58:33+00:00

If an error occurs and channel_detector_exit() is called, it relies on entries of the 'detectors' array to be NULL. Otherwise, it may access to un-initialized memory. Fix it and initialize the memory, as what was done before the commit in Fixes. Fixes: a063b650ce5d ("ath: dfs_pattern_detector: Avoid open coded arithmetic in memory allocation") Signed-off-by: Christophe JAILLET Reviewed-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/ad8c55b97ee4b330cb053ce2c448123c309cc91c.1695538105.git.christophe.jaillet@wanadoo.fr

ath: dfs_pattern_detector: Avoid open coded arithmetic in memory allocation

2022-01-17T12:41:51+00:00

kmalloc_array()/kcalloc() should be used to avoid potential overflow when a multiplication is needed to compute the size of the requested memory. kmalloc_array() can be used here instead of kcalloc() because the array is fully initialized in the next 'for' loop. Finally, 'cd->detectors' is defined as 'struct pri_detector **detectors;'. So 'cd->detectors' and '*cd->detectors' are both some pointer. So use a more logical 'sizeof(*cd->detectors)'. Signed-off-by: Christophe JAILLET Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/0fbcd32a0384ac1f87c5a3549e505e4becc60226.1640624216.git.christophe.jaillet@wanadoo.fr

ath: dfs_pattern_detector: Fix possible null-pointer dereference in channel_detector_create()

2021-10-11T06:26:10+00:00

kzalloc() is used to allocate memory for cd->detectors, and if it fails, channel_detector_exit() behind the label fail will be called: channel_detector_exit(dpd, cd); In channel_detector_exit(), cd->detectors is dereferenced through: struct pri_detector *de = cd->detectors[i]; To fix this possible null-pointer dereference, check cd->detectors before the for loop to dereference cd->detectors. Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210805153854.154066-1-islituo@gmail.com

ath: dfs_pattern_detector: Fix some function kernel-doc headers

2020-11-07T08:06:46+00:00

Fixes the following W=1 kernel build warning(s): drivers/net/wireless/ath/dfs_pattern_detector.c:34: warning: Function parameter or member 'region' not described in 'radar_types' drivers/net/wireless/ath/dfs_pattern_detector.c:141: warning: Function parameter or member 'region' not described in 'get_dfs_domain_radar_types' drivers/net/wireless/ath/dfs_pattern_detector.c:239: warning: Function parameter or member 'dpd' not described in 'channel_detector_get' drivers/net/wireless/ath/dfs_pattern_detector.c:239: warning: Function parameter or member 'freq' not described in 'channel_detector_get' Cc: Kalle Valo Cc: "David S. Miller" Cc: Jakub Kicinski Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201102112410.1049272-22-lee.jones@linaro.org

ath: drop unnecessary list_empty

2020-08-14T15:05:06+00:00

list_for_each_entry{_safe} is able to handle an empty list. The only effect of avoiding the loop is not initializing the index variable. Drop list_empty tests in cases where these variables are not used. Note that list_for_each_entry{_safe} is defined in terms of list_first_entry, which indicates that it should not be used on an empty list. But in list_for_each_entry{_safe}, the element obtained by list_first_entry is not really accessed, only the address of its list_head field is compared to the address of the list head, so the list_first_entry is safe. The semantic patch that makes this change for the list_for_each_entry case is as follows: (http://coccinelle.lip6.fr/) @@ expression x,e; statement S; identifier i; @@ -if (!(list_empty(x))) list_for_each_entry(i,x,...) S ... when != i ? i = e Signed-off-by: Julia Lawall Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1595761112-11003-8-git-send-email-Julia.Lawall@inria.fr

ath: DFS JP domain W56 fixed pulse type 3 RADAR detection

2019-04-29T14:58:51+00:00

Increase pulse width range from 1-2usec to 0-4usec. During data traffic HW occasionally fails detecting radar pulses, so that SW cannot get enough radar reports to achieve the success rate. Tested ath10k hw and fw: * QCA9888(10.4-3.5.1-00052) * QCA4019(10.4-3.2.1.1-00017) * QCA9984(10.4-3.6-00104) * QCA988X(10.2.4-1.0-00041) Tested ath9k hw: AR9300 Tested-by: Tamizh chelvam Signed-off-by: Tamizh chelvam Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo

ath: add support to get the detected radar specifications

2018-05-25T10:15:21+00:00

This enables ath10k/ath9k drivers to collect the specifications of the radar type once it is detected by the dfs pattern detector unit. Usage of the collected info is specific to driver implementation. For example, collected radar info could be used by the host driver to send to co-processors for additional processing/validation. Note: 'radar_detector_specs' data containing the specifications of different radar types which was private within dfs_pattern_detector/ dfs_pri_detector is now shared with drivers as well for making use of this information. Signed-off-by: Sriram R Signed-off-by: Kalle Valo