* [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Gianfranco Costamagna @ 2016-10-28 16:15 UTC (permalink / raw)
To: brcm80211-dev-list@broadcom.com, arend.vanspriel@broadcom.com,
linux-wireless@vger.kernel.org
Cc: nsmaldone@tierratelematics.com, Marco.Arlone@roj.com
In-Reply-To: <CACJOhtKej4EZ3ufGGUr=Rf1X=hufmKtPLQH3y4x0kK4nNg5U0w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
(resending from my debian.org mail address, to avoid spam filtering)
Hi Broadcom developers and linux wireless list.
We found a possible issue in the cfg80211 implementation of the regulatory domain rules:
.reg_rules = {
/* IEEE 802.11b/g, channels 1..11 */
REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
the referred channel 11 has/should have a frequency of 2462, not 2472 (corresponding to channel 13).
Is this a typo in the code or the above comment?
(I'm not sure why the override of reg.c is in place for 2.4 Ghz frequencies)
Can you please double check and in case apply the attached patch?
thanks,
--
Gianfranco Costamagna
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-broadcom-cfg80211-fix-regulatory-channel-frequency.patch --]
[-- Type: text/x-diff, Size: 1248 bytes --]
From dc2eaeba8cf3d992a18745cfef1b74bbfc11715b Mon Sep 17 00:00:00 2001
From: Arlone Marco <marco.arlone@roj.com>
Date: Sat, 22 Oct 2016 15:08:35 +0200
Subject: [PATCH] broadcom cfg80211: fix regulatory channel frequency channel
11 is actually 2462, not 2472 (that is channel 13 instead)
Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
Signed-off-by: Arlone Marco <marco.arlone@roj.com>
Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..d71f959 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -204,7 +204,7 @@ static const struct ieee80211_regdomain brcmf_regdom = {
.alpha2 = "99",
.reg_rules = {
/* IEEE 802.11b/g, channels 1..11 */
- REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
+ REG_RULE(2412-10, 2462+10, 40, 6, 20, 0),
/* If any */
/* IEEE 802.11 channel 14 - Only JP enables
* this and for 802.11b only
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map
From: Johannes Berg @ 2016-10-28 15:46 UTC (permalink / raw)
To: Filip Matusiak, linux-wireless
Cc: marek.kwaczynski, davem, netdev, linux-kernel
In-Reply-To: <1477665523-8970-1-git-send-email-filip.matusiak@tieto.com>
On Fri, 2016-10-28 at 16:38 +0200, Filip Matusiak wrote:
> This is a workaround for VHT-enabled STAs which break the spec
> and have the VHT-MCS Rx map filled in with value 3 for all eight
> spacial streams.
>
> As per spec, in section 22.1.1 Introduction to the VHT PHY
> A VHT STA shall support at least single spactial stream VHT-MCSs
> 0 to 7 (transmit and receive) in all supported channel widths.
Interesting, and also kinda dumb :)
> + /*
> + * This is a workaround for VHT-enabled STAs which break the
>
I find that it helps, in the future, if we know an example of a station
that did this, so we can test other implementations etc. Can you change
the comment accordingly?
johannes
^ permalink raw reply
* [PATCH] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map
From: Filip Matusiak @ 2016-10-28 14:38 UTC (permalink / raw)
To: linux-wireless
Cc: filip.matusiak, marek.kwaczynski, johannes, davem, netdev,
linux-kernel
This is a workaround for VHT-enabled STAs which break the spec
and have the VHT-MCS Rx map filled in with value 3 for all eight
spacial streams.
As per spec, in section 22.1.1 Introduction to the VHT PHY
A VHT STA shall support at least single spactial stream VHT-MCSs
0 to 7 (transmit and receive) in all supported channel widths.
For some devices firmware asserts if such situation occurs.
Signed-off-by: Filip Matusiak <filip.matusiak@tieto.com>
---
net/mac80211/vht.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..ce93cff 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -270,6 +270,22 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata,
vht_cap->vht_mcs.tx_mcs_map |= cpu_to_le16(peer_tx << i * 2);
}
+ /*
+ * This is a workaround for VHT-enabled STAs which break the spec
+ * and have the VHT-MCS Rx map filled in with value 3 for all eight
+ * spacial streams.
+ *
+ * As per spec, in section 22.1.1 Introduction to the VHT PHY
+ * A VHT STA shall support at least single spactial stream VHT-MCSs
+ * 0 to 7 (transmit and receive) in all supported channel widths.
+ */
+ if (vht_cap->vht_mcs.rx_mcs_map == cpu_to_le16(0xFFFF)) {
+ vht_cap->vht_supported = false;
+ sdata_info(sdata, "Ignoring VHT IE from %pM due to invalid rx_mcs_map\n",
+ sta->addr);
+ return;
+ }
+
/* finally set up the bandwidth */
switch (vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ:
--
2.7.4
^ permalink raw reply related
* [v2] pull-request: mac80211-next 2016-10-28
From: Johannes Berg @ 2016-10-28 11:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
First update for 4.10 - nothing major, new features as usual (FILS), and
sometimes we deprecate old stuff (WDS).
I don't have the fixes for the on-stack crypto/SG handling in this tree
(you already have them via mac80211.git), but we did make sure that the
fils_aead code doesn't re-introduce such an issue.
This one is with Arnd's fix included.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 6b25e21fa6f26d0f0d45f161d169029411c84286:
Merge tag 'drm-for-v4.9' of git://people.freedesktop.org/~airlied/linux (2016-10-11 18:12:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-10-28
for you to fetch changes up to 514877182b537372352c14a0a50822572f66e831:
mac80211: fils_aead: fix encrypt error handling (2016-10-28 12:59:12 +0200)
----------------------------------------------------------------
Among various cleanups and improvements, we have the following:
* client FILS authentication support in mac80211 (Jouni)
* AP/VLAN multicast improvements (Michael Braun)
* config/advertising support for differing beacon intervals on
multiple virtual interfaces (Purushottam Kushwaha, myself)
* deprecate the old WDS mode for cfg80211-based drivers, the
mode is hardly usable since it doesn't support any "modern"
features like WPA encryption (2003), HT (2009) or VHT (2014),
I'm not even sure WEP (introduced in 1997) could be done.
----------------------------------------------------------------
Andrei Otcheretianski (1):
cfg80211: allow vendor commands to be sent to nan interface
Arend Van Spriel (1):
cfg80211: add generic helper to check interface is running
Arnd Bergmann (1):
mac80211: fils_aead: fix encrypt error handling
Emmanuel Grumbach (2):
mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger
mac80211: uapsd_queues is in QoS IE order
Ilan Peer (1):
cfg80211: allow aborting in-progress connection atttempts
Johannes Berg (17):
mac80211: remove unnecessary mesh check
mac80211_hwsim: make multi-channel ops const
mac80211: preserve more bits when building QoS header
nl80211: correctly use nl80211_nan_srf_policy
nl80211: ifdef WoWLAN related policies
wireless: radiotap: fix timestamp sampling position values
mac80211: fix tid_agg_rx NULL dereference
mac80211: improve RX aggregation data in debugfs
wireless: deprecate WDS and disable by default
cfg80211: fix beacon interval in interface combination iteration
cfg80211: mesh: track (and thus validate) beacon interval
cfg80211: disallow beacon_int_min_gcd with IBSS
cfg80211: validate beacon int as part of iface combinations
mac80211: validate new interface's beacon intervals
nl80211: move unsplit command advertising to a separate function
nl80211: use nla_parse_nested() instead of nla_parse()
cfg80211: handle fragmented IEs in splitting
Jouni Malinen (9):
cfg80211: Rename SAE_DATA to more generic AUTH_DATA
mac80211: Allow AUTH_DATA to be used for FILS
cfg80211: Add feature flag for Fast Initial Link Setup (FILS) as STA
cfg80211: Define IEEE P802.11ai (FILS) information elements
cfg80211: Add Fast Initial Link Setup (FILS) auth algs
cfg80211: Add KEK/nonces for FILS association frames
mac80211: Add FILS auth alg mapping
mac80211: FILS AEAD protection for station mode association frames
mac80211: Claim Fast Initial Link Setup (FILS) STA support
Linus Lüssing (1):
mac80211_hwsim: suggest nl80211 instead of wext driver in documentation
Michael Braun (5):
mac80211: remove unnecessary num_mcast_sta check
mac80211: filter multicast data packets on AP / AP_VLAN
mac80211: avoid extra memcpy in A-MSDU head creation
mac80211: fix A-MSDU outer SA/DA
cfg80211: configure multicast to unicast for AP interfaces
Purushottam Kushwaha (2):
cfg80211: pass struct to interface combination check/iter
cfg80211: support virtual interfaces with different beacon intervals
Sara Sharon (1):
mac80211: add a HW flag for supporting HW TX fragmentation
Wei Yongjun (1):
cfg80211: fix possible memory leak in cfg80211_iter_combinations()
vamsi krishna (1):
cfg80211: Add support to update connection parameters
Documentation/networking/mac80211_hwsim/README | 2 +-
drivers/net/wireless/Kconfig | 13 +
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ath/ath9k/init.c | 6 +
drivers/net/wireless/broadcom/b43/main.c | 2 +
drivers/net/wireless/broadcom/b43legacy/main.c | 2 +
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 22 +-
drivers/net/wireless/mac80211_hwsim.c | 79 ++--
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 6 +-
drivers/net/wireless/ti/wlcore/main.c | 1 +
include/linux/ieee80211.h | 26 ++
include/net/cfg80211.h | 150 +++++--
include/net/ieee80211_radiotap.h | 4 +-
include/net/mac80211.h | 19 +-
include/uapi/linux/nl80211.h | 69 +++-
net/mac80211/Makefile | 1 +
net/mac80211/aes_cmac.c | 8 +-
net/mac80211/aes_cmac.h | 4 +
net/mac80211/agg-rx.c | 8 +-
net/mac80211/cfg.c | 35 +-
net/mac80211/debugfs.c | 1 +
net/mac80211/debugfs_netdev.c | 11 +
net/mac80211/debugfs_sta.c | 9 +-
net/mac80211/fils_aead.c | 342 ++++++++++++++++
net/mac80211/fils_aead.h | 19 +
net/mac80211/ieee80211_i.h | 26 +-
net/mac80211/iface.c | 16 +
net/mac80211/main.c | 5 +
net/mac80211/mlme.c | 60 ++-
net/mac80211/rx.c | 11 +-
net/mac80211/sta_info.c | 23 +-
net/mac80211/sta_info.h | 4 +-
net/mac80211/tx.c | 55 ++-
net/mac80211/util.c | 61 +--
net/mac80211/wme.c | 23 +-
net/mac80211/wpa.c | 2 +-
net/wireless/core.c | 33 +-
net/wireless/core.h | 4 +-
net/wireless/mesh.c | 2 +
net/wireless/mlme.c | 6 +-
net/wireless/nl80211.c | 445 +++++++++++++--------
net/wireless/rdev-ops.h | 24 ++
net/wireless/sme.c | 2 +-
net/wireless/trace.h | 37 ++
net/wireless/util.c | 125 ++++--
45 files changed, 1383 insertions(+), 421 deletions(-)
create mode 100644 net/mac80211/fils_aead.c
create mode 100644 net/mac80211/fils_aead.h
^ permalink raw reply
* Re: [PATCH] mac80211: fils_aead: fix encrypt error handling
From: Johannes Berg @ 2016-10-28 10:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Jouni Malinen, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20161028102621.1881878-1-arnd@arndb.de>
On Fri, 2016-10-28 at 12:25 +0200, Arnd Bergmann wrote:
> gcc -Wmaybe-uninitialized reports a bug in aes_siv_encryp:
>
> net/mac80211/fils_aead.c: In function ‘aes_siv_encrypt.constprop’:
> net/mac80211/fils_aead.c:84:26: error: ‘tfm2’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> At the time that the memory allocation fails, 'tfm2' has not been
> allocated, so we should not attempt to free it later, and we can
> simply return an error.
>
> Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode
> association frames")
Ahrg, how did I miss that.
Dave, I'll apply this, and send a new pull request.
johannes
^ permalink raw reply
* [PATCH] mac80211: fils_aead: fix encrypt error handling
From: Arnd Bergmann @ 2016-10-28 10:25 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, David S. Miller, Jouni Malinen, linux-wireless,
netdev, linux-kernel
gcc -Wmaybe-uninitialized reports a bug in aes_siv_encryp:
net/mac80211/fils_aead.c: In function ‘aes_siv_encrypt.constprop’:
net/mac80211/fils_aead.c:84:26: error: ‘tfm2’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
At the time that the memory allocation fails, 'tfm2' has not been
allocated, so we should not attempt to free it later, and we can
simply return an error.
Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/mac80211/fils_aead.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/fils_aead.c b/net/mac80211/fils_aead.c
index b81b4f2472cf..ecfdd97758a3 100644
--- a/net/mac80211/fils_aead.c
+++ b/net/mac80211/fils_aead.c
@@ -110,10 +110,8 @@ static int aes_siv_encrypt(const u8 *key, size_t key_len,
* overwriting this during AES-CTR.
*/
tmp = kmemdup(plain, plain_len, GFP_KERNEL);
- if (!tmp) {
- res = -ENOMEM;
- goto fail;
- }
+ if (!tmp)
+ return -ENOMEM;
/* IV for CTR before encrypted data */
memcpy(out, v, AES_BLOCK_SIZE);
--
2.9.0
^ permalink raw reply related
* pull-request: mac80211-next 2016-10-28
From: Johannes Berg @ 2016-10-28 7:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
First update for 4.10 - nothing major, new features as usual (FILS), and
sometimes we deprecate old stuff (WDS).
I don't have the fixes for the on-stack crypto/SG handling in this tree
(you already have them via mac80211.git), but we did make sure that the
fils_aead code doesn't re-introduce such an issue.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 6b25e21fa6f26d0f0d45f161d169029411c84286:
Merge tag 'drm-for-v4.9' of git://people.freedesktop.org/~airlied/linux (2016-10-11 18:12:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-10-28
for you to fetch changes up to 088e8df82f91a24728d49d9532cab7ebdee5117f:
cfg80211: Add support to update connection parameters (2016-10-27 16:03:28 +0200)
----------------------------------------------------------------
Among various cleanups and improvements, we have the following:
* client FILS authentication support in mac80211 (Jouni)
* AP/VLAN multicast improvements (Michael Braun)
* config/advertising support for differing beacon intervals on
multiple virtual interfaces (Purushottam Kushwaha, myself)
* deprecate the old WDS mode for cfg80211-based drivers, the
mode is hardly usable since it doesn't support any "modern"
features like WPA encryption (2003), HT (2009) or VHT (2014),
I'm not even sure WEP (introduced in 1997) could be done.
----------------------------------------------------------------
Andrei Otcheretianski (1):
cfg80211: allow vendor commands to be sent to nan interface
Arend Van Spriel (1):
cfg80211: add generic helper to check interface is running
Emmanuel Grumbach (2):
mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger
mac80211: uapsd_queues is in QoS IE order
Ilan Peer (1):
cfg80211: allow aborting in-progress connection atttempts
Johannes Berg (17):
mac80211: remove unnecessary mesh check
mac80211_hwsim: make multi-channel ops const
mac80211: preserve more bits when building QoS header
nl80211: correctly use nl80211_nan_srf_policy
nl80211: ifdef WoWLAN related policies
wireless: radiotap: fix timestamp sampling position values
mac80211: fix tid_agg_rx NULL dereference
mac80211: improve RX aggregation data in debugfs
wireless: deprecate WDS and disable by default
cfg80211: fix beacon interval in interface combination iteration
cfg80211: mesh: track (and thus validate) beacon interval
cfg80211: disallow beacon_int_min_gcd with IBSS
cfg80211: validate beacon int as part of iface combinations
mac80211: validate new interface's beacon intervals
nl80211: move unsplit command advertising to a separate function
nl80211: use nla_parse_nested() instead of nla_parse()
cfg80211: handle fragmented IEs in splitting
Jouni Malinen (9):
cfg80211: Rename SAE_DATA to more generic AUTH_DATA
mac80211: Allow AUTH_DATA to be used for FILS
cfg80211: Add feature flag for Fast Initial Link Setup (FILS) as STA
cfg80211: Define IEEE P802.11ai (FILS) information elements
cfg80211: Add Fast Initial Link Setup (FILS) auth algs
cfg80211: Add KEK/nonces for FILS association frames
mac80211: Add FILS auth alg mapping
mac80211: FILS AEAD protection for station mode association frames
mac80211: Claim Fast Initial Link Setup (FILS) STA support
Linus Lüssing (1):
mac80211_hwsim: suggest nl80211 instead of wext driver in documentation
Michael Braun (5):
mac80211: remove unnecessary num_mcast_sta check
mac80211: filter multicast data packets on AP / AP_VLAN
mac80211: avoid extra memcpy in A-MSDU head creation
mac80211: fix A-MSDU outer SA/DA
cfg80211: configure multicast to unicast for AP interfaces
Purushottam Kushwaha (2):
cfg80211: pass struct to interface combination check/iter
cfg80211: support virtual interfaces with different beacon intervals
Sara Sharon (1):
mac80211: add a HW flag for supporting HW TX fragmentation
Wei Yongjun (1):
cfg80211: fix possible memory leak in cfg80211_iter_combinations()
vamsi krishna (1):
cfg80211: Add support to update connection parameters
Documentation/networking/mac80211_hwsim/README | 2 +-
drivers/net/wireless/Kconfig | 13 +
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ath/ath9k/init.c | 6 +
drivers/net/wireless/broadcom/b43/main.c | 2 +
drivers/net/wireless/broadcom/b43legacy/main.c | 2 +
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 22 +-
drivers/net/wireless/mac80211_hwsim.c | 79 ++--
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 6 +-
drivers/net/wireless/ti/wlcore/main.c | 1 +
include/linux/ieee80211.h | 26 ++
include/net/cfg80211.h | 150 +++++--
include/net/ieee80211_radiotap.h | 4 +-
include/net/mac80211.h | 19 +-
include/uapi/linux/nl80211.h | 69 +++-
net/mac80211/Makefile | 1 +
net/mac80211/aes_cmac.c | 8 +-
net/mac80211/aes_cmac.h | 4 +
net/mac80211/agg-rx.c | 8 +-
net/mac80211/cfg.c | 35 +-
net/mac80211/debugfs.c | 1 +
net/mac80211/debugfs_netdev.c | 11 +
net/mac80211/debugfs_sta.c | 9 +-
net/mac80211/fils_aead.c | 344 ++++++++++++++++
net/mac80211/fils_aead.h | 19 +
net/mac80211/ieee80211_i.h | 26 +-
net/mac80211/iface.c | 16 +
net/mac80211/main.c | 5 +
net/mac80211/mlme.c | 60 ++-
net/mac80211/rx.c | 11 +-
net/mac80211/sta_info.c | 23 +-
net/mac80211/sta_info.h | 4 +-
net/mac80211/tx.c | 55 ++-
net/mac80211/util.c | 61 +--
net/mac80211/wme.c | 23 +-
net/mac80211/wpa.c | 2 +-
net/wireless/core.c | 33 +-
net/wireless/core.h | 4 +-
net/wireless/mesh.c | 2 +
net/wireless/mlme.c | 6 +-
net/wireless/nl80211.c | 445 +++++++++++++--------
net/wireless/rdev-ops.h | 24 ++
net/wireless/sme.c | 2 +-
net/wireless/trace.h | 37 ++
net/wireless/util.c | 125 ++++--
45 files changed, 1385 insertions(+), 421 deletions(-)
create mode 100644 net/mac80211/fils_aead.c
create mode 100644 net/mac80211/fils_aead.h
^ permalink raw reply
* Re: [PATCH v2 5/5] mwifiex: wait firmware dump complete during card remove process
From: Brian Norris @ 2016-10-27 18:48 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Xinming Hu
In-Reply-To: <1477559563-18328-5-git-send-email-akarwar@marvell.com>
Hi,
On Thu, Oct 27, 2016 at 02:42:43PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> Wait for firmware dump complete in card remove function.
> For sdio interface, there are two diffenrent cases,
> card reset trigger sdio_work and firmware dump trigger sdio_work.
> Do code rearrangement for distinguish between these two cases.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: 1. Get rid of reset_triggered flag. Instead split the code and use
> __mwifiex_sdio_remove() (Brian Norris/Dmitry Torokhov)
> 2. "v1 4/5 mwifiex: firmware dump code rearrangement.." is dropped. So
> rebased accordingly.
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 6 +++++-
> drivers/net/wireless/marvell/mwifiex/sdio.c | 15 ++++++++++++---
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 9025af7..6c421ad 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -37,6 +37,9 @@ static struct mwifiex_if_ops pcie_ops;
>
> static struct semaphore add_remove_card_sem;
>
> +static void mwifiex_pcie_work(struct work_struct *work);
> +static DECLARE_WORK(pcie_work, mwifiex_pcie_work);
This work_struct didn't need to be static in the first place; it should
be embedded in the 'card' and initialized during device init. Then once
you cancel the work in remove() (like this patch is doing) you can also
kill the cancel_work_sync() from the module_exit() path -- you really
shouldn't be doing work like this in the module_init()/module_exit(). It
all belongs in device init/teardown.
> +
> static int
> mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
> size_t size, int flags)
> @@ -249,6 +252,8 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
> if (!adapter || !adapter->priv_num)
> return;
>
> + cancel_work_sync(&pcie_work);
Hmm, actually what happens if we have !adapter? Then that means we've
already torn down the device (e.g., unregister_dev() -- except we
haven't quite fixed that bug, see the other patch series you sent out),
and so we'll never reach this. But that also means we haven't
synchronized any outstanding work.
So this really belongs in one of the earlier mwifiex callbacks
(unregister_dev()?), and not in the device remove() callback.
Same applies to sdio.c I think.
Brian
> +
> if (user_rmmod && !adapter->mfg_mode) {
> #ifdef CONFIG_PM_SLEEP
> if (adapter->is_suspended)
> @@ -2716,7 +2721,6 @@ static void mwifiex_pcie_work(struct work_struct *work)
> mwifiex_pcie_device_dump_work(save_adapter);
> }
>
> -static DECLARE_WORK(pcie_work, mwifiex_pcie_work);
> /* This function dumps FW information */
> static void mwifiex_pcie_device_dump(struct mwifiex_adapter *adapter)
> {
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index 241d2b3..5d84c563 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -46,6 +46,9 @@
> */
> static u8 user_rmmod;
>
> +static void mwifiex_sdio_work(struct work_struct *work);
> +static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
> +
> static struct mwifiex_if_ops sdio_ops;
> static unsigned long iface_work_flags;
>
> @@ -275,7 +278,7 @@ static int mwifiex_sdio_resume(struct device *dev)
> * This function removes the interface and frees up the card structure.
> */
> static void
> -mwifiex_sdio_remove(struct sdio_func *func)
> +__mwifiex_sdio_remove(struct sdio_func *func)
> {
> struct sdio_mmc_card *card;
> struct mwifiex_adapter *adapter;
> @@ -305,6 +308,13 @@ mwifiex_sdio_remove(struct sdio_func *func)
> mwifiex_remove_card(card->adapter, &add_remove_card_sem);
> }
>
> +static void
> +mwifiex_sdio_remove(struct sdio_func *func)
> +{
> + cancel_work_sync(&sdio_work);
> + __mwifiex_sdio_remove(func);
> +}
> +
> /*
> * SDIO suspend.
> *
> @@ -2290,7 +2300,7 @@ static void mwifiex_recreate_adapter(struct sdio_mmc_card *card)
> * discovered and initializes them from scratch.
> */
>
> - mwifiex_sdio_remove(func);
> + __mwifiex_sdio_remove(func);
>
> /* power cycle the adapter */
> sdio_claim_host(func);
> @@ -2623,7 +2633,6 @@ static void mwifiex_sdio_work(struct work_struct *work)
> mwifiex_sdio_card_reset_work(save_adapter);
> }
>
> -static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
> /* This function resets the card */
> static void mwifiex_sdio_card_reset(struct mwifiex_adapter *adapter)
> {
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting
From: Johannes Berg @ 2016-10-27 18:42 UTC (permalink / raw)
To: Denis Kenzior, Zaborowski, Andrew, linux-wireless@vger.kernel.org
In-Reply-To: <581243A0.3070907@gmail.com>
> Pardon a dumb question, but can filtering be turned off? I doubt
> anyone would want to, but just wondering.
Generally I assume that a typical device/firmware will be able to turn
it off (I know ours can), but we don't think we even provide a knob for
it for anyone to request it, so you'd have to modify the driver.
> Is there anything you have in mind? Our goal is to minimize
> hardware-kernel-userspace wakeups. With the nl80211 API as it is
> today, it doesn't seem feasible to do anything besides
> polling. Whatever we come up with will surely be better than that.
I was thinking of just providing two thresholds, since you should be
able to emulate more of them with that, without much cost.
> So you're thinking of having high and low threshold. So we'd get an
> event when we're higher than the high threshold and lower than the
> low threshold, right?
I'm mostly handwaving, but yes.
> Then we'd need to bootstrap our current rssi somehow, or do we get
> another event? I'm guessing we're going to have some race condition
> issues?
Generally, with CQM, when you initially program it you get an event
telling you where you're at right now - so hopefully you'd get "middle"
(rather than "low"/"high") with the actual signal falling squarely into
your range, and from there on you're pretty much good to go.
> Would using an n-threshold API be possible? That way user space can
> program in whatever threholds once, and then the kernel would figure
> out how to support that given the relevant hardware capabilities.
That seems like a reasonable idea. We'd want to have code in cfg80211
that does the emulation as we discussed above, so that from a userspace
POV an "arbitrary" number of thresholds is supported (if the capability
is supported at all, which would depend on the device doing >=2
thresholds).
johannes
^ permalink raw reply
* Re: [PATCH v2 1/5] mwifiex: remove redundant condition in main process
From: Brian Norris @ 2016-10-27 18:35 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov
In-Reply-To: <1477559563-18328-1-git-send-email-akarwar@marvell.com>
On Thu, Oct 27, 2016 at 02:42:39PM +0530, Amitkumar Karwar wrote:
> This condition while calling mwifiex_check_ps_cond() is redundant.
> The function internally already takes care of it.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Same as v1
You've omitted the Reviewed-by tags from v1:
Reviewed-by: Brian Norris <briannorris@chromium.org>
^ permalink raw reply
* Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting
From: Denis Kenzior @ 2016-10-27 18:12 UTC (permalink / raw)
To: Johannes Berg, Zaborowski, Andrew, linux-wireless@vger.kernel.org
In-Reply-To: <1477487137.4059.43.camel@sipsolutions.net>
Hi Johannes,
> Huh? No, beacon filtering is implemented by a lot of drivers today.
Pardon a dumb question, but can filtering be turned off? I doubt anyone
would want to, but just wondering.
>
>> The userspace switches count too and are the main motivation for this
>> patch. Eventually, as you say, things will depend on specific
>> drivers and you will want to optimise whatever you can assuming the
>> hardware you're constrained to.
>
> Yes and no. I think we can probably define a reasonable subset that
> you'd expect more devices to implement. I don't really see the
> requirement to do the "banding" that you did here offloaded - doing it
> in mac80211 won't help much, and won't work in cases where you have
> beacon filtering already anyway.
Is there anything you have in mind? Our goal is to minimize
hardware-kernel-userspace wakeups. With the nl80211 API as it is today,
it doesn't seem feasible to do anything besides polling. Whatever we
come up with will surely be better than that.
> Well, ok, technically the API can be implemented on top of drivers with
> low/high thresholds, by doing the configuration according to the
> current range you're in.
So you're thinking of having high and low threshold. So we'd get an
event when we're higher than the high threshold and lower than the low
threshold, right? Then we'd need to bootstrap our current rssi somehow,
or do we get another event? I'm guessing we're going to have some race
condition issues?
>
> I would argue though that it makes more sense to expose a simpler
> capability (e.g. two instead of the current single threshold) and do
> the reprogramming from higher layers. That ends up being more flexible,
> since you can then, for example, also have ranges that aren't all
> identical - which makes some sense because above a certain level you
> don't really care at all.
It seems like we'd be limiting ourselves here. Couple reasons that come
to mind:
- This would still require user space to keep re-setting the new
thresholds. While the wakeups are much less frequent than with polling
for example, they still add up. Scheduling userspace, processing
nl80211 messages, etc is still a cost.
- It feels like we're exposing a lowest-common-denominator API with no
possibility of offload / optimization in the future. E.g. even drivers
that can support arbitrary number of thresholds will be boxed in.
Would using an n-threshold API be possible? That way user space can
program in whatever threholds once, and then the kernel would figure out
how to support that given the relevant hardware capabilities.
>
>> In short a nl80211 change would be needed regardless of the mechanism
>> chosen.
>
> Agree. I'm just not convinced that the banding mechanism you propose is
> the most reasonable choice for new API.
>
Understood, but it was just a stab in the dark to get this discussion
started.
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Dmitry Torokhov @ 2016-10-27 17:44 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris
In-Reply-To: <1477559563-18328-2-git-send-email-akarwar@marvell.com>
Hi Amit,
On Thu, Oct 27, 2016 at 02:42:40PM +0530, Amitkumar Karwar wrote:
> This variable is guarded by spinlock at all other places. This patch
> takes care of missing spinlock usage in mwifiex_shutdown_drv().
Since in the previous discussion you stated that we inhibit interrupts
and flush the workqueue so that mwifiex_shutdown_drv() can't run
simultaneously with the main processing routine, why do we need this?
Instead please remove call to mwifiex_shutdown_drv() in the main routine
and "if (adapter->mwifiex_processing)" check here.
Thanks.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Same as v1
> ---
> drivers/net/wireless/marvell/mwifiex/init.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
> index 82839d9..8e5e424 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -670,11 +670,14 @@ mwifiex_shutdown_drv(struct mwifiex_adapter *adapter)
>
> adapter->hw_status = MWIFIEX_HW_STATUS_CLOSING;
> /* wait for mwifiex_process to complete */
> + spin_lock_irqsave(&adapter->main_proc_lock, flags);
> if (adapter->mwifiex_processing) {
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> mwifiex_dbg(adapter, WARN,
> "main process is still running\n");
> return ret;
> }
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
>
> /* cancel current command */
> if (adapter->curr_cmd) {
> --
> 1.9.1
>
--
Dmitry
^ permalink raw reply
* Re: [RFC] mac80211: set wifi_acked[_valid] bits for transmitted SKBs
From: Dave Taht @ 2016-10-27 16:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20161027142103.19756-1-johannes@sipsolutions.net>
On Thu, Oct 27, 2016 at 7:21 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There may be situations in which the in-kernel originator of an
> SKB cares about its wifi transmission status. To have that, set
> the wifi_acked[_valid] bits before freeing/orphaning the SKB if
> the destructor is set. The originator can then use it in there.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> net/mac80211/status.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/mac80211/status.c b/net/mac80211/status.c
> index ddf71c648cab..dc3132d0effe 100644
> --- a/net/mac80211/status.c
> +++ b/net/mac80211/status.c
> @@ -541,6 +541,11 @@ static void ieee80211_report_used_skb(struct ieee802=
11_local *local,
> } else if (info->ack_frame_id) {
> ieee80211_report_ack_skb(local, info, acked, dropped);
> }
> +
> + if (!dropped && skb->destructor) {
> + skb->wifi_acked_valid =3D 1;
> + skb->wifi_acked =3D acked;
> + }
> }
One of the things I've been curious about one day trying to take advantage =
of
is the pacing available from sch_fq, in a world where we were trying
to take advantage of the chocolatey goodness of the new TCP BBR
congestion control algorithm. (sch_fq is apparently required for BBR
to work right)
By moving the fq_codel algo into the softmac layer as we are doing, we
currently expose the "noqueue" interface to the qdisc layer, there, which
works great for routers, but for dual use (acting as a NAS host and
routing) seems less than ideal.
Now it turns out that you can indeed slap the fq qdisc on top of the
new wifi intermediate queues code...
dave@nemesis:~/slashdot$ tc -s qdisc show dev wlp3s0
qdisc fq 8001: root refcnt 5 limit 10000p flow_limit 100p buckets 1024
orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay
40.0ms
Sent 30828141202 bytes 20530733 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1127 flows (1127 inactive, 0 throttled)
0 gc, 117 highprio, 714646 throttled
but as 1127 inactive flows have been there for a day now, and don't
show up in netstat, I guess that somewhere in here we aren't
"retiring" a skb in a way the tcp stack understands.
root@nemesis:~/slashdot# tc qdisc del dev wlp3s0 root
root@nemesis:~/slashdot# tc -s qdisc show dev wlp3s0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
>
> /*
> --
> 2.9.3
>
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2016-10-25-2
From: Kalle Valo @ 2016-10-27 15:32 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1477469629.27792.8.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> Here's an updated pull-request, replacing 2016-10-25, with one commit
> message reworded, as you requested.
>
> I sent v2 of that patch to the linux-wireless mailing list.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 15b95a15950238eff4d7f24be1716086eea67835:
>
> Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2016-09-28 16:37:33 +0300)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2016-10-25-2
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* wireless-drivers-next open for 4.10
From: Kalle Valo @ 2016-10-27 15:28 UTC (permalink / raw)
To: linux-wireless
Delayed due to my trip last week but wireless-drivers-next is now open
for new features going to 4.10.
wireless-drivers remains open for important fixes for 4.9.
--
Kalle Valo
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Johannes Berg @ 2016-10-27 15:06 UTC (permalink / raw)
To: Sebastian Gottschall, Kalle Valo, Antonio Quartulli
Cc: ath9k-devel, linux-wireless, sw, Antonio Quartulli
In-Reply-To: <62a2dc74-4a7c-d3d4-4170-4d5759b07ab3@dd-wrt.com>
On Thu, 2016-10-27 at 09:54 +0200, Sebastian Gottschall wrote:
> all patches have a unclear license since most patches are not comming
> with any licence declaration ;-)
You should read the DCO some time. Maybe you shouldn't be sending
patches if you think so.
johannes
^ permalink raw reply
* Re: [19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Kalle Valo @ 2016-10-27 15:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Arnd Bergmann,
Hante Meuleman, Franky Lin, Pieter-Paul Giesberts,
Franky (Zhenhui) Lin, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev
In-Reply-To: <20161017221355.1861551-7-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> A bugfix added a sanity check around the assignment and use of the
> 'is_11d' variable, which looks correct to me, but as the function is
> rather complex already, this confuses the compiler to the point where
> it can no longer figure out if the variable is always initialized
> correctly:
>
> brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
> brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This adds an initialization for the newly introduced case in which
> the variable should not really be used, in order to make the warning
> go away.
>
> Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers.git, thanks.
d3532ea6ce4e brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
--
https://patchwork.kernel.org/patch/9380763/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: pull-request: iwlwifi 2016-10-25
From: Kalle Valo @ 2016-10-27 15:02 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1477388323.17122.27.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> Here are 7 patches intended for 4.9. =C2=A0They fix some small issues, as
> described in the tag itself. I sent them out for review on 2016-10-19,=20
> and pushed to a pending branch. Kbuildbot didn't find any issues.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 1ea2643961b0d1b8d0e4a11af5aa69b0f92d05=
33:
>
> ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro (2016-10-13 14:16:33 =
+0300)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git=
tags/iwlwifi-for-kalle-2016-10-25
Pulled, thanks.
--=20
Kalle Valo
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Sebastian Gottschall @ 2016-10-27 7:54 UTC (permalink / raw)
To: Kalle Valo, Antonio Quartulli
Cc: ath9k-devel, linux-wireless, sw, Antonio Quartulli
In-Reply-To: <87bmy65nz8.fsf@kamboji.qca.qualcomm.com>
all patches have a unclear license since most patches are not comming
with any licence declaration ;-)
Am 27.10.2016 um 08:02 schrieb Kalle Valo:
> Antonio Quartulli <a@unstable.cc> writes:
>
>> On Wed, Oct 26, 2016 at 05:05:14PM +0300, Kalle Valo wrote:
>>> Antonio Quartulli <a@unstable.cc> writes:
>>>
>>>> From: Antonio Quartulli <antonio@open-mesh.com>
>>>>
>>>> This patch was crafted long time ago to work around a key cache
>>>> corruption problem on ath9k chipsets.
>>>>
>>>> The workaround consists in periodically triggering a worker that
>>>> uploads all the keys to the HW cache. The worker is triggered also
>>>> when the vif detects 21 undecryptable packets.
>>>>
>>>>
>>>> This patch is based on top compat-wireless-2015-10-26.
>>>>
>>>>
>>>> I was asked to release this code to the public and, since it is
>>>> GPL, I am now doing it.
>>> GPL? AFAICS ath9k is under ISC. I'm not sure what you mean with the
>>> sentence above, but it's possible to interpret it so that this patch is
>>> not under ISC license, which is problematic.
>> Honestly, my sentence was just a way to say "it makes sense to release this
>> patch to the public".
> I was suspecting it was like that, I just wasn't sure.
>
>> If it needs to be ISC in order to be merged, then it can be released under ISC.
>>
>> I don't want to enter a legal case :)
> Me neither. But I can't apply patches with unclear license.
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: Outdated wl12xx firmwares
From: Gary Bisson @ 2016-10-27 10:45 UTC (permalink / raw)
To: linux-firmware; +Cc: linux-wireless
In-Reply-To: <CAAMH-ytch0sbtjfp8rjUCNbEkj4euBES7a4n9niS1DtMZk2EKA@mail.gmail.com>
Hi,
Adding linux-wireless in CC, hoping to get more traction.
Just checked the MAINTAINERS file of this driver and it is listed as
'Orphan', so is it ok if a non-TI person submits the up-to-date
firmware files?
Regards,
Gary
On Fri, Oct 14, 2016 at 7:32 PM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> Hi,
>
> I am wondering why the w127x and wl128x firmware files have not been
> updated to their latest version (since Jan 2014)?
>
> The current version in the linux-firmware repo are:
> - 6.3.10.0.133 for single-role
> - 6.5.7.0.42 for multi-role
>
> Looking at TI's forum[1], they recommend using the latest one to avoid
> issues like firmware reload:
> - 6.3.10.0.139 for single-role
> - 6.5.7.0.47 for multi-role
>
> The up-to-date firmware files can be found in the following repo:
> https://github.com/TI-OpenLink/ti-utils/tree/master/hw/firmware
>
> What is the procedure to update them, does it need to be a TI employee
> that sends the patch? The former wl12xx maintainer (Luciano Coelho)
> seems to work for Intel now.
>
> Regards,
> Gary
>
> [1] https://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/p/350832/1236099#1236099
^ permalink raw reply
* Re: [PATCH v2 0/9] cfg80211/mac80211: Fast Initial Link Setup (IEEE 802.11ai)
From: Johannes Berg @ 2016-10-27 10:42 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <1477518126-823-1-git-send-email-jouni@qca.qualcomm.com>
On Thu, 2016-10-27 at 00:41 +0300, Jouni Malinen wrote:
> [...]
> This series covers only the FILS authentication/association
> functionality from IEEE 802.11ai, i.e., the other changes like
> scanning optimizations are not included.
>
Applied, thanks.
johannes
^ permalink raw reply
* [RFC] mac80211: set wifi_acked[_valid] bits for transmitted SKBs
From: Johannes Berg @ 2016-10-27 14:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There may be situations in which the in-kernel originator of an
SKB cares about its wifi transmission status. To have that, set
the wifi_acked[_valid] bits before freeing/orphaning the SKB if
the destructor is set. The originator can then use it in there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/status.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index ddf71c648cab..dc3132d0effe 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -541,6 +541,11 @@ static void ieee80211_report_used_skb(struct ieee80211_local *local,
} else if (info->ack_frame_id) {
ieee80211_report_ack_skb(local, info, acked, dropped);
}
+
+ if (!dropped && skb->destructor) {
+ skb->wifi_acked_valid = 1;
+ skb->wifi_acked = acked;
+ }
}
/*
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2] cfg80211: Add support to update connection parameters
From: Johannes Berg @ 2016-10-27 14:00 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1477576271-12696-1-git-send-email-jouni@qca.qualcomm.com>
On Thu, 2016-10-27 at 16:51 +0300, Jouni Malinen wrote:
> From: vamsi krishna <vamsin@qti.qualcomm.com>
>
> Add functionality to update the connection parameters when in
> connected
> state, so that driver/firmware uses the updated parameters for
> subsequent roaming. This is for drivers that support internal BSS
> selection and roaming. The new command does not change the current
> association state, i.e., it can be used to update IE contents for
> future
> (re)associations without causing an immediate disassociation or
> reassociation with the current BSS.
>
> [...]
applied.
johannes
^ permalink raw reply
* Re: [PATCH 5/5] mwifiex: wait for firmware dump completion in remove_card
From: Kalle Valo @ 2016-10-27 13:20 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Amitkumar Karwar, linux-wireless, Cathy Luo, Nishant Sarmukadam,
briannorris, Xinming Hu
In-Reply-To: <20161025001405.GE15034@dtor-ws>
Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
>> +/* reset_trigger variable is used to identify if mwifiex_sdio_remove()
>> + * is called by sdio_work during reset or the call is from sdio subsystem.
>> + * We will cancel sdio_work only if the call is from sdio subsystem.
>> + */
>> +static u8 reset_triggered;
>
> It would be really great if the driver supported multiple devices. IOW
> please avoid module-globals.
Good catch, it's a hard requirement to support multiple devices at the
same time.
--
Kalle Valo
^ permalink raw reply
* pull-request: mac80211 2016-10-27
From: Johannes Berg @ 2016-10-27 8:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Before I go off for LPC and the workshop and everything, I have
two fixes. Neither is very important, but I figured I'd get them
out since I won't have any others soon.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit b4f0fd4baa90ecce798e0d26d1cce8f4457f2028:
qed: Use list_move_tail instead of list_del/list_add_tail (2016-10-18 16:40:41 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-10-27
for you to fetch changes up to b4f7f4ad425a84fd5d40da21aff8681997b25ff9:
mac80211: fix some sphinx warnings (2016-10-26 08:01:07 +0200)
----------------------------------------------------------------
Just two fixes:
* a fix to process all events while suspending, so any
potential calls into the driver are done before it is
suspended
* small markup fixes for the sphinx documentation conversion
that's coming into the tree via the doc tree
----------------------------------------------------------------
Jani Nikula (1):
mac80211: fix some sphinx warnings
Johannes Berg (1):
cfg80211: process events caused by suspend before suspending
include/net/mac80211.h | 21 +++++++++++++--------
net/wireless/sysfs.c | 5 ++++-
2 files changed, 17 insertions(+), 9 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox