[PATCH v4] staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler

Change the config packet format used in handle_set_wfi_drv_handler() to align the host driver with the new format used in the wilc firmware. The change updates the format in which the host driver provides the firmware with the drv_handler index and also uses two new fields viz. "mode" and 'name"

[linux-wireless] [mac80211] Does IEEE80211_IBSS_MAX_STA_ENTRIES (in net/mac80211/ibss.c) work?

Hi community, Does IEEE80211_IBSS_MAX_STA_ENTRIES (in net/mac80211/ibss.c) work? I hard-code it to be 2 (from original 128), and update kernel for one node, and start IBSS network with 5 nodes. In the node with hard-coded IBSS_MAX_STA_ENTRIES = 2, I still can see and ping all other 4 nodes. I

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Hi Igor, On Wed, 7 Jun 2017 19:43:18 -0700 Igor Mitsyanko wrote: > > thanks. As I understand, you've applied this patch during a merge and no > further actions are required, correct? Dave Miller will need to apply that patch (or something similar) when he

Re: linux-next: build failure after merge of the wireless-drivers-next tree

On 06/07/2017 07:27 PM, Stephen Rothwell wrote: External Email Hi all, After merging the wireless-drivers-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/wireless/quantenna/qtnfmac/core.c: In function 'qtnf_core_net_attach':

linux-next: build failure after merge of the wireless-drivers-next tree

Hi all, After merging the wireless-drivers-next tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/wireless/quantenna/qtnfmac/core.c: In function 'qtnf_core_net_attach': drivers/net/wireless/quantenna/qtnfmac/core.c:319:5: error: 'struct net_device' has no

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

Oleksij Rempel wrote: > Am 07.06.2017 um 02:12 schrieb Tobias Diedrich: > > Oleksij Rempel wrote: > >> Yes, this is "normal" problem. The firmware has no error handler for PCI > >> bus related exceptions. So if we filed to read PCI bus first time, we > >> have choice to Ooops and stall or Ooops

[PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid, which gives 16 possible values for tid. This is problematic because IWL_MAX_TID_COUNT is 8, so indexing iwl_priv::tid_data can go very wrong. With UBSAN I can it happening while establishing the first connection after

Re: [PATCH 1/1] mac80211: ieee80211_rx_napi: remove warning

On Sun, 2017-06-04 at 15:11 +0200, Erik Stromdahl wrote: > The softirq count is not always incremented during driver > operation. This is the case for usb and sdio network > drivers. I'm pretty sure the warning is correct, and we do rely on having local_bh_disable(), otherwise we may end up

Re: [V4,1/3] brcmfmac: add support multi-scheduled scan

On 07-06-17 16:53, Kalle Valo wrote: > Arend van Spriel writes: > >> On 5/22/2017 5:16 PM, Kalle Valo wrote: >>> Arend Van Spriel wrote: From: Arend Van Spriel This change adds support for

Re: Wifi-Event for when initial 4-way completes?

On 06/07/2017 12:25 AM, Wojciech Dubowik wrote: Hello Ben, I have been using this part of wpa_supplicant to notify that 4-Way handshake is completed. around line 868 in wpa_supplicant.c #if defined(CONFIG_CTRL_IFACE) || !defined(CONFIG_NO_STDOUT_DEBUG) wpa_msg(wpa_s,

Re: [V4,1/3] brcmfmac: add support multi-scheduled scan

Arend van Spriel writes: > On 5/22/2017 5:16 PM, Kalle Valo wrote: >> Arend Van Spriel wrote: >>> From: Arend Van Spriel >>> >>> This change adds support for multi-scheduled scan in the driver. It >>>

Re: [V4,1/3] brcmfmac: add support multi-scheduled scan

On 5/22/2017 5:16 PM, Kalle Valo wrote: Arend Van Spriel wrote: From: Arend Van Spriel This change adds support for multi-scheduled scan in the driver. It currently relies on g-scan support in firmware and will set struct

Re: Wifi-Event for when initial 4-way completes?

+ hostap list On 6/7/2017 2:46 AM, Ben Greear wrote: I have been tracking down a nasty EAPOL related bug in ath10k, and found something that may be peripheral, or maybe it is significant. My logic is basically to kick supplicant, watch 'iw events', and then when I see something like "sta62

Re: Wifi-Event for when initial 4-way completes?

Hello Ben, I have been using this part of wpa_supplicant to notify that 4-Way handshake is completed. around line 868 in wpa_supplicant.c #if defined(CONFIG_CTRL_IFACE) || !defined(CONFIG_NO_STDOUT_DEBUG) wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_CONNECTED "- Connection to "

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

Am 07.06.2017 um 02:12 schrieb Tobias Diedrich: > Oleksij Rempel wrote: >> Yes, this is "normal" problem. The firmware has no error handler for PCI >> bus related exceptions. So if we filed to read PCI bus first time, we >> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot >>

Re: [PATCH] net: wireless: intel: iwlwifi: dvm: remove unused defines

On Wed, 2017-06-07 at 01:20 +0200, Seraphime Kirkovski wrote: > Those constants have been unused for quite some time now. > > Signed-off-by: Seraphime Kirkovski > --- > I've compile-tested it. Thanks. I've applied it to our internal tree and it will reach the mainline at