On 14 March 2018 at 20:02, 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
> array. So fix this accordingly.
>
>
Fix the following sparse warning in mwifiex_cmd_append_11n_tlv:
drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid assignment:
&=
drivers/net/wireless/marvell/mwifiex/11n.c:358:65:left side has type
restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:358:65:right
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. Thu
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 even further, removing now all
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 matter?
Because we want to
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
> array. So fix this according
+ 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);
MODULE_PARM_DESC(ps_e
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 exceuse? Could it be the
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 working in some specific
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 PM, Tobin C. Har
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
---
drivers/net/wireless/bro
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
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
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 code
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
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 firmware API.
> > >
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 the new API
> > ca
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 Broadcom's firmwares. Th
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? Something to improve?
V2:
Mo
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 firmwares. This is an obsoleted
standa
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 resulted in
discovering
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 good reason for #if
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 resulted in
discovering
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 firmwares can send 802.11f ADD
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"
> >>> >+depends on BRCMFMAC
> >>> >+---h
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 802.11f ADD frame every
>>> >+ti
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
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +
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 +-
drivers/ide/ide
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
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
https://lwn.net
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);
>MODULE_PARM_DESC(ps_enable, "Enable WLAN Power
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 standard
> and its implementation is som
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
Signed-off-by: Colin Ian King
---
dr
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 patch which had these changes. This patch can be ignore from
the
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
and its implementa
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 insertion(+)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgop
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 changed, 1 insertion(+)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/s
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 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_mon.c
b/driv
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 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wilc
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: wilc1000: use kmemdup instead of kmal
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 changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/stagi
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 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/w
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 changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/s
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 eeprom.
Introduce a module parameter endian_check
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 | 2 --
1 file changed,
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 error handling part
> >
> > Si
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
> ---
> drivers/staging/wilc1000/host_interface.
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) Most people don't n
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.
>
>
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 corresponding mgmt frame is
>
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 connection
> when it's not a
"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 11:00:47PM +0200, Andy Shevchenk
"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 pretty much sure it depends on the original emai
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
>> > is defined using a magic number.
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:
>> +/**
>> + * request_firmware_optional: - request for an optional fw module
>>
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 go
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: pointer to firmware image
+ * @name: name of
57 matches
Mail list logo
