Re: [PATCH] ath10k: fix recent bandwidth conversion bug

2018-03-10 Thread Kalle Valo
Rafał Miłecki writes: > On 14 December 2017 at 14:21, Kalle Valo wrote: >> Christian Lamparter writes: >> >>> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote: Christian Lamparter writes:

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

2018-03-10 Thread Gustavo A. R. Silva
On 03/10/2018 05:12 PM, Kees Cook wrote: On Sat, Mar 10, 2018 at 3:06 PM, Arend van Spriel wrote: On 3/9/2018 1:30 PM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. I think there was a remark made earlier to give

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

2018-03-10 Thread Daniel Micay
> Just wondering. Is this actually a VLA. FFT_NUM_SAMPLES was static const so > not really going to show a lot of variation. This array will always have the > same size on the stack. The issue is that unlike in C++, a `static const` can't be used in a constant expression in C. It's unclear why C

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

2018-03-10 Thread Kees Cook
On Sat, Mar 10, 2018 at 3:06 PM, Arend van Spriel wrote: > On 3/9/2018 1:30 PM, Andreas Christoforou wrote: >> >> The kernel would like to have all stack VLA usage removed. > > > I think there was a remark made earlier to give more explanation here. It > should

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

2018-03-10 Thread Arend van Spriel
On 3/9/2018 1:30 PM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. I think there was a remark made earlier to give more explanation here. It should explain why we want "VLA on stack" removed. Signed-off-by: Andreas Christoforou

[PATCH 3/3] wlcore: Use common error handling code in wl1271_acx_sta_rate_policies()

2018-03-10 Thread SF Markus Elfring
From: Markus Elfring Date: Sat, 10 Mar 2018 22:18:45 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 2/3] wlcore: Return directly after a failed kzalloc() in wl1271_acx_sta_rate_policies()

2018-03-10 Thread SF Markus Elfring
From: Markus Elfring Date: Sat, 10 Mar 2018 22:00:31 +0100 Return directly after a call of the function "kzalloc" failed at the beginning. Signed-off-by: Markus Elfring --- drivers/net/wireless/ti/wlcore/acx.c | 7 ++- 1 file

[PATCH 1/3] wlcore: Delete an unnecessary variable initialisation in wl1271_acx_sta_rate_policies()

2018-03-10 Thread SF Markus Elfring
From: Markus Elfring Date: Sat, 10 Mar 2018 21:51:17 +0100 The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring ---

[PATCH 0/3] wlcore: Adjustments for wl1271_acx_sta_rate_policies()

2018-03-10 Thread SF Markus Elfring
From: Markus Elfring Date: Sat, 10 Mar 2018 22:25:45 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an unnecessary variable initialisation Return directly after a failed kzalloc() Use

Re: [PATCH v3 00/20] firmware: development for v4.17

2018-03-10 Thread Kees Cook
On Sat, Mar 10, 2018 at 6:14 AM, Luis R. Rodriguez wrote: > Greg, > > Here's a respin of what I have queued up for v4.17 for the firmware API. It > combines the cleanup I've been working on and the addition of the new API call > request_firmware_cache() for fixing a corner case

Re: [PATCH] wcn36xx: calculate DXE control registers values

2018-03-10 Thread Ramon Fried
On 3/10/2018 11:47 AM, Kalle Valo wrote: > Ramon Fried writes: > >> DXE descriptor control registers used hardcoded magic values. Added >> bit definitions of the control register and calculate this values in >> compilation for clarity. >> >> Signed-off-by: Ramon Fried

Re: [PATCH] firmware: add a function to load optional firmware v2

2018-03-10 Thread Luis R. Rodriguez
First, thanks for your patch! On Fri, Mar 9, 2018 at 3:09 PM, Andres Rodriguez wrote: > Currently the firmware loader only exposes one silent path for querying > optional firmware, and that is request_firmware_direct(). This function > also disables the usermodehelper

[PATCH v3 00/20] firmware: development for v4.17

2018-03-10 Thread Luis R. Rodriguez
Greg, Here's a respin of what I have queued up for v4.17 for the firmware API. It combines the cleanup I've been working on and the addition of the new API call request_firmware_cache() for fixing a corner case suspend issue on some type of cards with an optimization in place where the firmware

[PATCH v3 03/20] test_firmware: replace syfs fallback check with kconfig_has helper

2018-03-10 Thread Luis R. Rodriguez
Now that we have a kconfig checker just use that instead of relying on testing a sysfs directory being present, since our requirements are spelled out. Acked-by: Kees Cook Signed-off-by: Luis R. Rodriguez ---

[PATCH v3 02/20] test_firmware: enable custom fallback testing on limited kernel configs

2018-03-10 Thread Luis R. Rodriguez
When a kernel is not built with: CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y We don't currently enable testing fw_fallback.sh. For kernels that still enable the fallback mechanism, its possible to use the async request firmware API call request_firmware_nowait() using the custom interface to use

[PATCH v3 01/20] test_firmware: add simple firmware firmware test library

2018-03-10 Thread Luis R. Rodriguez
We'll expland on this later, for now just add basic module checker. While at it, move this all to use /bin/bash as we'll have much more flexibility with it. Signed-off-by: Luis R. Rodriguez --- tools/testing/selftests/firmware/fw_fallback.sh | 7 ++--

[PATCH v3 04/20] firmware: enable to split firmware_class into separate target files

2018-03-10 Thread Luis R. Rodriguez
The firmware loader code has grown quite a bit over the years. The practice of stuffing everything we need into one file makes the code hard to follow. In order to split the firmware loader code into different components we must pick a module name and a first object target file. We must keep the

[PATCH v3 07/20] firmware: move loading timeout under struct firmware_fallback_config

2018-03-10 Thread Luis R. Rodriguez
The timeout is a fallback construct, so we can just stuff the timeout configuration under struct firmware_fallback_config. While at it, add a few helpers which vets the use of getting or setting the timeout as an int. The main use of the timeout is to set a timeout for completion, and that is

[PATCH v3 06/20] firmware: use helpers for setting up a temporary cache timeout

2018-03-10 Thread Luis R. Rodriguez
We only use the timeout for the firmware fallback mechanism except for trying to set the timeout during the cache setup for resume/suspend. For those cases, setting the timeout should be a no-op, so just reflect this in code by adding helpers for it. This change introduces no functional changes.

[PATCH v3 05/20] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further

2018-03-10 Thread Luis R. Rodriguez
All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool, initailized at build time. Define it as such. This simplifies the logic even further, removing now all explicit #ifdefs around the code. Acked-by: Kees Cook Signed-off-by: Luis R. Rodriguez

[PATCH v3 08/20] firmware: split firmware fallback functionality into its own file

2018-03-10 Thread Luis R. Rodriguez
The firmware fallback code is optional. Split that code out to help distinguish the fallback functionlity from othere core firmware loader features. This should make it easier to maintain and review code changes. The reason for keeping the configuration onto a table which is built-in if you

Re: [RFC 0/1] Loading optional firmware

2018-03-10 Thread Luis R. Rodriguez
On Fri, Mar 9, 2018 at 2:12 PM, Andres Rodriguez wrote: > Hi Everyone, > > Wanted to inquire your opinions about the following matter. > > We are experiencing some end user confusion regarding the following messages > being printed to dmesg: > > [0.571324] amdgpu

[PATCH v3 14/20] rename: _request_firmware_load() fw_load_sysfs_fallback()

2018-03-10 Thread Luis R. Rodriguez
This reflects much clearer what is being done. While at it, kdoc'ify it. Signed-off-by: Luis R. Rodriguez --- Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +- drivers/base/firmware_loader/fallback.c | 13 ++--- 2 files changed, 11

[PATCH v3 10/20] firmware: enable run time change of forcing fallback loader

2018-03-10 Thread Luis R. Rodriguez
Currently one requires to test four kernel configurations to test the firmware API completely: 0) CONFIG_FW_LOADER=y 1) o CONFIG_FW_LOADER=y o CONFIG_FW_LOADER_USER_HELPER=y 2) o CONFIG_FW_LOADER=y o CONFIG_FW_LOADER_USER_HELPER=y o CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y 3) When

[PATCH v3 09/20] firmware: move firmware loader into its own directory

2018-03-10 Thread Luis R. Rodriguez
This will make it much easier to manage as we manage to keep trimming componnents down into their own files to more easily manage and maintain this codebase. Suggested-by: Kees Cook Signed-off-by: Luis R. Rodriguez --- MAINTAINERS

[PATCH v3 11/20] firmware: enable to force disable the fallback mechanism at run time

2018-03-10 Thread Luis R. Rodriguez
You currently need four different kernel builds to test the firmware API fully. By adding a proc knob to force disable the fallback mechanism completely we are able to reduce the amount of kernels you need built to test the firmware API down to two. Acked-by: Kees Cook

[PATCH v3 15/20] firmware: fix checking for return values for fw_add_devm_name()

2018-03-10 Thread Luis R. Rodriguez
Currently fw_add_devm_name() returns 1 if the firmware cache was already set. This makes it complicated for us to check for correctness. It is actually non-fatal if the firmware cache is already setup, so just return 0, and simplify the checkers. fw_add_devm_name() adds device's name onto the

[PATCH v3 17/20] test_firmware: modify custom fallback tests to use unique files

2018-03-10 Thread Luis R. Rodriguez
Users of the custom firmware fallback interface is are not supposed to use the firmware cache interface, this can happen if for instance the one of the APIs which use the firmware cache is used first with one firmware file and then the request_firmware_nowait(uevent=false) API is used with the

[PATCH v3 16/20] firmware: add helper to check to see if fw cache is setup

2018-03-10 Thread Luis R. Rodriguez
Add a helper to check if the firmware cache is already setup for a device. This will be used later. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_loader/main.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git

[PATCH v3 18/20] firmware: ensure the firmware cache is not used on incompatible calls

2018-03-10 Thread Luis R. Rodriguez
request_firmware_into_buf() explicitly disables the firmware cache, meanwhile the firmware cache cannot be used when request_firmware_nowait() is used without the uevent. Enforce a sanity check for this to avoid future issues undocumented behaviours should misuses of the firmware cache happen

[PATCH v3 13/20] test_firmware: test three firmware kernel configs using a proc knob

2018-03-10 Thread Luis R. Rodriguez
Since we now have knobs to twiddle what used to be set on kernel configurations we can build one base kernel configuration and modify behaviour to mimic such kernel configurations to test them. Provided you build a kernel with: CONFIG_TEST_FIRMWARE=y CONFIG_FW_LOADER=y

[PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

2018-03-10 Thread Luis R. Rodriguez
Some devices have an optimization in place to enable the firmware to be retaineed during a system reboot, so after reboot the device can skip requesting and loading the firmware. This can save up to 1s in load time. The mt7601u 802.11 device happens to be such a device. When these devices retain

[PATCH v3 20/20] mt7601u: use request_firmware_cache() to address cache on reboot

2018-03-10 Thread Luis R. Rodriguez
request_firmware_cache() will ensure the firmware is available on resume from suspend if on reboot the device retains the firmware. This optimization is in place given otherwise on reboot we have to reload the firmware, the opmization saves us about max 1s, minimum 10ms. Cantabile has reported

[PATCH v3 12/20] test_firmware: expand on library with shared helpers

2018-03-10 Thread Luis R. Rodriguez
This expands our library with as many things we could find which both scripts we use share. Signed-off-by: Luis R. Rodriguez --- tools/testing/selftests/firmware/fw_fallback.sh | 31 +++--- tools/testing/selftests/firmware/fw_filesystem.sh | 41 +++---

[PATCH] ath10k: fix recent bandwidth conversion bug

2018-03-10 Thread Anilkumar Kolli
From: Christian Lamparter The commit "cfg80211: make RATE_INFO_BW_20 the default" changed the index of RATE_INFO_BW_20, but the updates to ath10k missed the special bandwidth calculation case in ath10k_update_per_peer_tx_stats(). This will fix below warning, WARNING: CPU:

Re: [PATCH v2] bcma: Prevent build of PCI host features in module

2018-03-10 Thread Jonas Gorski
Hi, On 8 March 2018 at 13:00, Matt Redfearn wrote: > Hi, > > > On 02/03/18 17:56, Larry Finger wrote: >> >> On 03/01/2018 04:45 AM, Kalle Valo wrote: >>> >>> Matt Redfearn writes: >>> Attempting to build bcma.ko with

Re: [PATCH v3] ath9k: fix crash in spectral scan

2018-03-10 Thread Kalle Valo
s.gottsch...@dd-wrt.com writes: > From: Sebastian Gottschall > > fixes crash seen on arm smp systems (gateworks ventana imx6) > > Signed-off-by: Sebastian Gottschall > > v2: fix wrong field and add signed-off-by > v3: forgot to include correct

Re: [PATCH] wcn36xx: calculate DXE control registers values

2018-03-10 Thread Kalle Valo
Ramon Fried writes: > DXE descriptor control registers used hardcoded magic values. Added > bit definitions of the control register and calculate this values in > compilation for clarity. > > Signed-off-by: Ramon Fried I assume that the values are

Re: [PATCH] wcn36xx: Add support for FTM WLAN

2018-03-10 Thread Kalle Valo
Ramon Fried writes: > From: Eyal Ilsar > > Introduced infrastructure for supporting FTM WLAN in user space exposing > the netlink channel from the kernel WLAN driver. What's FTM WLAN? Don't assume that people know all the acronyms. This included:

Re: [PATCH 01/13] ath10k: platform driver for WCN3990 SNOC WLAN module

2018-03-10 Thread Kalle Valo
writes: >> >> Kbuild bot found an odd problem with this patch: >> >> >> >> include/linux/dynamic_debug.h:77:14: error: 'KBUILD_MODNAME' >> >> undeclared (first use in this function); did you mean >> 'KBUILD_BASENAME'? >> >> >> >> Full report: >> >> >> >> >>

Re: Dependency required for wil6210 kernel module

2018-03-10 Thread Kalle Valo
Arjav Parikh writes: > I am using kernel version 4.4.60 built with QSDK. This list is about upstream kernel, not QSDK. And please don't top post. -- Kalle Valo

Re: Dependency required for wil6210 kernel module

2018-03-10 Thread Kalle Valo
Arjav Parikh writes: > Currently I am working to minimize the filesystem for one of my > project. In my project I only want to add support for USB & Wireless > (wil6210). To minimize the filesystem I disabled the unwanted things > like Iptables, VLAN, VPN, Ethernet