* [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
* [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
* Re: [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches
From: Gustavo A. R. Silva @ 2017-09-07 14:35 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <ae09e952-112e-9616-735a-b86ba01ad398@lwfinger.net>
Hi Larry,
On 08/30/2017 11:48 PM, Larry Finger wrote:
> On 08/30/2017 08:42 AM, Gustavo A. R. Silva wrote:
>> Refactor code in order to avoid identical code for different branches.
>>
>> This issue was detected with the help of Coccinelle.
>>
>> Addresses-Coverity-ID: 1226788
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> This issue was reported by Coverity and it was tested by compilation
>> only.
>> I'm suspicious this may be a copy/paste error. Please, verify.
>>
>> .../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 10
>> ++--------
>> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> This change is not correct. When bt_link_info->sco_exist is true, the
> call should be
>
> halbtc8723b1ant_limited_rx(btcoexist,
> NORMAL_EXEC, true,
> false, 0x5);
>
> NACK
>
> I will push the correct patch.
>
Great. Good to know.
Thanks
--
Gustavo A. R. Silva
^ permalink raw reply
* Re: [1/2] rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be
From: Kalle Valo @ 2017-09-07 12:56 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless, Larry Finger, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting, Stable
In-Reply-To: <20170904175134.8331-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when
> hw initialisation done"), there is an additional error when the module
> parameter ant_sel is used to select the auxilary antenna. The error is
> that the antenna selection is not checked when writing the antenna
> selection register.
>
> Fixes: bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when hw initialisation done")
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Cc: Birming Chiu <birming@realtek.com>
> Cc: Shaofu <shaofu@realtek.com>
> Cc: Steven Ting <steventing@realtek.com>
> Cc: Stable <stable@vger.kernel.org> # 4.12+
2 patches applied to wireless-drivers.git, thanks.
a33fcba6ec01 rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be
6d6226928369 rtlwifi: btcoexist: Fix antenna selection code
--
https://patchwork.kernel.org/patch/9937493/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] brcmfmac: Correctly fail to suspend when SDIO does not support power on suspend
From: Kalle Valo @ 2017-09-07 12:54 UTC (permalink / raw)
To: Eric Bentley
Cc: Steve deRosier, linux-wireless@vger.kernel.org,
arend.vanspriel@broadcom.com
In-Reply-To: <AC37C967-209B-4BC3-9AF2-9CC4C27391C0@lairdtech.com>
Eric Bentley <eric.bentley@lairdtech.com> wrote:
> Return error when failing to set power management capabilities flag. This will
> cause the suspend to fail but the radio will continue to operate. Allowing this
> to fail without reporting error will cause the radio to be non-functional on
> resume as it will have lost power.
>
> Signed-off-by: Eric Bentley eric.bentley@lairdtech.com
The patch is corrupted. It seems you used outlook to submit it which is
a recipe for a disaster:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#format_issues
Also please improve the commit log like Arend mentioned.
fatal: corrupt patch at line 23
error: could not build fake ancestor
Applying: brcmfmac: Correctly fail to suspend when SDIO does not support power on suspend
Patch failed at 0001 brcmfmac: Correctly fail to suspend when SDIO does not support power on suspend
The copy of the patch that failed is found in: .git/rebase-apply/patch
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9934065/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: only send LEDS_CMD when the FW supports it
From: Kalle Valo @ 2017-09-07 12:39 UTC (permalink / raw)
To: torvalds, Luca Coelho
Cc: linux-wireless, johannes, linux-kernel, akpm, netdev, davem,
emmanuel.grumbach, Luca Coelho
In-Reply-To: <20170907075152.4522-1-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> 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>
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.
--
Kalle Valo
^ permalink raw reply
* Re: using vulnerability ids in patches
From: Kalle Valo @ 2017-09-07 12:34 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <7415a11b-398c-69df-b39f-7b985f07112b@broadcom.com>
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.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10: mark PM functions as __maybe_unused
From: Kalle Valo @ 2017-09-07 11:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Colin Ian King, bartosz.markowski@tieto.com, Govind Singh,
Ryan Hsu, Srinivas Kandagatla, Rajkumar Manoharan,
Ashok Raj Nagarajan, Ben Greear, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170906125904.2588620-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> When CONFIG_PM_SLEEP is disabled, we get a compile-time
> warning:
>
> drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resu=
me' defined but not used [-Werror=3Dunused-function]
> static int ath10k_pci_pm_resume(struct device *dev)
> ^~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath10k/pci.c:3401:12: error: 'ath10k_pci_pm_susp=
end' defined but not used [-Werror=3Dunused-function]
> static int ath10k_pci_pm_suspend(struct device *dev)
>
> Rather than fixing the #ifdef, this just marks both functions
> as __maybe_unused, which is a more robust way to do this.
>
> Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks. But the title should have "ath10k:", I'll fix that.
--=20
Kalle Valo=
^ permalink raw reply
* Re: using vulnerability ids in patches
From: Arend van Spriel @ 2017-09-07 9:59 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1504777242.6177.2.camel@sipsolutions.net>
On 07-09-17 11:40, Johannes Berg wrote:
> On Thu, 2017-09-07 at 11:38 +0200, Arend van Spriel wrote:
>>
>> Ok. So doing this I see a number of instances where the CVE-ID is
>> mentioned in the commit message, but there are also instances that
>> use the 'Fixes:' tag. Does it make sense to use that or does it
>> serve another purpose?
>
> Huh, I don't think that makes sense - the Fixes: tag should be for the
> commit that introduced the bug. I guess parsers will have to ignore
> garbage so it's probably safe, but I don't think you could mine for CVE
> fixes that way anyway ...
Indeed. I see a lot of different ways in which the CVE-IDs are
referenced, which makes mining for a list of CVE-IDs between releases
hard. Seems like a useful thing to have though, but people may grow
tired of all the different tags :-p
Regards,
Arend
^ permalink raw reply
* Re: using vulnerability ids in patches
From: Johannes Berg @ 2017-09-07 9:40 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <7b09c3d4-a18a-6bc3-6445-8911c088258f@broadcom.com>
On Thu, 2017-09-07 at 11:38 +0200, Arend van Spriel wrote:
>
> Ok. So doing this I see a number of instances where the CVE-ID is
> mentioned in the commit message, but there are also instances that
> use the 'Fixes:' tag. Does it make sense to use that or does it
> serve another purpose?
Huh, I don't think that makes sense - the Fixes: tag should be for the
commit that introduced the bug. I guess parsers will have to ignore
garbage so it's probably safe, but I don't think you could mine for CVE
fixes that way anyway ...
johannes
^ permalink raw reply
* Re: using vulnerability ids in patches
From: Arend van Spriel @ 2017-09-07 9:38 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1504774743.6177.0.camel@sipsolutions.net>
On 07-09-17 10:59, Johannes Berg wrote:
> On Thu, 2017-09-07 at 10:40 +0200, Arend van Spriel wrote:
>> Hi Kalle,
>>
>> 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.
>
> Sure.
>
> git log --grep "CVE-"
>
> shows it being done frequently.
Ok. So doing this I see a number of instances where the CVE-ID is
mentioned in the commit message, but there are also instances that use
the 'Fixes:' tag. Does it make sense to use that or does it serve
another purpose?
Regards,
Arend
^ permalink raw reply
* Re: using vulnerability ids in patches
From: Arend van Spriel @ 2017-09-07 9:28 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1504774743.6177.0.camel@sipsolutions.net>
On 07-09-17 10:59, Johannes Berg wrote:
> On Thu, 2017-09-07 at 10:40 +0200, Arend van Spriel wrote:
>> Hi Kalle,
>>
>> 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.
>
> Sure.
>
> git log --grep "CVE-"
>
> shows it being done frequently.
Right. Failed to do the obvious ;-)
Thanks,
Arend
^ permalink raw reply
* Re: using vulnerability ids in patches
From: Johannes Berg @ 2017-09-07 8:59 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <7415a11b-398c-69df-b39f-7b985f07112b@broadcom.com>
On Thu, 2017-09-07 at 10:40 +0200, Arend van Spriel wrote:
> Hi Kalle,
>
> 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.
Sure.
git log --grep "CVE-"
shows it being done frequently.
johannes
^ permalink raw reply
* using vulnerability ids in patches
From: Arend van Spriel @ 2017-09-07 8:40 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
Hi Kalle,
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.
Regards,
Arend
^ permalink raw reply
* [PATCH] iwlwifi: mvm: only send LEDS_CMD when the FW supports it
From: Luca Coelho @ 2017-09-07 7:51 UTC (permalink / raw)
To: torvalds
Cc: linux-wireless, johannes, linux-kernel, akpm, kvalo, netdev,
davem, emmanuel.grumbach, Luca Coelho
In-Reply-To: <CA+55aFxjHSW7v4Ttu7mGPkxdGpR-WtVoxDT5qtwxUC-Dge5a5A@mail.gmail.com>
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>
---
drivers/net/wireless/intel/iwlwifi/fw/file.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/led.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h b/drivers/net/wireless/intel/iwlwifi/fw/file.h
index 887f6d8fc8a7..279248cd9cfb 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
@@ -378,6 +378,7 @@ enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_EXTEND_SHARED_MEM_CFG = (__force iwl_ucode_tlv_capa_t)80,
IWL_UCODE_TLV_CAPA_LQM_SUPPORT = (__force iwl_ucode_tlv_capa_t)81,
IWL_UCODE_TLV_CAPA_TX_POWER_ACK = (__force iwl_ucode_tlv_capa_t)84,
+ IWL_UCODE_TLV_CAPA_LED_CMD_SUPPORT = (__force iwl_ucode_tlv_capa_t)86,
IWL_UCODE_TLV_CAPA_MLME_OFFLOAD = (__force iwl_ucode_tlv_capa_t)96,
NUM_IWL_UCODE_TLV_CAPA
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/led.c b/drivers/net/wireless/intel/iwlwifi/mvm/led.c
index 005e2e7278a5..b27269504a62 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/led.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/led.c
@@ -92,7 +92,8 @@ static void iwl_mvm_send_led_fw_cmd(struct iwl_mvm *mvm, bool on)
static void iwl_mvm_led_set(struct iwl_mvm *mvm, bool on)
{
- if (mvm->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
+ if (fw_has_capa(&mvm->fw->ucode_capa,
+ IWL_UCODE_TLV_CAPA_LED_CMD_SUPPORT)) {
iwl_mvm_send_led_fw_cmd(mvm, on);
return;
}
--
2.14.1
^ permalink raw reply related
* pull-request: mac80211 2017-09-07
From: Johannes Berg @ 2017-09-07 7:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
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.
Thanks,
johannes
The following changes since commit 6d9c153a0b84392406bc77600aa7d3ea365de041:
net: dsa: loop: Do not unregister invalid fixed PHY (2017-09-03 20:18:25 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-09-07
for you to fetch changes up to bde59c475e0883e4c4294bcd9b9c7e08ae18c828:
mac80211: fix deadlock in driver-managed RX BA session start (2017-09-06 15:22:02 +0200)
----------------------------------------------------------------
Back from a long absence, so we have a number of things:
* a remain-on-channel fix from Avi
* hwsim TX power fix from Beni
* null-PTR dereference with iTXQ in some rare configurations (Chunho)
* 40 MHz custom regdomain fixes (Emmanuel)
* look at right place in HT/VHT capability parsing (Igor)
* complete A-MPDU teardown properly (Ilan)
* Mesh ID Element ordering fix (Liad)
* avoid tracing warning in ht_dbg() (Sharon)
* fix print of assoc/reassoc (Simon)
* fix encrypted VLAN with iTXQ (myself)
* fix calling context of TX queue wake (myself)
* fix a deadlock with ath10k aggregation (myself)
----------------------------------------------------------------
Avraham Stern (1):
mac80211: flush hw_roc_start work before cancelling the ROC
Beni Lev (1):
mac80211_hwsim: Use proper TX power
Chunho Lee (1):
mac80211: Fix null pointer dereference with iTXQ support
Emmanuel Grumbach (1):
cfg80211: honor NL80211_RRF_NO_HT40{MINUS,PLUS}
Igor Mitsyanko (1):
nl80211: look for HT/VHT capabilities in beacon's tail
Ilan peer (1):
mac80211: Complete ampdu work schedule during session tear down
Johannes Berg (3):
mac80211: fix VLAN handling with TXQs
mac80211: agg-tx: call drv_wake_tx_queue in proper context
mac80211: fix deadlock in driver-managed RX BA session start
Liad Kaufman (1):
mac80211: add MESH IE in the correct order
Sharon Dvir (1):
mac80211: shorten debug prints using ht_dbg() to avoid warning
Simon Dinkin (1):
mac80211: fix incorrect assignment of reassoc value
drivers/net/wireless/mac80211_hwsim.c | 2 --
include/net/mac80211.h | 15 ++-------------
net/mac80211/agg-rx.c | 32 ++++++++++++++++++++-----------
net/mac80211/agg-tx.c | 8 ++++++--
net/mac80211/ht.c | 24 ++++++++++++++++++++---
net/mac80211/ieee80211_i.h | 4 ++++
net/mac80211/iface.c | 20 ++++++++++++++++---
net/mac80211/mlme.c | 2 +-
net/mac80211/offchannel.c | 2 ++
net/mac80211/tx.c | 36 ++++++++++++++++++++++++++++-------
net/mac80211/util.c | 2 +-
net/wireless/nl80211.c | 4 ++--
net/wireless/reg.c | 20 +++++++++++++++++--
13 files changed, 124 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)
From: Johannes Berg @ 2017-09-07 6:45 UTC (permalink / raw)
To: Sergey Matyukevich; +Cc: linux-wireless, netdev, Igor Mitsyanko, Avinash Patil
In-Reply-To: <20170906154522.twtesbo2rxbrhekf@bars>
Hi,
> > To clarify, I think what you - conceptually - want is the following
> > topology:
> >
> > +--- eth0.1 --- br.1 --- wlan0.1
> > |
> > eth0 ---+--- eth0.2 --- br.2 --- wlan0.2
> > |
> > +--- eth0.3 --- br.3 --- wlan0.3
[...]
> That's right. In fact, hostapd is able to create this kind of network
> bridge infrastructure automatically when it is built
> with CONFIG_FULL_DYNAMIC_VLAN option enabled.
Cool, I was unaware of the exact functionality of this build-time
option. :)
> > Now, you seem to want to compress this to
> >
> > +--- wlan0.1
> > |
> > eth0 --- br ---+--- wlan0.2
> > |
> > +--- wlan0.3
[...]
> Exactly. And yes, the only purpose of this 'non-conventional' mode
> was to have 802.1Q acceleration on the ethernet port.
Right. You can still have acceleration in the top picture by placing
the feature into the Ethernet hardware, so that tagging/untagging
doesn't have to touch the packet data but just touches (skb) metadata.
But obviously that's something that happens on the other side and you
don't have control over it.
Anyway, I'm happy we cleared up what was going on and also that you
decided to leave it for now and work with the regular Linux topology
model.
Thanks,
johannes
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2017-09-07 5:46 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-kernel@vger.kernel.org, linuxwifi, Berg, Johannes,
akpm@linux-foundation.org, kvalo@codeaurora.org,
netdev@vger.kernel.org, davem@davemloft.net,
linux-wireless@vger.kernel.org, Grumbach, Emmanuel
In-Reply-To: <1504762851.5400.93.camel@coelho.fi>
On Wed, Sep 6, 2017 at 10:40 PM, Luca Coelho <luca@coelho.fi> wrote:
>
> This patch is not very important (unless you really like blinking lights
> -- maybe I'll change my mind when the holidays approach :P). so it is
> fine if you just want to revert it for now.
>
> In any case, I'll send a patch fixing this problem soon.
No need to revert if we can get this fixed quickly enough.
I'll leave the fw-31 on my laptop, so that I can continue to use it for now.
Thanks,
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: Luca Coelho @ 2017-09-07 5:40 UTC (permalink / raw)
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linuxwifi, Berg, Johannes,
akpm@linux-foundation.org, kvalo@codeaurora.org,
netdev@vger.kernel.org, davem@davemloft.net,
linux-wireless@vger.kernel.org, Grumbach, Emmanuel
In-Reply-To: <1504760688.5400.91.camel@intel.com>
On Thu, 2017-09-07 at 05:04 +0000, Coelho, Luciano wrote:
> On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote:
> > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
> > <luciano.coelho@intel.com> wrote:
> > >
> > > This seems to be a problem with backwards-compatibility with FW version
> > > 27. We are now in version 31[1] and upgrading will probably fix that.
> >
> > I can confirm that fw version 31 works.
>
> Great, so I know for sure that this is a backwards-compatibility issue
> with the FW API.
>
>
> > > But obviously the driver should not fail miserably like this with
> > > version 27, because it claims to support it still.
> >
> > Not just "claims to support it", but if it's what is shipped with a
> > fairly recent distro like an up-to-date version of F26, I would really
> > hope that the driver can still work with it.
>
> I totally agree, we support a bunch of older versions for that exact
> reason. We just don't really test all the supported versions very
> often. We should probably change that.
>
> I'll make sure it still works with version 27.
Okay, I found the offending patch:
commit 7089ae634c50544b29b31faf1a751e8765c8de3b
Author: Johannes Berg <johannes.berg@intel.com>
AuthorDate: Wed Jun 28 16:19:49 2017 +0200
Commit: Luca Coelho <luciano.coelho@intel.com>
CommitDate: Wed Aug 9 09:15:32 2017 +0300
iwlwifi: mvm: use firmware LED command where applicable
On devices starting from 8000 series, the host can no longer toggle
the LED through the CSR_LED_REG register, but must do it via the
firmware instead. Add support for this. Note that this means that
the LED cannot be turned on while the firmware is off, so using an
arbitrary LED trigger may not work as expected.
Fixes: 503ab8c56ca0 ("iwlwifi: Add 8000 HW family support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reverting it solves the problem. We introduced a new command to control
the LED lights and assumed it was available in older FW versions as
well, which turned out not to be the case.
This patch is not very important (unless you really like blinking lights
-- maybe I'll change my mind when the holidays approach :P). so it is
fine if you just want to revert it for now.
In any case, I'll send a patch fixing this problem soon.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [GIT] Networking
From: Coelho, Luciano @ 2017-09-07 5:04 UTC (permalink / raw)
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linuxwifi, Berg, Johannes,
akpm@linux-foundation.org, kvalo@codeaurora.org,
netdev@vger.kernel.org, davem@davemloft.net,
linux-wireless@vger.kernel.org, Grumbach, Emmanuel
In-Reply-To: <CA+55aFzECjnpFWo_ZfbV+vE-5zRst7JfDC0hxnoitCGN0rmE3Q@mail.gmail.com>
T24gV2VkLCAyMDE3LTA5LTA2IGF0IDIxOjU3IC0wNzAwLCBMaW51cyBUb3J2YWxkcyB3cm90ZToN
Cj4gT24gV2VkLCBTZXAgNiwgMjAxNyBhdCA5OjExIFBNLCBDb2VsaG8sIEx1Y2lhbm8NCj4gPGx1
Y2lhbm8uY29lbGhvQGludGVsLmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4gVGhpcyBzZWVtcyB0byBi
ZSBhIHByb2JsZW0gd2l0aCBiYWNrd2FyZHMtY29tcGF0aWJpbGl0eSB3aXRoIEZXIHZlcnNpb24N
Cj4gPiAyNy4gIFdlIGFyZSBub3cgaW4gdmVyc2lvbiAzMVsxXSBhbmQgdXBncmFkaW5nIHdpbGwg
cHJvYmFibHkgZml4IHRoYXQuDQo+IA0KPiBJIGNhbiBjb25maXJtIHRoYXQgZncgdmVyc2lvbiAz
MSB3b3Jrcy4NCg0KR3JlYXQsIHNvIEkga25vdyBmb3Igc3VyZSB0aGF0IHRoaXMgaXMgYSBiYWNr
d2FyZHMtY29tcGF0aWJpbGl0eSBpc3N1ZQ0Kd2l0aCB0aGUgRlcgQVBJLg0KDQoNCj4gPiBCdXQg
b2J2aW91c2x5IHRoZSBkcml2ZXIgc2hvdWxkIG5vdCBmYWlsIG1pc2VyYWJseSBsaWtlIHRoaXMg
d2l0aA0KPiA+IHZlcnNpb24gMjcsIGJlY2F1c2UgaXQgY2xhaW1zIHRvIHN1cHBvcnQgaXQgc3Rp
bGwuDQo+IA0KPiBOb3QganVzdCAiY2xhaW1zIHRvIHN1cHBvcnQgaXQiLCBidXQgaWYgaXQncyB3
aGF0IGlzIHNoaXBwZWQgd2l0aCBhDQo+IGZhaXJseSByZWNlbnQgZGlzdHJvIGxpa2UgYW4gdXAt
dG8tZGF0ZSB2ZXJzaW9uIG9mIEYyNiwgSSB3b3VsZCByZWFsbHkNCj4gaG9wZSB0aGF0IHRoZSBk
cml2ZXIgY2FuIHN0aWxsIHdvcmsgd2l0aCBpdC4NCg0KSSB0b3RhbGx5IGFncmVlLCB3ZSBzdXBw
b3J0IGEgYnVuY2ggb2Ygb2xkZXIgdmVyc2lvbnMgZm9yIHRoYXQgZXhhY3QNCnJlYXNvbi4gIFdl
IGp1c3QgZG9uJ3QgcmVhbGx5IHRlc3QgYWxsIHRoZSBzdXBwb3J0ZWQgdmVyc2lvbnMgdmVyeQ0K
b2Z0ZW4uICBXZSBzaG91bGQgcHJvYmFibHkgY2hhbmdlIHRoYXQuDQoNCkknbGwgbWFrZSBzdXJl
IGl0IHN0aWxsIHdvcmtzIHdpdGggdmVyc2lvbiAyNy4NCg0KLS0NCkNoZWVycywNCkx1Y2Eu
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2017-09-07 4:57 UTC (permalink / raw)
To: Coelho, Luciano
Cc: davem@davemloft.net, kvalo@codeaurora.org, Berg, Johannes,
Grumbach, Emmanuel, linuxwifi, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
akpm@linux-foundation.org
In-Reply-To: <1504757495.5400.89.camel@intel.com>
On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano
<luciano.coelho@intel.com> wrote:
>
> This seems to be a problem with backwards-compatibility with FW version
> 27. We are now in version 31[1] and upgrading will probably fix that.
I can confirm that fw version 31 works.
> But obviously the driver should not fail miserably like this with
> version 27, because it claims to support it still.
Not just "claims to support it", but if it's what is shipped with a
fairly recent distro like an up-to-date version of F26, I would really
hope that the driver can still work with it.
> I'm looking into this now and will provide a fix asap.
Thanks,
Linus
^ permalink raw reply
* Re: [PATCH v5] brcmfmac: add CLM download support
From: Chung-Hsien Hsu @ 2017-09-07 4:32 UTC (permalink / raw)
To: Arend van Spriel
Cc: Wright Feng, franky.lin, hante.meuleman, kvalo, chi-hsien.lin,
linux-wireless, brcm80211-dev-list.pdl
In-Reply-To: <32126aa8-359f-a333-bcc0-ecc464c5c20a@broadcom.com>
On Tue, Sep 05, 2017 at 10:03:45PM +0200, Arend van Spriel wrote:
> On 29-08-17 08:23, Wright Feng wrote:
> >From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> >
> >The firmware for brcmfmac devices includes information regarding
> >regulatory constraints. For certain devices this information is kept
> >separately in a binary form that needs to be downloaded to the device.
> >This patch adds support to download this so-called CLM blob file. It
> >uses the same naming scheme as the other firmware files with extension
> >of .clm_blob.
> >
> >The CLM blob file is optional. If the file does not exist, the download
> >process will be bypassed. It will not affect the driver loading.
>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> >Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> >---
> >v2: Revise commit message to describe in more detail
> >v3: Add error handling in brcmf_c_get_clm_name function
> >v4: Correct the length of dload_buf in brcmf_c_download function
> >v5: Remove unnecessary cast and alignment
> >---
> > .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 ++
> > .../wireless/broadcom/brcm80211/brcmfmac/common.c | 160 +++++++++++++++++++++
> > .../wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +
> > .../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
> > .../broadcom/brcm80211/brcmfmac/fwil_types.h | 31 ++++
> > .../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 19 +++
> > .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 19 +++
> > .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 18 +++
> > 8 files changed, 261 insertions(+)
>
> [...]
>
> >diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> >index 7a2b495..f6268e0 100644
> >--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> >+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> >@@ -18,6 +18,7 @@
> > #include <linux/string.h>
> > #include <linux/netdevice.h>
> > #include <linux/module.h>
> >+#include <linux/firmware.h>
> > #include <brcmu_wifi.h>
> > #include <brcmu_utils.h>
> > #include "core.h"
> >@@ -28,6 +29,7 @@
> > #include "tracepoint.h"
> > #include "common.h"
> > #include "of.h"
> >+#include "firmware.h"
>
> You are not calling anything in firmware.c from this source file so
> I do not think you need to include firmware.h here. Or did I miss
> something?
Including firmware.h here is needed. BRCMF_FW_NAME_LEN, defined in
firmware.h, is used in brcmf_c_get_clm_name() and
brcmf_c_process_clm_blob().
>
> > MODULE_AUTHOR("Broadcom Corporation");
> > MODULE_DESCRIPTION("Broadcom 802.11 wireless LAN fullmac driver.");
> >@@ -104,12 +106,138 @@ void brcmf_c_set_joinpref_default(struct brcmf_if *ifp)
> > brcmf_err("Set join_pref error (%d)\n", err);
> > }
>
> [...]
>
> >+static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
> >+{
> >+ struct device *dev = ifp->drvr->bus_if->dev;
> >+ struct brcmf_dload_data_le *chunk_buf;
> >+ const struct firmware *clm = NULL;
> >+ u8 clm_name[BRCMF_FW_NAME_LEN];
> >+ u32 chunk_len;
> >+ u32 datalen;
> >+ u32 cumulative_len = 0;
> >+ u16 dl_flag = DL_BEGIN;
> >+ u32 status;
> >+ s32 err;
> >+
> >+ brcmf_dbg(INFO, "Enter\n");
>
> Please use TRACE level for function entry logging.
Will do it.
>
> >+ memset(clm_name, 0, BRCMF_FW_NAME_LEN);
> >+ err = brcmf_c_get_clm_name(ifp, clm_name);
> >+ if (err) {
> >+ brcmf_err("get CLM blob file name failed (%d)\n", err);
> >+ return err;
> >+ }
> >+
> >+ err = request_firmware(&clm, clm_name, dev);
> >+ if (err) {
> >+ if (err == -ENOENT)
> >+ return 0;
>
> This exit point is worth a comment or even a brcmf_dbg(INFO, ...) to
> clarify what is happening here, ie. continue with CLM data currently
> present in firmware.
Will do it.
>
> >+ brcmf_err("request CLM blob file failed (%d)\n", err);
> >+ return err;
> >+ }
> >+
> >+ datalen = clm->size;
>
> move this initialization just before the do-while loop.
Will do it.
>
> >+ chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1, GFP_KERNEL);
> >+ if (!chunk_buf) {
> >+ err = -ENOMEM;
> >+ goto done;
> >+ }
>
> initialize datalen and cumulative_len here.
Will do it.
>
> >+ do {
> >+ if (datalen > MAX_CHUNK_LEN) {
> >+ chunk_len = MAX_CHUNK_LEN;
> >+ } else {
> >+ chunk_len = datalen;
> >+ dl_flag |= DL_END;
> >+ }
> >+ memcpy(chunk_buf->data, clm->data + cumulative_len, chunk_len);
> >+
> >+ err = brcmf_c_download(ifp, dl_flag, chunk_buf, chunk_len);
> >+
> >+ dl_flag &= ~DL_BEGIN;
> >+
> >+ cumulative_len += chunk_len;
> >+ datalen -= chunk_len;
> >+ } while ((datalen > 0) && (err == 0));
> >+
> >+ if (err) {
> >+ brcmf_err("clmload (%d byte file) failed (%d); ",
> >+ (u32)clm->size, err);
>
> Instead of casting clm->size it seems better to use the proper
> format specifier, ie. %zu (see format_decode() [1]).
Will do it.
>
> >+ /* Retrieve clmload_status and print */
> >+ err = brcmf_fil_iovar_int_get(ifp, "clmload_status", &status);
> >+ if (err)
> >+ brcmf_err("get clmload_status failed (%d)\n", err);
> >+ else
> >+ brcmf_dbg(INFO, "clmload_status=%d\n", status);
> >+ err = -EIO;
> >+ }
> >+
> >+ kfree(chunk_buf);
> >+done:
> >+ release_firmware(clm);
> >+ return err;
> >+}
> >+
---------------------------------------------------------------
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---------------------------------------------------------------
^ permalink raw reply
* Re: [GIT] Networking
From: Coelho, Luciano @ 2017-09-07 4:11 UTC (permalink / raw)
To: torvalds@linux-foundation.org, davem@davemloft.net,
kvalo@codeaurora.org, Berg, Johannes, Grumbach, Emmanuel
Cc: linuxwifi, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <CA+55aFw0KNTKFrRHk5hthDGTGgL9BGt9G=x_m9Tz7m_-pN+NoA@mail.gmail.com>
T24gV2VkLCAyMDE3LTA5LTA2IGF0IDE2OjI3IC0wNzAwLCBMaW51cyBUb3J2YWxkcyB3cm90ZToN
Cj4gVGhpcyBwdWxsIHJlcXVlc3QgY29tcGxldGVseSBicmVha3MgSW50ZWwgd2lyZWxlc3MgZm9y
IG1lLg0KPiANCj4gVGhpcyBpcyBteSB0cnVzdHkgb2xkIFhQUyAxMyAoOTM1MCksIHVzaW5nIElu
dGVsIFdpcmVsZXNzIDgyNjAgKHJldiAzYSkuDQo+IA0KPiBUaGF0IHJlbWFpbnMgYSB2ZXJ5IHN0
YW5kYXJkIEludGVsIG1hY2hpbmUgd2l0aCBhYnNvbHV0ZWx5IHplcm8gb2RkDQo+IHRoaW5ncyBn
b2luZyBvbi4NCj4gDQo+IFRoZSBmaXJtd2FyZSBpcyBpd2x3aWZpLTgwMDBDLTI4LnVjb2RlIGZy
b20NCj4gaXdsNzI2MC1maXJtd2FyZS0yNS4zMC4xMy4wLTc1LmZjMjYubm9hcmNoLCBhbmQgdGhl
IGtlcm5lbCByZXBvcnRzDQo+IA0KPiAgIGl3bHdpZmkgMDAwMDozYTowMC4wOiBsb2FkZWQgZmly
bXdhcmUgdmVyc2lvbiAyNy40NTU0NzAuMCBvcF9tb2RlIGl3bG12bQ0KPiANCj4gdGhlIHRoaW5n
IHN0YXJ0cyBhY3RpbmcgYmFkbHkgd2l0aCB0aGlzOg0KPiANCj4gICBpd2x3aWZpIDAwMDA6M2E6
MDAuMDogRlcgRXJyb3Igbm90aWZpY2F0aW9uOiB0eXBlIDB4MDAwMDAwMDAgY21kX2lkIDB4MDQN
Cj4gICBpd2x3aWZpIDAwMDA6M2E6MDAuMDogRlcgRXJyb3Igbm90aWZpY2F0aW9uOiBzZXEgMHgw
MDAwIHNlcnZpY2UgMHgwMDAwMDAwNA0KPiAgIGl3bHdpZmkgMDAwMDozYTowMC4wOiBGVyBFcnJv
ciBub3RpZmljYXRpb246IHRpbWVzdGFtcCAweCAgICAgICAgICAgIDVEODQNCj4gICBpd2x3aWZp
IDAwMDA6M2E6MDAuMDogTWljcm9jb2RlIFNXIGVycm9yIGRldGVjdGVkLiAgUmVzdGFydGluZyAw
eDIwMDAwMDAuDQo+ICAgaXdsd2lmaSAwMDAwOjNhOjAwLjA6IFN0YXJ0IElXTCBFcnJvciBMb2cg
RHVtcDoNCj4gICBpd2x3aWZpIDAwMDA6M2E6MDAuMDogU3RhdHVzOiAweDAwMDAwMTAwLCBjb3Vu
dDogNg0KPiAgIGl3bHdpZmkgMDAwMDozYTowMC4wOiBMb2FkZWQgZmlybXdhcmUgdmVyc2lvbjog
MjcuNDU1NDcwLjANCj4gICBpd2x3aWZpIDAwMDA6M2E6MDAuMDogMHgwMDAwMDAzOCB8IEJBRF9D
T01NQU5EDQo+ICAgaXdsd2lmaSAwMDAwOjNhOjAwLjA6IDB4MDBBMDAyRjAgfCB0cm1faHdfc3Rh
dHVzMA0KPiAgIC4uLg0KPiAgIGl3bHdpZmkgMDAwMDozYTowMC4wOiAweDAwMDAwMDAwIHwgaXNy
IHN0YXR1cyByZWcNCj4gICBpZWVlODAyMTEgcGh5MDogSGFyZHdhcmUgcmVzdGFydCB3YXMgcmVx
dWVzdGVkDQo+ICAgaXdsd2lmaSAwMDAwOjNhOjAwLjA6IEZXIGVycm9yIGluIFNZTkMgQ01EIE1B
Q19DT05URVhUX0NNRA0KDQpUaGlzIHNlZW1zIHRvIGJlIGEgcHJvYmxlbSB3aXRoIGJhY2t3YXJk
cy1jb21wYXRpYmlsaXR5IHdpdGggRlcgdmVyc2lvbg0KMjcuICBXZSBhcmUgbm93IGluIHZlcnNp
b24gMzFbMV0gYW5kIHVwZ3JhZGluZyB3aWxsIHByb2JhYmx5IGZpeCB0aGF0Lg0KDQpCdXQgb2J2
aW91c2x5IHRoZSBkcml2ZXIgc2hvdWxkIG5vdCBmYWlsIG1pc2VyYWJseSBsaWtlIHRoaXMgd2l0
aA0KdmVyc2lvbiAyNywgYmVjYXVzZSBpdCBjbGFpbXMgdG8gc3VwcG9ydCBpdCBzdGlsbC4NCg0K
SSdtIGxvb2tpbmcgaW50byB0aGlzIG5vdyBhbmQgd2lsbCBwcm92aWRlIGEgZml4IGFzYXAuDQoN
ClsxXSBodHRwczovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9maXJt
d2FyZS9saW51eC1maXJtd2FyZS5naXQvdHJlZS9pd2x3aWZpLTgwMDBDLTMxLnVjb2RlDQoNCg0K
LS0NCkNoZWVycywNCkx1Y2Eu
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2017-09-06 23:37 UTC (permalink / raw)
To: David Miller, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Kalle Valo
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux Wireless List
In-Reply-To: <CA+55aFw0KNTKFrRHk5hthDGTGgL9BGt9G=x_m9Tz7m_-pN+NoA@mail.gmail.com>
On Wed, Sep 6, 2017 at 4:27 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
>
> iwlwifi 0000:3a:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm
And when I said "iwlwifi-8000C-28.ucode" I obviously meant
"iwlwifi-8000C-27.ucode".
At least it was _hopefully_ obvious from that "27" in the actual
version number it reports.
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2017-09-06 23:31 UTC (permalink / raw)
To: torvalds
Cc: johannes.berg, emmanuel.grumbach, luciano.coelho, kvalo, akpm,
netdev, linux-kernel, linuxwifi, linux-wireless
In-Reply-To: <CA+55aFw0KNTKFrRHk5hthDGTGgL9BGt9G=x_m9Tz7m_-pN+NoA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 6 Sep 2017 16:27:15 -0700
> This pull request completely breaks Intel wireless for me.
>
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
>
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
>
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
...
Johannes and other Intel folks please look into this.
^ 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