* [PATCH 1/2] wireless: set correct mandatory rate flags
From: Richard Schütz @ 2017-09-07 15:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Richard Schütz
According to IEEE Std 802.11-2016 (16.2.3.4 Long PHY SIGNAL field) all of
the following rates are mandatory for a HR/DSSS PHY: 1 Mb/s, 2 Mb/s,
5.5 Mb/s and 11 Mb/s. Set IEEE80211_RATE_MANDATORY_B flag for all of these
instead of just 1 Mb/s to correctly reflect this.
Signed-off-by: Richard Schütz <rschuetz@uni-koblenz.de>
---
net/wireless/util.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index bcb1284c3415..c69b5c31caf8 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -157,32 +157,28 @@ static void set_mandatory_flags_band(struct ieee80211_supported_band *sband)
case NL80211_BAND_2GHZ:
want = 7;
for (i = 0; i < sband->n_bitrates; i++) {
- if (sband->bitrates[i].bitrate == 10) {
+ if (sband->bitrates[i].bitrate == 10 ||
+ sband->bitrates[i].bitrate == 20 ||
+ sband->bitrates[i].bitrate == 55 ||
+ sband->bitrates[i].bitrate == 110) {
sband->bitrates[i].flags |=
IEEE80211_RATE_MANDATORY_B |
IEEE80211_RATE_MANDATORY_G;
want--;
+ } else {
+ sband->bitrates[i].flags |=
+ IEEE80211_RATE_ERP_G;
}
- if (sband->bitrates[i].bitrate == 20 ||
- sband->bitrates[i].bitrate == 55 ||
- sband->bitrates[i].bitrate == 110 ||
- sband->bitrates[i].bitrate == 60 ||
+ if (sband->bitrates[i].bitrate == 60 ||
sband->bitrates[i].bitrate == 120 ||
sband->bitrates[i].bitrate == 240) {
sband->bitrates[i].flags |=
IEEE80211_RATE_MANDATORY_G;
want--;
}
-
- if (sband->bitrates[i].bitrate != 10 &&
- sband->bitrates[i].bitrate != 20 &&
- sband->bitrates[i].bitrate != 55 &&
- sband->bitrates[i].bitrate != 110)
- sband->bitrates[i].flags |=
- IEEE80211_RATE_ERP_G;
}
- WARN_ON(want != 0 && want != 3 && want != 6);
+ WARN_ON(want != 0 && want != 3);
break;
case NL80211_BAND_60GHZ:
/* check for mandatory HT MCS 1..4 */
--
2.14.1
^ permalink raw reply related
* [PATCH 2/2] wireless: return correct mandatory rates
From: Richard Schütz @ 2017-09-07 15:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Richard Schütz
In-Reply-To: <20170907154744.28357-1-rschuetz@uni-koblenz.de>
Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B for
comparison to get all mandatory rates in 2.4 GHz band. It is safe to do so
because ERP mandatory rates are a superset of HR/DSSS mandatory rates. Also
force IEEE80211_RATE_MANDATORY_A for 10 MHz and 5 MHz channels as they use
"half-clocked" respectively "quarter-clocked" operation of the OFDM rates
(IEEE Std 802.11-2016, 17.1.1).
Signed-off-by: Richard Schütz <rschuetz@uni-koblenz.de>
---
net/wireless/util.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index c69b5c31caf8..8cac453302f7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -48,15 +48,12 @@ u32 ieee80211_mandatory_rates(struct ieee80211_supported_band *sband,
if (WARN_ON(!sband))
return 1;
- if (sband->band == NL80211_BAND_2GHZ) {
- if (scan_width == NL80211_BSS_CHAN_WIDTH_5 ||
- scan_width == NL80211_BSS_CHAN_WIDTH_10)
- mandatory_flag = IEEE80211_RATE_MANDATORY_G;
- else
- mandatory_flag = IEEE80211_RATE_MANDATORY_B;
- } else {
+ if (sband->band == NL80211_BAND_2GHZ &&
+ scan_width != NL80211_BSS_CHAN_WIDTH_5 &&
+ scan_width != NL80211_BSS_CHAN_WIDTH_10)
+ mandatory_flag = IEEE80211_RATE_MANDATORY_G;
+ else
mandatory_flag = IEEE80211_RATE_MANDATORY_A;
- }
bitrates = sband->bitrates;
for (i = 0; i < sband->n_bitrates; i++)
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] iwlwifi: mvm: only send LEDS_CMD when the FW supports it
From: Linus Torvalds @ 2017-09-07 16:13 UTC (permalink / raw)
To: Kalle Valo
Cc: Luca Coelho, Linux Wireless List, Johannes Berg,
Linux Kernel Mailing List, Andrew Morton, Network Development,
David Miller, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <877exan0nq.fsf@kamboji.qca.qualcomm.com>
On Thu, Sep 7, 2017 at 5:39 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Linus, do you want to apply this directly or should we take it via the
> normal route (wireless-drivers -> net)? If your prefer the latter when
> I'm planning to submit this to Dave in a day or two and expecting it to
> get to your tree in about a week, depending of course what is Dave's
> schedule.
Since we have a workaround for the problem, let's just go through the
regular channels. As long as I get the fix through David before the
merge window closes, I'm happy.
Linus
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: only send LEDS_CMD when the FW supports it
From: Kalle Valo @ 2017-09-07 16:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Luca Coelho, Linux Wireless List, Johannes Berg,
Linux Kernel Mailing List, Andrew Morton, Network Development,
David Miller, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <CA+55aFyeEwg7vd8FPHqG+4d7KbJ6ke4NDwhd+8y=_auRApyvmw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Sep 7, 2017 at 5:39 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Linus, do you want to apply this directly or should we take it via the
>> normal route (wireless-drivers -> net)? If your prefer the latter when
>> I'm planning to submit this to Dave in a day or two and expecting it to
>> get to your tree in about a week, depending of course what is Dave's
>> schedule.
>
> Since we have a workaround for the problem, let's just go through the
> regular channels. As long as I get the fix through David before the
> merge window closes, I'm happy.
Ok, I'll aim to send the pull request to Dave tomorrow.
--
Kalle Valo
^ permalink raw reply
* Re: iwlwifi: mvm: only send LEDS_CMD when the FW supports it
From: Kalle Valo @ 2017-09-07 16:40 UTC (permalink / raw)
To: Luciano Coelho
Cc: torvalds, linux-wireless, johannes, linux-kernel, akpm, netdev,
davem, emmanuel.grumbach, Luca Coelho
In-Reply-To: <20170907075152.4522-1-luca@coelho.fi>
Luciano Coelho <luca@coelho.fi> wrote:
> From: Luca Coelho <luciano.coelho@intel.com>
>
> The LEDS_CMD command is only supported in some newer FW versions
> (e.g. iwlwifi-8000C-31.ucode), so we can't send it to older versions
> (such as iwlwifi-8000C-27.ucode).
>
> To fix this, check for a new bit in the FW capabilities TLV that tells
> when the command is supported.
>
> Note that the current version of -31.ucode in linux-firmware.git
> (31.532993.0) does not have this capability bit set, so the LED won't
> work, even though this version should support it. But we will update
> this firmware soon, so it won't be a problem anymore.
>
> Fixes: 7089ae634c50 ("iwlwifi: mvm: use firmware LED command where applicable")
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Patch applied to wireless-drivers.git, thanks.
2eabc84d2f8e iwlwifi: mvm: only send LEDS_CMD when the FW supports it
--
https://patchwork.kernel.org/patch/9941719/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: pull-request: mac80211 2017-09-07
From: David Miller @ 2017-09-07 16:41 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170907070939.3658-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 7 Sep 2017 09:09:38 +0200
> During my long absence some things have accumulated, but there wasn't
> actually all that much that could've gone into the last cycle, and a
> fix or two was taken care of by others.
>
> The most important thing here is probably the deadlock fix that a few
> people have run into on 4.13, but that was only identified now, and
> perhaps the 40 MHz fix from Emmanuel that helps avoid iwlwifi firmware
> crashes.
>
> Please pull and let me know if there's any problem.
Pulled, thanks.
^ permalink raw reply
* Re: using vulnerability ids in patches
From: Arend van Spriel @ 2017-09-07 19:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87bmmmn0ur.fsf@kamboji.qca.qualcomm.com>
On 07-09-17 14:34, Kalle Valo wrote:
> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
>
>> Due to recent events we were asked about some vulnerability fixes for
>> brcmfmac. We already fixed a couple of things without referring to a
>> so-called CVE-ID, which is what people are asking for. Do we have a
>> upstream policy on that? I could not really find anything in the
>> Documentation folder (but I may have overlooked it). Might be worth
>> mentioning in the commit message like with the coverity ids.
>
> Johannes already answered, but I'll just add that this is all I know
> about security patches:
>
> If you have a patch that fixes an exploitable security bug, send that
> patch to security@kernel.org. For severe bugs, a short embargo may be
> considered to allow distributors to get the patch out to users; in
> such cases, obviously, the patch should not be sent to any public
> lists.
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>
> I don't know if you should follow that in this case or not, just wanted
> to point out this.
I see. I thought security@kernel.org was just to report exploitable
security bugs. Thanks for the pointer.
Regards,
Arend
^ permalink raw reply
* [PATCH] mwifiex: check for mfg_mode in add_virtual_intf
From: Ganapathi Bhat @ 2017-09-07 20:32 UTC (permalink / raw)
To: linux-wireless
Cc: Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare, Ganapathi Bhat
If driver is loaded with 'mfg_mode' enabled, then the sending
commands are not allowed. So, skip sending commands, to firmware
in mwifiex_add_virtual_intf if 'mfg_mode' is enabled.
Fixes: 7311ea850079 ("mwifiex: fix AP start problem for newly added interface")
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
v2: addressed Brian's comments.
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 32c5074..ad1ebd8 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2959,18 +2959,21 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
}
mwifiex_init_priv_params(priv, dev);
- mwifiex_set_mac_address(priv, dev);
priv->netdev = dev;
- ret = mwifiex_send_cmd(priv, HostCmd_CMD_SET_BSS_MODE,
- HostCmd_ACT_GEN_SET, 0, NULL, true);
- if (ret)
- goto err_set_bss_mode;
+ if (!adapter->mfg_mode) {
+ mwifiex_set_mac_address(priv, dev);
- ret = mwifiex_sta_init_cmd(priv, false, false);
- if (ret)
- goto err_sta_init;
+ ret = mwifiex_send_cmd(priv, HostCmd_CMD_SET_BSS_MODE,
+ HostCmd_ACT_GEN_SET, 0, NULL, true);
+ if (ret)
+ goto err_set_bss_mode;
+
+ ret = mwifiex_sta_init_cmd(priv, false, false);
+ if (ret)
+ goto err_sta_init;
+ }
mwifiex_setup_ht_caps(&wiphy->bands[NL80211_BAND_2GHZ]->ht_cap, priv);
if (adapter->is_hw_11ac_capable)
--
1.9.1
^ permalink raw reply related
* RE: [EXT] Re: [PATCH] mwifiex: check for mfg_mode in add_virtual_intf
From: Ganapathi Bhat @ 2017-09-07 20:41 UTC (permalink / raw)
To: Brian Norris
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Xinming Hu,
Zhiyuan Yang, James Cao, Mangesh Malusare
In-Reply-To: <20170831202146.GA27509@google.com>
Hi Brian,
>
> ----------------------------------------------------------------------
> On Thu, Aug 31, 2017 at 12:16:58AM +0530, Ganapathi Bhat wrote:
> > If driver is loaded with 'mfg_mode' enabled, then the sending
> commands
> > are not allowed. So, when mwifiex_send_cmd fails in
> > mwifiex_add_virtual_intf, driver must check for 'mfg_mode' before
> > returning error.
> >
> > Fixes: 7311ea850079 ("mwifiex: fix AP start problem for newly added
> > interface")
> > Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> > ---
> > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > index ffada17..1856205 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> > @@ -2967,11 +2967,11 @@ struct wireless_dev
> > *mwifiex_add_virtual_intf(struct wiphy *wiphy,
> >
> > ret = mwifiex_send_cmd(priv, HostCmd_CMD_SET_BSS_MODE,
> > HostCmd_ACT_GEN_SET, 0, NULL, true);
> > - if (ret)
> > + if (ret && !adapter->mfg_mode)
>
> It doesn't feel like ignoring errors is the best approach here,
> especially when it's only a single command that we could easily just
> skip.
Got it.
>
> So, why don't you just skip it, like this?
>
> if (!adapter->mfg_mode) {
Yes. This is better.
> ret = mwifiex_send_cmd(...);
> if (ret)
> goto err_set_bss_mode;
> }
>
> > goto err_set_bss_mode;
> >
> > ret = mwifiex_sta_init_cmd(priv, false, false);
> > - if (ret)
> > + if (ret && !adapter->mfg_mode)
> > goto err_sta_init;
>
> Same here; I think it's safe to just completely skip
> mwifiex_sta_init_cmd(), no?
Yes. I have sent v2 of these changes.
>
> Brian
>
> >
> > mwifiex_setup_ht_caps(&wiphy->bands[NL80211_BAND_2GHZ]->ht_cap,
> > priv);
> > --
> > 1.9.1
> >
Thanks,
Ganapathi
^ permalink raw reply
* [PATCH] rtl8xxxu: Don't printk raw binary if serial number is not burned in.
From: Adam Borowski @ 2017-09-07 23:51 UTC (permalink / raw)
To: Jes Sorensen, Kalle Valo, linux-wireless, netdev; +Cc: Adam Borowski
I assume that a blank efuse comes with all ones, thus I did not bother
recognizing other possible junk values. This matches 100% of dongles
I've seen (a single Gembird 8192eu).
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index 80fee699f58a..bdc37e7272ca 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -614,7 +614,11 @@ static int rtl8192eu_parse_efuse(struct rtl8xxxu_priv *priv)
dev_info(&priv->udev->dev, "Vendor: %.7s\n", efuse->vendor_name);
dev_info(&priv->udev->dev, "Product: %.11s\n", efuse->device_name);
- dev_info(&priv->udev->dev, "Serial: %.11s\n", efuse->serial);
+ if (strncmp(efuse->serial,
+ "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff", 11))
+ dev_info(&priv->udev->dev, "Serial: %.11s\n", efuse->serial);
+ else
+ dev_info(&priv->udev->dev, "Serial not available.\n");
if (rtl8xxxu_debug & RTL8XXXU_DEBUG_EFUSE) {
unsigned char *raw = priv->efuse_wifi.raw;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Don't printk raw binary if serial number is not burned in.
From: Stefano Brivio @ 2017-09-08 1:27 UTC (permalink / raw)
To: Adam Borowski; +Cc: Jes Sorensen, Kalle Valo, linux-wireless, netdev
In-Reply-To: <20170907235103.5359-1-kilobyte@angband.pl>
On Fri, 8 Sep 2017 01:51:03 +0200
Adam Borowski <kilobyte@angband.pl> wrote:
> I assume that a blank efuse comes with all ones, thus I did not bother
> recognizing other possible junk values. This matches 100% of dongles
> I've seen (a single Gembird 8192eu).
>
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
> index 80fee699f58a..bdc37e7272ca 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
> @@ -614,7 +614,11 @@ static int rtl8192eu_parse_efuse(struct rtl8xxxu_priv *priv)
>
> dev_info(&priv->udev->dev, "Vendor: %.7s\n", efuse->vendor_name);
> dev_info(&priv->udev->dev, "Product: %.11s\n", efuse->device_name);
> - dev_info(&priv->udev->dev, "Serial: %.11s\n", efuse->serial);
> + if (strncmp(efuse->serial,
> + "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff", 11))
You might want to use memchr_inv():
if (memchr_inv(efuse->serial, 0xff, 11))
dev_info(&priv->udev->dev, "Serial: %.11s\n", efuse->serial);
...
Mostly cosmetic though.
--
Stefano
^ permalink raw reply
* Re: [PATCH 1/2] wireless: set correct mandatory rate flags
From: Johannes Berg @ 2017-09-08 6:54 UTC (permalink / raw)
To: Richard Schütz, linux-wireless
In-Reply-To: <20170907154744.28357-1-rschuetz@uni-koblenz.de>
On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
> According to IEEE Std 802.11-2016 (16.2.3.4 Long PHY SIGNAL field)
> all of
> the following rates are mandatory for a HR/DSSS PHY: 1 Mb/s, 2 Mb/s,
> 5.5 Mb/s and 11 Mb/s. Set IEEE80211_RATE_MANDATORY_B flag for all of
> these instead of just 1 Mb/s to correctly reflect this.
Hmm, I guess technically you're correct, since 11b added what's now
Clause 16 (was Clause 18 at the time), and that has all of them
mandatory? But perhaps this was actually intended for Clause 15
compatibility?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] wireless: return correct mandatory rates
From: Johannes Berg @ 2017-09-08 6:55 UTC (permalink / raw)
To: Richard Schütz, linux-wireless
In-Reply-To: <20170907154744.28357-2-rschuetz@uni-koblenz.de>
On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
> Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B
> for comparison to get all mandatory rates in 2.4 GHz band. It is safe
> to do so because ERP mandatory rates are a superset of HR/DSSS
> mandatory rates.
This I don't understand - what "comparison" are you talking about?
> Also force IEEE80211_RATE_MANDATORY_A for 10 MHz and 5 MHz channels
> as they use "half-clocked" respectively "quarter-clocked" operation
> of the OFDM rates (IEEE Std 802.11-2016, 17.1.1).
I don't think this is correct - the way the flags are used, anything on
2.4 GHz would never bother to check the MANDATORY_A flag.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] wireless: set correct mandatory rate flags
From: Richard Schütz @ 2017-09-08 8:43 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1504853647.6177.8.camel@sipsolutions.net>
Am 08.09.2017 um 08:54 schrieb Johannes Berg:
> On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
>> According to IEEE Std 802.11-2016 (16.2.3.4 Long PHY SIGNAL field)
>> all of
>> the following rates are mandatory for a HR/DSSS PHY: 1 Mb/s, 2 Mb/s,
>> 5.5 Mb/s and 11 Mb/s. Set IEEE80211_RATE_MANDATORY_B flag for all of
>> these instead of just 1 Mb/s to correctly reflect this.
>
> Hmm, I guess technically you're correct, since 11b added what's now
> Clause 16 (was Clause 18 at the time), and that has all of them
> mandatory? But perhaps this was actually intended for Clause 15
> compatibility?
Compatibility in what way?
--
Richard
^ permalink raw reply
* Re: [PATCH 2/2] wireless: return correct mandatory rates
From: Richard Schütz @ 2017-09-08 8:43 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Simon Wunderlich
In-Reply-To: <1504853740.6177.10.camel@sipsolutions.net>
Am 08.09.2017 um 08:55 schrieb Johannes Berg:
> On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
>> Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B
>> for comparison to get all mandatory rates in 2.4 GHz band. It is safe
>> to do so because ERP mandatory rates are a superset of HR/DSSS
>> mandatory rates.
> This I don't understand - what "comparison" are you talking about?
Sorry, I meant the condition that checks for the presence of
mandatory_flag at the bottom of the function.
>> Also force IEEE80211_RATE_MANDATORY_A for 10 MHz and 5 MHz channels
>> as they use "half-clocked" respectively "quarter-clocked" operation
>> of the OFDM rates (IEEE Std 802.11-2016, 17.1.1).
> I don't think this is correct - the way the flags are used, anything on
> 2.4 GHz would never bother to check the MANDATORY_A flag.
Do we actually allow 10 MHz and 5 MHz operation in the 2.4 GHz band? As
far as I can tell that has only been specified for OFDM PHYs, which use
the 5 GHz band and are covered by IEEE80211_RATE_MANDATORY_A, but I am
not a hundred per cent sure about that. Cc'ing Simon Wunderlich who
originally implemented checking of scan_width here.
The main intention of this patch series is to fix mandatory rates
returned for normal operation in 2.4 GHz band. Currently only 1 Mb/s is
returned here, which is wrong for both HR/DSSS and ERP PHYs.
--
Richard
^ permalink raw reply
* Re: [PATCH 2/2] wireless: return correct mandatory rates
From: Richard Schütz @ 2017-09-08 8:53 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Simon Wunderlich
In-Reply-To: <5aed0ea0-f127-bd1e-ca06-db7edbf56680@uni-koblenz.de>
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]
Am 08.09.2017 um 10:43 schrieb Richard Schütz:
> Am 08.09.2017 um 08:55 schrieb Johannes Berg:
>> On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
>>> Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B
>>> for comparison to get all mandatory rates in 2.4 GHz band. It is safe
>>> to do so because ERP mandatory rates are a superset of HR/DSSS
>>> mandatory rates.
>> This I don't understand - what "comparison" are you talking about?
>
> Sorry, I meant the condition that checks for the presence of
> mandatory_flag at the bottom of the function.
>
>>> Also force IEEE80211_RATE_MANDATORY_A for 10 MHz and 5 MHz channels
>>> as they use "half-clocked" respectively "quarter-clocked" operation
>>> of the OFDM rates (IEEE Std 802.11-2016, 17.1.1).
>> I don't think this is correct - the way the flags are used, anything on
>> 2.4 GHz would never bother to check the MANDATORY_A flag.
>
> Do we actually allow 10 MHz and 5 MHz operation in the 2.4 GHz band? As
> far as I can tell that has only been specified for OFDM PHYs, which use
> the 5 GHz band and are covered by IEEE80211_RATE_MANDATORY_A, but I am
> not a hundred per cent sure about that. Cc'ing Simon Wunderlich who
> originally implemented checking of scan_width here.
Looks like the old address is invalid now. New try.
> The main intention of this patch series is to fix mandatory rates
> returned for normal operation in 2.4 GHz band. Currently only 1 Mb/s is
> returned here, which is wrong for both HR/DSSS and ERP PHYs.
--
Richard
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5087 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] wireless: set correct mandatory rate flags
From: Johannes Berg @ 2017-09-08 8:57 UTC (permalink / raw)
To: Richard Schütz, linux-wireless
In-Reply-To: <85930e91-2c1e-53a6-5b65-d796116295fa@uni-koblenz.de>
On Fri, 2017-09-08 at 10:43 +0200, Richard Schütz wrote:
> > Hmm, I guess technically you're correct, since 11b added what's now
> > Clause 16 (was Clause 18 at the time), and that has all of them
> > mandatory? But perhaps this was actually intended for Clause 15
> > compatibility?
>
> Compatibility in what way?
Well, realistically there are only three users of this information:
* ieee80211_mandatory_rates(), used for supported station rates if we
don't know anything better in IBSS (and OCB) and for basic rates in
mesh;
* basic rates in IBSS (__cfg80211_join_ibss);
* duration calculation in ieee80211_duration, but that's just a
fallback
So I guess it's now pretty unlikely that anyone would have a pre-11b
device, so it would make sense to actually make this change.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] wireless: return correct mandatory rates
From: Johannes Berg @ 2017-09-08 9:03 UTC (permalink / raw)
To: Richard Schütz, linux-wireless; +Cc: Simon Wunderlich
In-Reply-To: <5aed0ea0-f127-bd1e-ca06-db7edbf56680@uni-koblenz.de>
On Fri, 2017-09-08 at 10:43 +0200, Richard Schütz wrote:
> Am 08.09.2017 um 08:55 schrieb Johannes Berg:
> > On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
> > > Use IEEE80211_RATE_MANDATORY_G instead of
> > > IEEE80211_RATE_MANDATORY_B
> > > for comparison to get all mandatory rates in 2.4 GHz band. It is
> > > safe
> > > to do so because ERP mandatory rates are a superset of HR/DSSS
> > > mandatory rates.
> >
> > This I don't understand - what "comparison" are you talking about?
>
> Sorry, I meant the condition that checks for the presence of
> mandatory_flag at the bottom of the function.
Ah, sorry, I got confused with the other patch.
> Do we actually allow 10 MHz and 5 MHz operation in the 2.4 GHz band?
> As far as I can tell that has only been specified for OFDM PHYs,
> which use the 5 GHz band and are covered by
> IEEE80211_RATE_MANDATORY_A, but I am not a hundred per cent sure
> about that. Cc'ing Simon Wunderlich who originally implemented
> checking of scan_width here.
Clearly we do allow that, since the existing check is:
if (sband->band == NL80211_BAND_2GHZ) {
if (scan_width == NL80211_BSS_CHAN_WIDTH_5 ||
scan_width == NL80211_BSS_CHAN_WIDTH_10)
mandatory_flag = IEEE80211_RATE_MANDATORY_G;
That wouldn't make any sense if we didn't have 5/10 MHz on 2.4 GHz.
> The main intention of this patch series is to fix mandatory rates
> returned for normal operation in 2.4 GHz band. Currently only 1 Mb/s
> is returned here, which is wrong for both HR/DSSS and ERP PHYs.
The patch is still wrong wrt. 5/10 MHz though.
I think what you really wanted to do is the following:
* rename RATE_MANDATORY_B to RATE_MANDATORY_HR_DSSS
* combine RATE_MANDATORY_G/_A to RATE_MANDATORY_OFDM
Then, what you need to do, is change the checks in
ieee80211_mandatory_rates() to be
if (sband->band == NL80211_BAND_2GHZ) {
if (scan_width == NL80211_BSS_CHAN_WIDTH_5 ||
scan_width == NL80211_BSS_CHAN_WIDTH_10)
mandatory_flag = IEEE80211_RATE_MANDATORY_OFDM;
else
mandatory_flag = IEEE80211_RATE_MANDATORY_HR_DSSS;
} else {
mandatory_flag = IEEE80211_RATE_MANDATORY_OFDM;
}
That would actually fix a bug in a way because right now the code
treats HR/DSSS rates (1, 2, 5.5, 11) for 2.4 GHz narrow-band operation
as mandatory, which seems wrong.
johannes
^ permalink raw reply
* [PATCH 00/10] iwlwifi: fixes intended for 4.14 2017-09-08
From: Luca Coelho @ 2017-09-08 9:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Luca Coelho
From: Luca Coelho <luciano.coelho@intel.com>
Hi,
Here is my first batch of fixes intended for 4.14. Since it is very
early in the release process, I was a bit liberal with the fixes I'm
sending, but they all fix real issues.
These are the fixes:
* A couple of bugzilla bugs related to multicast handling;
* Two fixes for WoWLAN bugs that were causing queue hangs and
re-initialization problems;
* Two fixes for potential uninitialized variable use reported by Dan
Carpenter in relation to a recently introduced patch;
* A fix for buffer reordering in the newly supported 9000 device
family;
* Fix a race when starting aggregation;
* Small fix for a recent patch to wake mac80211 queues;
* Send non-bufferable management frames in the generic queue so they
are not sent on queues that are under power-save;
As usual, I'm pushing this to a pending branch, for kbuild bot, and
will send a pull-request later.
Please review.
Cheers,
Luca.
Avraham Stern (2):
iwlwifi: mvm: send all non-bufferable frames on the probe queue
iwlwifi: mvm: wake the correct mac80211 queue
David Spinadel (1):
iwlwifi: mvm: Flush non STA TX queues
Luca Coelho (4):
iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD
iwlwifi: mvm: handle FIF_ALLMULTI when setting multicast addresses
iwlwifi: mvm: initialize status in iwl_mvm_add_int_sta_common()
iwlwifi: mvm: set status before calling iwl_mvm_send_cmd_status()
Matt Chen (1):
iwlwifi: mvm: fix wowlan resume failed to load INIT ucode
Naftali Goldstein (1):
iwlwifi: mvm: change state when queueing agg start work
Sara Sharon (1):
iwlwifi: mvm: fix reorder buffer for 9000 devices
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 62 +++++++++++++++++++++--
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 7 +--
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 8 +--
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 2 +
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 ++--
9 files changed, 80 insertions(+), 17 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH 01/10] iwlwifi: mvm: fix wowlan resume failed to load INIT ucode
From: Luca Coelho @ 2017-09-08 9:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Matt Chen, Luca Coelho
In-Reply-To: <20170908091256.25279-1-luca@coelho.fi>
From: Matt Chen <matt.chen@intel.com>
If we set disconnect on wowlan and run suspend/resume, will run
into:
...snipped
iwlwifi 0000:01:00.0: Failed to load firmware chunk!
iwlwifi 0000:01:00.0: Could not load the [0] uCode section
iwlwifi 0000:01:00.0: Failed to start INIT ucode: -110
iwlwifi 0000:01:00.0: Failed to run INIT ucode: -110
iwlwifi 0000:01:00.0: Failed to start RT ucode: -110
It is because we still keep IWL_MVM_STATUS_IN_HW_RESTART in
__iwl_mvm_resume. When mac80211 starts the device as
__iwl_mvm_mac_start(), we will miss iwl_mvm_restart_cleanup(mvm).
Signed-off-by: Matt Chen <matt.chen@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 5de19ea10575..b205a7bfb828 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -2167,7 +2167,7 @@ static int __iwl_mvm_resume(struct iwl_mvm *mvm, bool test)
* 1. We are not using a unified image
* 2. We are using a unified image but had an error while exiting D3
*/
- set_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status);
+ set_bit(IWL_MVM_STATUS_HW_RESTART_REQUESTED, &mvm->status);
set_bit(IWL_MVM_STATUS_D3_RECONFIG, &mvm->status);
/*
* When switching images we return 1, which causes mac80211
--
2.14.1
^ permalink raw reply related
* [PATCH 02/10] iwlwifi: mvm: Flush non STA TX queues
From: Luca Coelho @ 2017-09-08 9:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, David Spinadel, Luca Coelho
In-Reply-To: <20170908091256.25279-1-luca@coelho.fi>
From: David Spinadel <david.spinadel@intel.com>
When starting wowlan mac80211 requests flush w/o vif
and we ignore this request. As a result some packets
stay stuck in the queue and it may end up with a queue
hang.
Allow the driver to flush queues even if station isn't
specified.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 44 ++++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 15f2d826bb4b..64b0be73ea72 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -3975,6 +3975,43 @@ static int iwl_mvm_post_channel_switch(struct ieee80211_hw *hw,
return ret;
}
+static void iwl_mvm_flush_no_vif(struct iwl_mvm *mvm, u32 queues, bool drop)
+{
+ if (drop) {
+ if (iwl_mvm_has_new_tx_api(mvm))
+ /* TODO new tx api */
+ WARN_ONCE(1,
+ "Need to implement flush TX queue\n");
+ else
+ iwl_mvm_flush_tx_path(mvm,
+ iwl_mvm_flushable_queues(mvm) & queues,
+ 0);
+ } else {
+ if (iwl_mvm_has_new_tx_api(mvm)) {
+ struct ieee80211_sta *sta;
+ int i;
+
+ mutex_lock(&mvm->mutex);
+
+ for (i = 0; i < ARRAY_SIZE(mvm->fw_id_to_mac_id); i++) {
+ sta = rcu_dereference_protected(
+ mvm->fw_id_to_mac_id[i],
+ lockdep_is_held(&mvm->mutex));
+ if (IS_ERR_OR_NULL(sta))
+ continue;
+
+ iwl_mvm_wait_sta_queues_empty(mvm,
+ iwl_mvm_sta_from_mac80211(sta));
+ }
+
+ mutex_unlock(&mvm->mutex);
+ } else {
+ iwl_trans_wait_tx_queues_empty(mvm->trans,
+ queues);
+ }
+ }
+}
+
static void iwl_mvm_mac_flush(struct ieee80211_hw *hw,
struct ieee80211_vif *vif, u32 queues, bool drop)
{
@@ -3985,7 +4022,12 @@ static void iwl_mvm_mac_flush(struct ieee80211_hw *hw,
int i;
u32 msk = 0;
- if (!vif || vif->type != NL80211_IFTYPE_STATION)
+ if (!vif) {
+ iwl_mvm_flush_no_vif(mvm, queues, drop);
+ return;
+ }
+
+ if (vif->type != NL80211_IFTYPE_STATION)
return;
/* Make sure we're done with the deferred traffic before flushing */
--
2.14.1
^ permalink raw reply related
* [PATCH 03/10] iwlwifi: mvm: send all non-bufferable frames on the probe queue
From: Luca Coelho @ 2017-09-08 9:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Avraham Stern, Luca Coelho
In-Reply-To: <20170908091256.25279-1-luca@coelho.fi>
From: Avraham Stern <avraham.stern@intel.com>
AP interfaces now send all non-bufferable frames using the broadcast
station. Thus allow them to use the probe queue and don't warn about
it.
Fixes: eb045e6e0389 ("iwlwifi: mvm: Avoid deferring non bufferable frames")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 172b5e63d3fb..6f2e2af23219 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -564,8 +564,8 @@ static int iwl_mvm_get_ctrl_vif_queue(struct iwl_mvm *mvm,
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_ADHOC:
/*
- * Handle legacy hostapd as well, where station will be added
- * only just before sending the association response.
+ * Non-bufferable frames use the broadcast station, thus they
+ * use the probe queue.
* Also take care of the case where we send a deauth to a
* station that we don't have, or similarly an association
* response (with non-success status) for a station we can't
@@ -573,9 +573,9 @@ static int iwl_mvm_get_ctrl_vif_queue(struct iwl_mvm *mvm,
* Also, disassociate frames might happen, particular with
* reason 7 ("Class 3 frame received from nonassociated STA").
*/
- if (ieee80211_is_probe_resp(fc) || ieee80211_is_auth(fc) ||
- ieee80211_is_deauth(fc) || ieee80211_is_assoc_resp(fc) ||
- ieee80211_is_disassoc(fc))
+ if (ieee80211_is_mgmt(fc) &&
+ (!ieee80211_is_bufferable_mmpdu(fc) ||
+ ieee80211_is_deauth(fc) || ieee80211_is_disassoc(fc)))
return mvm->probe_queue;
if (info->hw_queue == info->control.vif->cab_queue)
return mvmvif->cab_queue;
--
2.14.1
^ permalink raw reply related
* [PATCH 04/10] iwlwifi: mvm: change state when queueing agg start work
From: Luca Coelho @ 2017-09-08 9:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Naftali Goldstein, Luca Coelho
In-Reply-To: <20170908091256.25279-1-luca@coelho.fi>
From: Naftali Goldstein <naftali.goldstein@intel.com>
Add a new state to enum iwl_mvm_agg_state, which is used between
queueing the work that starts tx aggregations and actually starting that
work (changing to state IWL_AGG_STARTING).
This solves a race where ieee80211_start_tx_ba_session is called a
second time, before the work queued by the first run has a chance to
change the agg_state. In this case the second call to
ieee80211_start_tx_ba_session returns an error, and the fallback is to
abort the ba session start.
Fixes: 482e48440a0e ("iwlwifi: mvm: change open and close criteria of a BA session")
Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 3 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 6 ++++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 2 ++
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index ba7bd049d3d4..0fe723ca844e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -661,7 +661,8 @@ static void rs_tl_turn_on_agg(struct iwl_mvm *mvm, struct iwl_mvm_sta *mvmsta,
(lq_sta->tx_agg_tid_en & BIT(tid)) &&
(tid_data->tx_count_last >= IWL_MVM_RS_AGG_START_THRESHOLD)) {
IWL_DEBUG_RATE(mvm, "try to aggregate tid %d\n", tid);
- rs_tl_turn_on_agg_for_tid(mvm, lq_sta, tid, sta);
+ if (rs_tl_turn_on_agg_for_tid(mvm, lq_sta, tid, sta) == 0)
+ tid_data->state = IWL_AGG_QUEUED;
}
}
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 411a2055dc45..2dafe9bb4d8b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -2385,8 +2385,10 @@ int iwl_mvm_sta_tx_agg_start(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
if (WARN_ON_ONCE(tid >= IWL_MAX_TID_COUNT))
return -EINVAL;
- if (mvmsta->tid_data[tid].state != IWL_AGG_OFF) {
- IWL_ERR(mvm, "Start AGG when state is not IWL_AGG_OFF %d!\n",
+ if (mvmsta->tid_data[tid].state != IWL_AGG_QUEUED &&
+ mvmsta->tid_data[tid].state != IWL_AGG_OFF) {
+ IWL_ERR(mvm,
+ "Start AGG when state is not IWL_AGG_QUEUED or IWL_AGG_OFF %d!\n",
mvmsta->tid_data[tid].state);
return -ENXIO;
}
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.h b/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
index d13893806513..aedabe101cf0 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.h
@@ -281,6 +281,7 @@ struct iwl_mvm_vif;
* These states relate to a specific RA / TID.
*
* @IWL_AGG_OFF: aggregation is not used
+ * @IWL_AGG_QUEUED: aggregation start work has been queued
* @IWL_AGG_STARTING: aggregation are starting (between start and oper)
* @IWL_AGG_ON: aggregation session is up
* @IWL_EMPTYING_HW_QUEUE_ADDBA: establishing a BA session - waiting for the
@@ -290,6 +291,7 @@ struct iwl_mvm_vif;
*/
enum iwl_mvm_agg_state {
IWL_AGG_OFF = 0,
+ IWL_AGG_QUEUED,
IWL_AGG_STARTING,
IWL_AGG_ON,
IWL_EMPTYING_HW_QUEUE_ADDBA,
--
2.14.1
^ permalink raw reply related
* [PATCH 05/10] iwlwifi: mvm: wake the correct mac80211 queue
From: Luca Coelho @ 2017-09-08 9:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Avraham Stern, Luca Coelho
In-Reply-To: <20170908091256.25279-1-luca@coelho.fi>
From: Avraham Stern <avraham.stern@intel.com>
iwl_mvm_start_mac_queues() takes a bitmap of the queues to wake.
When deferred tx is purged, set the bit of the hw_queue so
the correct queue will be waken up.
Fixes: 7e39a00d5931 ("iwlwifi: mvm: start mac queues when deferred tx frames are purged")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 64b0be73ea72..3a6ce4222ff5 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2563,7 +2563,7 @@ static void iwl_mvm_purge_deferred_tx_frames(struct iwl_mvm *mvm,
* queues, so we should never get a second deferred
* frame for the RA/TID.
*/
- iwl_mvm_start_mac_queues(mvm, info->hw_queue);
+ iwl_mvm_start_mac_queues(mvm, BIT(info->hw_queue));
ieee80211_free_txskb(mvm->hw, skb);
}
}
--
2.14.1
^ permalink raw reply related
* [PATCH 07/10] iwlwifi: mvm: handle FIF_ALLMULTI when setting multicast addresses
From: Luca Coelho @ 2017-09-08 9:12 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <20170908091256.25279-1-luca@coelho.fi>
From: Luca Coelho <luciano.coelho@intel.com>
We were ignoring the FIF_ALLMULTI flag when setting the multicast
addresses with MCAST_FILTER_CMD. Check if this flag is set and enable
pass_all accordingly. We also need to set the count to 0 if pass_all
is enable so we don't pass addresses to the firmware when not needed
(as doing so causes an assert).
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=196741
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 635db63f972e..3bcaa82f59b2 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -1643,6 +1643,12 @@ static void iwl_mvm_configure_filter(struct ieee80211_hw *hw,
if (!cmd)
goto out;
+ if (changed_flags & FIF_ALLMULTI)
+ cmd->pass_all = !!(*total_flags & FIF_ALLMULTI);
+
+ if (cmd->pass_all)
+ cmd->count = 0;
+
iwl_mvm_recalc_multicast(mvm);
out:
mutex_unlock(&mvm->mutex);
--
2.14.1
^ permalink raw reply related
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