[PATCH v2] rsi: Remove stack VLA usage

The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug (kernel Oops) or a security flaw (overwriting memory beyond the stack). Also, in general, as code evolves it is easy to lose track of how big a VLA can get.

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

On Wed, Mar 14, 2018 at 11:53 AM, Greg KH wrote: > On Sat, Mar 10, 2018 at 06:14:46AM -0800, Luis R. Rodriguez wrote: >> 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

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

On Wed, Mar 14, 2018 at 11:56 AM, Greg KH wrote: > On Sat, Mar 10, 2018 at 06:14:48AM -0800, Luis R. Rodriguez wrote: >> The timeout is a fallback construct, so we can just stuff the >> timeout configuration under struct firmware_fallback_config. > > Why? What does it

Re: [PATCH] wireless: brcmfmac: cfg80211: Fix check for ISO3166 code

On Wed, Mar 14, 2018 at 12:02 PM, Stefan Wahren wrote: > The commit "regulatory: add NUL to request alpha2" increases the length of > alpha2 to 3. This causes a regression on brcmfmac, because > brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete >

Re: [PATCH] ath9k: introduce endian_check module parameter

+ Martin On 3/14/2018 3:34 PM, Kalle Valo wrote: Bas Vermeulen writes: --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -67,6 +67,9 @@ static int ath9k_ps_enable; module_param_named(ps_enable, ath9k_ps_enable, int, 0444);

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 3/14/2018 5:10 PM, Kalle Valo wrote: Rafał Miłecki writes: + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN; +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) #ifndef? I followed what is used in the include/linux/etherdevice.h. Is that a good

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 3/14/2018 4:57 PM, Rafał Miłecki wrote: On 2018-03-14 16:39, Rafał Miłecki wrote: On 2018-03-14 13:58, Arend van Spriel wrote: On 3/14/2018 12:01 PM, Rafał Miłecki wrote: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not

Re: [RESEND] rsi: Remove stack VLA usage

On Wed, Mar 14, 2018 at 11:19:53AM +0200, Kalle Valo wrote: > "Tobin C. Harding" writes: > > > Added Konstantin in case he is in charge of administering > > patchwork.kernel.org? > > > > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: > >> On Tue, Mar 13, 2018 at 7:11

[PATCH] wireless: brcmfmac: cfg80211: Fix check for ISO3166 code

The commit "regulatory: add NUL to request alpha2" increases the length of alpha2 to 3. This causes a regression on brcmfmac, because brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete array. So fix this accordingly. Signed-off-by: Stefan Wahren ---

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

On Sat, Mar 10, 2018 at 06:14:52AM -0800, Luis R. Rodriguez wrote: > 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

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

On Sat, Mar 10, 2018 at 06:14:48AM -0800, Luis R. Rodriguez wrote: > The timeout is a fallback construct, so we can just stuff the > timeout configuration under struct firmware_fallback_config. Why? What does it matter? > While at it, add a few helpers which vets the use of getting or > setting

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

On Sat, Mar 10, 2018 at 06:14:47AM -0800, Luis R. Rodriguez wrote: > 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

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

On Sat, Mar 10, 2018 at 06:14:46AM -0800, Luis R. Rodriguez wrote: > 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

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

On Wed, Mar 14, 2018 at 05:44:03PM +, Luis R. Rodriguez wrote: > On Sat, Mar 10, 2018 at 09:16:36AM -0800, Kees Cook wrote: > > 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

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

On Sat, Mar 10, 2018 at 09:16:36AM -0800, Kees Cook wrote: > 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

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 2018-03-14 13:58, Arend van Spriel wrote: On 3/14/2018 12:01 PM, Rafał Miłecki wrote: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging resulted in discovering support for IAPP in

[PATCH v2 resend] mac80211: inform wireless layer when frame RSSI is invalid

When the low-level driver returns an invalid RSSI indication, set the signal value to 0 as an indication to the upper layer. Also, skip average level computation if signal is invalid. Signed-off-by: Jean Pierre TOSONI --- @Johannes: what is the status of this patch?

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 2018-03-14 15:24, Kalle Valo wrote: Rafał Miłecki writes: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging resulted in discovering support for IAPP in Broadcom's

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 2018-03-14 16:39, Rafał Miłecki wrote: On 2018-03-14 13:58, Arend van Spriel wrote: On 3/14/2018 12:01 PM, Rafał Miłecki wrote: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

Rafał Miłecki writes: >>> + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN; >>> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) >> >> #ifndef? > > I followed what is used in the include/linux/etherdevice.h. Is that a > good exceuse? Could it be there any some

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 2018-03-14 16:39, Rafał Miłecki wrote: On 2018-03-14 13:58, Arend van Spriel wrote: On 3/14/2018 12:01 PM, Rafał Miłecki wrote: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 2018-03-14 16:08, Kalle Valo wrote: Arend van Spriel writes: On 3/14/2018 3:24 PM, Kalle Valo wrote: +config BRCMFMAC_IAPP >+ bool "Partial support for obsoleted Inter-Access Point Protocol" >+ depends on BRCMFMAC >+ ---help--- >+ Most of Broadcom's

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On Wed, 14 Mar 2018 17:08:48 +0200 Kalle Valo wrote: > Arend van Spriel writes: > > > On 3/14/2018 3:24 PM, Kalle Valo wrote: > >>> +config BRCMFMAC_IAPP > >>> >+bool "Partial support for obsoleted Inter-Access Point Protocol" >

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

Arend van Spriel writes: > On 3/14/2018 3:24 PM, Kalle Valo wrote: >>> +config BRCMFMAC_IAPP >>> >+ bool "Partial support for obsoleted Inter-Access Point Protocol" >>> >+ depends on BRCMFMAC >>> >+ ---help--- >>> >+Most of Broadcom's firmwares can send

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On Wed, 14 Mar 2018 12:01:19 +0100 Rafał Miłecki wrote: > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c > index 19048526b4af..db6987015fb1 100644 > ---

[PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs

A lot of Kconfig symbols have architecture specific dependencies. In those cases that depend on architectures we have already removed, they can be omitted. Signed-off-by: Arnd Bergmann --- block/bounce.c | 2 +- drivers/ide/Kconfig | 2 +-

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 3/14/2018 3:24 PM, Kalle Valo wrote: +config BRCMFMAC_IAPP >+ bool "Partial support for obsoleted Inter-Access Point Protocol" >+ depends on BRCMFMAC >+ ---help--- >+ Most of Broadcom's firmwares can send 802.11f ADD frame every >+ time new STA connects to the AP interface. Some

[PATCH 00/16] remove eight obsolete architectures

Here is the collection of patches I have applied to my 'asm-generic' tree on top of the 'metag' removal. This does not include any of the device drivers, I'll send those separately to a someone different list of people. The removal came out of a discussion that is now documented at

Re: [PATCH] ath9k: introduce endian_check module parameter

Bas Vermeulen writes: > --- a/drivers/net/wireless/ath/ath9k/init.c > +++ b/drivers/net/wireless/ath/ath9k/init.c > @@ -67,6 +67,9 @@ static int ath9k_ps_enable; >module_param_named(ps_enable, ath9k_ps_enable, int, 0444); >

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

Rafał Miłecki writes: > From: Rafał Miłecki > > Testing brcmfmac with more recent firmwares resulted in AP interfaces > not working in some specific setups. Debugging resulted in discovering > support for IAPP in Broadcom's firmwares. This is an obsoleted

[PATCH][next] rsi: remove redundant duplicate assignment of buffer_size

From: Colin Ian King Variable buffer_size is re-assigned the same value, this duplicated assignment is redundant and can be removed. Cleans up clang warning: drivers/net/wireless/rsi/rsi_91x_usb.c:140:4: warning: Value stored to 'buffer_size' is never read

Re: [PATCH 6/7] staging: wilc1000: remove unwanted braces and correct code alignment

On Wed, 14 Mar 2018 18:15:04 +0530 wrote: > From: HariPrasath Elango > > Remove the unwated brace and corrected the code block alignment > accordingly Changes done in this patch are already taken care. Today, Greg has applied the

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

On 3/14/2018 12:01 PM, Rafał Miłecki wrote: From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging resulted in discovering support for IAPP in Broadcom's firmwares. This is an obsoleted standard

[PATCH 4/7] staging: wilc1000: destroy initialized mutex object

From: HariPrasath Elango A mutex object that is initialized but not destroyed.This patch destroys the mutex object Signed-off-by: HariPrasath Elango --- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 1 + 1 file changed, 1

[PATCH 2/7] staging: wilc1000: Destroy mutex object in deinitialization

From: HariPrasath Elango Destroy the mutex object that is initialized in wlan_init_locks() Signed-off-by: HariPrasath Elango Reviewed-by: Ajay Singh --- drivers/staging/wilc1000/linux_wlan.c | 1 + 1 file

[PATCH 3/7] staging: wilc1000: use kmemdup instead of kmalloc and memcpy

From: HariPrasath Elango Kmalloc followed by memcpy can be replaced by kmemdup. Signed-off-by: HariPrasath Elango Reviewed-by: Ajay Singh --- drivers/staging/wilc1000/linux_mon.c | 3 +-- 1 file changed, 1

[PATCH 1/7] staging: wilc1000: Fix code block alignment

From: HariPrasath Elango Fix the code alignment for a block of code to adhere to coding guidelines Signed-off-by: HariPrasath Elango Reviewed-by: Ajay Singh --- drivers/staging/wilc1000/linux_wlan.c | 6

[PATCH 0/7] Cleanup patches for wilc1000 driver

From: HariPrasath Elango This patchset has few cleanup patches related to coding guidelines and few trivial changes HariPrasath Elango (7): staging: wilc1000: Fix code block alignment staging: wilc1000: Destroy mutex object in deinitialization staging:

[PATCH 6/7] staging: wilc1000: remove unwanted braces and correct code alignment

From: HariPrasath Elango Remove the unwated brace and corrected the code block alignment accordingly Signed-off-by: HariPrasath Elango --- drivers/staging/wilc1000/host_interface.c | 25 - 1 file changed, 12

[PATCH 7/7] staging: wilc1000: use kmemdup to replace kmalloc/memcpy

From: HariPrasath Elango kmalloc followed by memcpy can be replaced by kmemdup.Also added the related error handling part Signed-off-by: HariPrasath Elango --- drivers/staging/wilc1000/host_interface.c | 10 +++--- 1 file

[PATCH 5/7] staging: wilc1000: replace switch statement by simple if condition

From: HariPrasath Elango In this case,there is only a single switch case statement.So replacing by a simple if condition. Signed-off-by: HariPrasath Elango --- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 8 +--- 1 file

Re: [PATCH] ath9k: introduce endian_check module parameter

On 26-02-18 15:52, Kalle Valo wrote: Bas Vermeulen writes: On 26-02-18 10:54, Kalle Valo wrote: Bas Vermeulen writes: A random (little endian eeprom'd) ar9278 card didn't work on my PowerMac G5 without allowing the driver to byte-swap the

[PATCH] wcn36xx: turn off probe response offloading

It appears that the WCN36xx firmware doesn't actually respond to probe requests. Until it's resolved, switch the probe response responsibility to the 802.11 layer to allow creation of hidden SSID AP's. Signed-off-by: Ramon Fried --- drivers/net/wireless/ath/wcn36xx/main.c

Re: [PATCH] staging: wilc1000: use kmemdup to replace kmalloc/memcpy

On Wed, Mar 14, 2018 at 12:38:18PM +0100, Greg Kroah-Hartman wrote: > On Tue, Mar 13, 2018 at 06:19:32PM +0530, hariprasath.ela...@gmail.com wrote: > > From: HariPrasath Elango > > > > kmalloc followed by memcpy can be replaced by kmemdup.Also added the > > related

Re: [PATCH] staging: wilc1000: use kmemdup to replace kmalloc/memcpy

On Tue, Mar 13, 2018 at 06:19:32PM +0530, hariprasath.ela...@gmail.com wrote: > From: HariPrasath Elango > > kmalloc followed by memcpy can be replaced by kmemdup.Also added the > related error handling part > > Signed-off-by: HariPrasath Elango

[PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

From: Rafał Miłecki Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging resulted in discovering support for IAPP in Broadcom's firmwares. This is an obsoleted standard and its implementation is something that: 1)

Re: ath9k: Protect queue draining by rcu_read_lock()

Toke Høiland-Jørgensen wrote: > When ath9k was switched over to use the mac80211 intermediate queues, > node cleanup now drains the mac80211 queues. However, this call path is > not protected by rcu_read_lock() as it was previously entirely internal > to the driver which uses its own locking. >

Re: ath10k: dma unmap mgmt tx buffer if wmi cmd send fails

Rakesh Pillai wrote: > WCN3990 sends mgmt frames by reference via WMI. > The host dma maps the mgmt frame and sends the physical > address to the firmware in the wmi command. Since the > dma mapping is done in the gen_mgmt_tx and if the wmi > command send fails, the

Re: [PATCH 2/3] mwifiex: fix incorrect ht capability problem

Ganapathi Bhat writes: > IEEE80211_CHAN_NO_HT40PLUS and IEEE80211_CHAN_NO_HT40PLUS channel > flags tell if HT40 operation is allowed on a channel or not. > > This patch ensures ht_capability information is modified > accordingly so that we don't end up creating a HT40

Re: [RESEND] rsi: Remove stack VLA usage

"Tobin C. Harding" writes: > Added Konstantin in case he is in charge of administering > patchwork.kernel.org? > > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding wrote: >> > On Tue, Mar 13, 2018 at

Re: [RESEND] rsi: Remove stack VLA usage

"Tobin C. Harding" writes: > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote: >> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> >> tcharding wrote: >> >> I'm

Re: [RESEND] rsi: Remove stack VLA usage

tcharding writes: > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> tcharding wrote: >> >> > The kernel would like to have all stack VLA usage removed[1]. rsi uses >> > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size >> >

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

Arend van Spriel writes: > On 3/13/2018 5:46 PM, Kalle Valo wrote: >> "Luis R. Rodriguez" writes: >> >>> On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote: "Luis R. Rodriguez" writes: >> +/** >> + *

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

Hi, On 13-03-18 21:19, Arend van Spriel wrote: On 3/12/2018 10:45 AM, Hans de Goede wrote: Actually had a Sony device with nvram in EFI. Why not just drop this optimization. Ok, do you know if that variable had the same name and guid though ? Because if it doesn't then this code is not

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

On 3/13/2018 5:46 PM, Kalle Valo wrote: "Luis R. Rodriguez" writes: On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote: "Luis R. Rodriguez" writes: +/** + * request_firmware_optional: - request for an optional fw module + * @firmware_p: