* [PATCH 16/17] iwlwifi: mvm: Fix removal of IGTK
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Ilan Peer, Luca Coelho
In-Reply-To: <20170208155149.1704-1-luca@coelho.fi>
From: Ilan Peer <ilan.peer@intel.com>
When removing an IGTK, iwl_mvm_send_sta_igtk() was
called before station ID was retrieved, so the function
was invoked with an invalid station ID. Fix this by first
getting the station ID.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=192411
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 1bad933b3ad4..c35fabdf85da 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -3047,6 +3047,11 @@ int iwl_mvm_remove_sta_key(struct iwl_mvm *mvm,
/* Get the station from the mvm local station table */
mvm_sta = iwl_mvm_get_key_sta(mvm, vif, sta);
+ if (!mvm_sta) {
+ IWL_ERR(mvm, "Failed to find station\n");
+ return -EINVAL;
+ }
+ sta_id = mvm_sta->sta_id;
IWL_DEBUG_WEP(mvm, "mvm remove dynamic key: idx=%d sta=%d\n",
keyconf->keyidx, sta_id);
@@ -3074,8 +3079,6 @@ int iwl_mvm_remove_sta_key(struct iwl_mvm *mvm,
return 0;
}
- sta_id = mvm_sta->sta_id;
-
ret = __iwl_mvm_remove_sta_key(mvm, sta_id, keyconf, mcast);
if (ret)
return ret;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next v2 00/12] net: dsa: remove unnecessary phy.h include
From: David Miller @ 2017-02-08 16:06 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, linux-mips, linux-nfs, linux-scsi, linux-usb,
linux-wireless, target-devel, andrew, anna.schumaker,
derek.chickles, felix.manlunas, bfields, jlayton, jirislaby,
kvalo, mcgrof, madalin.bucur, UNGLinuxDriver, nab, mickflemm,
nicolas.ferre, raghu.vatsavayi, ralf, satananda.burla,
thomas.petazzoni, timur, trond.myklebust, vivien.didelot,
woojung.huh
In-Reply-To: <20170207230305.18222-1-f.fainelli@gmail.com>
RnJvbTogRmxvcmlhbiBGYWluZWxsaSA8Zi5mYWluZWxsaUBnbWFpbC5jb20+DQpEYXRlOiBUdWUs
ICA3IEZlYiAyMDE3IDE1OjAyOjUzIC0wODAwDQoNCj4gSSdtIGhvcGluZyB0aGlzIGRvZXNuJ3Qg
Y29uZmxpY3Qgd2l0aCB3aGF0J3MgYWxyZWFkeSBpbiBuZXQtbmV4dC4uLg0KPiANCj4gRGF2aWQs
IHRoaXMgc2hvdWxkIHByb2JhYmx5IGdvIHZpYSB5b3VyIHRyZWUgY29uc2lkZXJpbmcgdGhlIGRp
ZmZzdGF0Lg0KDQpJIHRoaW5rIHlvdSBuZWVkIG9uZSBtb3JlIHJlc3Bpbi4gIEFyZSB5b3UgZG9p
bmcgYW4gYWxsbW9kY29uZmlnIGJ1aWxkPw0KSWYgbm90LCBmb3Igc29tZXRoaW5nIGxpa2UgdGhp
cyBpdCdzIGEgbXVzdDoNCg0KZHJpdmVycy9uZXQvd2lyZWxlc3MvYXRoL3dpbDYyMTAvY2ZnODAy
MTEuYzoyNDozMDogZXJyb3I6IGV4cGVjdGVkIKEpoiBiZWZvcmUgoWJvb2yiDQogbW9kdWxlX3Bh
cmFtKGRpc2FibGVfYXBfc21lLCBib29sLCAwNDQ0KTsNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIF4NCmRyaXZlcnMvbmV0L3dpcmVsZXNzL2F0aC93aWw2MjEwL2NmZzgwMjExLmM6MjU6
MzQ6IGVycm9yOiBleHBlY3RlZCChKaIgYmVmb3JlIHN0cmluZyBjb25zdGFudA0KIE1PRFVMRV9Q
QVJNX0RFU0MoZGlzYWJsZV9hcF9zbWUsICIgbGV0IHVzZXIgc3BhY2UgaGFuZGxlIEFQIG1vZGUg
U01FIik7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXg0KTGlrZSBsaWtlIHRo
YXQgZmlsZSBuZWVkcyBsaW51eC9tb2R1bGUuaCBpbmNsdWRlZC4NCg0KVGhhbmtzLg0K
^ permalink raw reply
* [PATCH 15/17] iwlwifi: mvm: avoid race condition in ADD_STA.
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Goodstein, Mordechay, Luca Coelho
In-Reply-To: <20170208155149.1704-1-luca@coelho.fi>
From: "Goodstein, Mordechay" <mordechay.goodstein@intel.com>
The race happens when we send ADD_STA(auth->assoc) -> LQ_CMD
between the commands the FW sometimes loses the medium for AUX, and
sends a ndp to the AP and the flow becomes, ADD_STA -> send ndp -> LQ_CMD
the problem is that there's no rates yet defined for sending the ndp and
FW generates an assert.
The fix: change the order of the commands to LQ_CMD -> ADD_STA
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 7253b92792bf..d37b1695c64e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2627,11 +2627,10 @@ static int iwl_mvm_mac_sta_state(struct ieee80211_hw *hw,
mvmvif->ap_assoc_sta_count++;
iwl_mvm_mac_ctxt_changed(mvm, vif, false, NULL);
}
+
+ iwl_mvm_rs_rate_init(mvm, sta, mvmvif->phy_ctxt->channel->band,
+ true);
ret = iwl_mvm_update_sta(mvm, vif, sta);
- if (ret == 0)
- iwl_mvm_rs_rate_init(mvm, sta,
- mvmvif->phy_ctxt->channel->band,
- true);
} else if (old_state == IEEE80211_STA_ASSOC &&
new_state == IEEE80211_STA_AUTHORIZED) {
--
2.11.0
^ permalink raw reply related
* [PATCH 11/17] iwlwifi: dvm: don't call << operator with a negative value
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20170208155149.1704-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In https://bugzilla.kernel.org/show_bug.cgi?id=177341 Bob
reported a UBSAN WARNING on rs.c.
Undefined behaviour in drivers/net/wireless/intel/iwlwifi/dvm/rs.c:746:18
This because
i = index - 1;
for (mask = (1 << i); i >= 0; i--, mask >>= 1)
is unsafe: i could be negative and hence we can call <<
on a negative value.
This bug doesn't have any real impact since the condition
of the for loop will prevent any usage of mask.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177341
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
index 710dbbefd551..ff44ebc5829d 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
@@ -740,7 +740,10 @@ static u16 rs_get_adjacent_rate(struct iwl_priv *priv, u8 index, u16 rate_mask,
/* Find the previous rate that is in the rate mask */
i = index - 1;
- for (mask = (1 << i); i >= 0; i--, mask >>= 1) {
+ if (i >= 0)
+ mask = BIT(i);
+
+ for (; i >= 0; i--, mask >>= 1) {
if (rate_mask & mask) {
low = i;
break;
--
2.11.0
^ permalink raw reply related
* [PATCH 13/17] iwlwifi: pcie: set STATUS_RFKILL immediately after interrupt
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Golan Ben Ami, Luca Coelho
In-Reply-To: <20170208155149.1704-1-luca@coelho.fi>
From: Golan Ben Ami <golan.ben.ami@intel.com>
Currently, when getting a RFKILL interrupt, the transport enters a flow
in which it stops the device, disables other interrupts, etc. After
stopping the device, the transport resets the hw, and sleeps. During
the sleep, a context switch occurs and host commands are sent by upper
layers (e.g. mvm) to the fw. This is possible since the op_mode layer
and the transport layer hold different mutexes.
Since the STATUS_RFKILL bit isn't set, the transport layer doesn't
recognize that RFKILL was toggled on, and no commands can actually be
sent, so it enqueues the command to the tx queue and sets a timer on
the queue.
After switching context back to stopping the device, STATUS_RFKILL is
set, and then the transport can't send the command to the fw.
This eventually results in a queue hang.
Fix this by setting STATUS_RFKILL immediately when
the interrupt is fired.
Signed-off-by: Golan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index e1bf6da20909..de94dfdf2ec9 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1609,6 +1609,9 @@ irqreturn_t iwl_pcie_irq_handler(int irq, void *dev_id)
mutex_lock(&trans_pcie->mutex);
hw_rfkill = iwl_is_rfkill_set(trans);
+ if (hw_rfkill)
+ set_bit(STATUS_RFKILL, &trans->status);
+
IWL_WARN(trans, "RF_KILL bit toggled to %s.\n",
hw_rfkill ? "disable radio" : "enable radio");
@@ -1617,7 +1620,6 @@ irqreturn_t iwl_pcie_irq_handler(int irq, void *dev_id)
iwl_trans_pcie_rf_kill(trans, hw_rfkill);
mutex_unlock(&trans_pcie->mutex);
if (hw_rfkill) {
- set_bit(STATUS_RFKILL, &trans->status);
if (test_and_clear_bit(STATUS_SYNC_HCMD_ACTIVE,
&trans->status))
IWL_DEBUG_RF_KILL(trans,
@@ -1954,6 +1956,9 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void *dev_id)
mutex_lock(&trans_pcie->mutex);
hw_rfkill = iwl_is_rfkill_set(trans);
+ if (hw_rfkill)
+ set_bit(STATUS_RFKILL, &trans->status);
+
IWL_WARN(trans, "RF_KILL bit toggled to %s.\n",
hw_rfkill ? "disable radio" : "enable radio");
@@ -1962,7 +1967,6 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void *dev_id)
iwl_trans_pcie_rf_kill(trans, hw_rfkill);
mutex_unlock(&trans_pcie->mutex);
if (hw_rfkill) {
- set_bit(STATUS_RFKILL, &trans->status);
if (test_and_clear_bit(STATUS_SYNC_HCMD_ACTIVE,
&trans->status))
IWL_DEBUG_RF_KILL(trans,
--
2.11.0
^ permalink raw reply related
* [PATCH 10/17] iwlwifi: make RTPM depend on EXPERT
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20170208155149.1704-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Enabling the RTPM Kconfig option can be fairly risky.
Runtime PM must be validated against a specific platform
before it can be safely enabled. Hence, it makes no sense
for distros and other big OS vendors to enable it since
they ship code to various systems and unknown platform.
Make sure that this is hinted properly by making the
IWLWIFI_PCIE_RTPM Kconfig option depend on EXPERT.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=172411
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/Kconfig | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig b/drivers/net/wireless/intel/iwlwifi/Kconfig
index b64db47b31bb..c5f2ddf9b0fe 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -90,13 +90,16 @@ config IWLWIFI_BCAST_FILTERING
config IWLWIFI_PCIE_RTPM
bool "Enable runtime power management mode for PCIe devices"
- depends on IWLMVM && PM
+ depends on IWLMVM && PM && EXPERT
default false
help
Say Y here to enable runtime power management for PCIe
devices. If enabled, the device will go into low power mode
when idle for a short period of time, allowing for improved
- power saving during runtime.
+ power saving during runtime. Note that this feature requires
+ a tight integration with the platform. It is not recommended
+ to enable this feature without proper validation with the
+ specific target platform.
If unsure, say N.
--
2.11.0
^ permalink raw reply related
* [PATCH 12/17] iwlwifi: mvm: don't call << operator with a negative value
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20170208155149.1704-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In https://bugzilla.kernel.org/show_bug.cgi?id=177341 Bob
reported a UBSAN WARNING on rs.c in iwldvm.
Fix the same bug in iwlmvm.
This because
i = index - 1;
for (mask = (1 << i); i >= 0; i--, mask >>= 1)
is unsafe: i could be negative and hence we can call <<
on a negative value.
This bug doesn't have any real impact since the condition
of the for loop will prevent any usage of mask.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177341
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 13be9a5b83ee..ce907c58ebf6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -972,7 +972,9 @@ static u16 rs_get_adjacent_rate(struct iwl_mvm *mvm, u8 index, u16 rate_mask,
/* Find the previous rate that is in the rate mask */
i = index - 1;
- for (mask = (1 << i); i >= 0; i--, mask >>= 1) {
+ if (i >= 0)
+ mask = BIT(i);
+ for (; i >= 0; i--, mask >>= 1) {
if (rate_mask & mask) {
low = i;
break;
--
2.11.0
^ permalink raw reply related
* [PATCH 14/17] iwlwifi: mvm: Fix CSA received immediately after association
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Avraham Stern, Luca Coelho
In-Reply-To: <20170208155149.1704-1-luca@coelho.fi>
From: Avraham Stern <avraham.stern@intel.com>
The session protection set for association is only removed when
BSS_CHANGED_BEACON_INFO is set and BSS_CHANGED_ASSOC is not set.
However, mac80211 may set both on association (in case a beacon was
already received). In this case, mac80211 will not set
BSS_CHANGED_BEACON_INFO on the next beacons because it has already
notified the beacon change, so the session protection is never removed
(until the session protection ends).
When a CSA is received within this time, the station will fail to
folllow the channel switch because it cannot schedule the time event.
Fix this by removing the session protection when
BSS_CHANGED_BEACON_INFO and BSS_CHANGED_ASSOC are both set.
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 | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 15ecd3aba71b..7253b92792bf 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2008,16 +2008,16 @@ static void iwl_mvm_bss_info_changed_station(struct iwl_mvm *mvm,
if (fw_has_capa(&mvm->fw->ucode_capa,
IWL_UCODE_TLV_CAPA_UMAC_SCAN))
iwl_mvm_config_scan(mvm);
- } else if (changes & BSS_CHANGED_BEACON_INFO) {
+ }
+
+ if (changes & BSS_CHANGED_BEACON_INFO) {
/*
- * We received a beacon _after_ association so
+ * We received a beacon from the associated AP so
* remove the session protection.
*/
iwl_mvm_remove_time_event(mvm, mvmvif,
&mvmvif->time_event_data);
- }
- if (changes & BSS_CHANGED_BEACON_INFO) {
iwl_mvm_sf_update(mvm, vif, false);
WARN_ON(iwl_mvm_enable_beacon_filter(mvm, vif, 0));
}
--
2.11.0
^ permalink raw reply related
* [PATCH 09/17] iwlwifi: pcie: don't increment / decrement a bool
From: Luca Coelho @ 2017-02-08 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20170208112322.29413-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
David reported that the code I added uses the decrement
and increment operator on a boolean variable.
Fix that.
Fixes: 0cd58eaab148 ("iwlwifi: pcie: allow the op_mode to block the tx queues")
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
index cf5bda06042c..10937309641a 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -279,7 +279,7 @@ struct iwl_txq {
bool frozen;
u8 active;
bool ampdu;
- bool block;
+ int block;
unsigned long wd_timeout;
struct sk_buff_head overflow_q;
--
2.11.0
^ permalink raw reply related
* Re: [1/2] rt2x00usb: do not anchor rx and tx urb's
From: Kalle Valo @ 2017-02-08 15:30 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Vishal Thanki
In-Reply-To: <1486552690-27597-1-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> We might kill TX or RX urb during rt2x00usb_flush_entry(), what can
> cause anchor list corruption like shown below:
>
> [ 2074.035633] WARNING: CPU: 2 PID: 14480 at lib/list_debug.c:33 __list_add+0xac/0xc0
> [ 2074.035634] list_add corruption. prev->next should be next (ffff88020f362c28), but was dead000000000100. (prev=ffff8801d161bb70).
> <snip>
> [ 2074.035670] Call Trace:
> [ 2074.035672] [<ffffffff813bde47>] dump_stack+0x63/0x8c
> [ 2074.035674] [<ffffffff810a2231>] __warn+0xd1/0xf0
> [ 2074.035676] [<ffffffff810a22af>] warn_slowpath_fmt+0x5f/0x80
> [ 2074.035678] [<ffffffffa073855d>] ? rt2x00usb_register_write_lock+0x3d/0x60 [rt2800usb]
> [ 2074.035679] [<ffffffff813dbe4c>] __list_add+0xac/0xc0
> [ 2074.035681] [<ffffffff81591c6c>] usb_anchor_urb+0x4c/0xa0
> [ 2074.035683] [<ffffffffa07322af>] rt2x00usb_kick_rx_entry+0xaf/0x100 [rt2x00usb]
> [ 2074.035684] [<ffffffffa0732322>] rt2x00usb_clear_entry+0x22/0x30 [rt2x00usb]
>
> To fix do not anchor TX and RX urb's, it is not needed as during
> shutdown we kill those urbs in rt2x00usb_free_entries().
>
> Cc: Vishal Thanki <vishalthanki@gmail.com>
> Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
2 patches applied to wireless-drivers-next.git, thanks.
93c7018ec16b rt2x00usb: do not anchor rx and tx urb's
0488a6121dfe rt2x00usb: fix anchor initialization
--
https://patchwork.kernel.org/patch/9562337/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/3] rt61pci: use entry directly
From: Kalle Valo @ 2017-02-08 15:31 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa
In-Reply-To: <1486558291-1615-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
3 patches applied to wireless-drivers-next.git, thanks.
80a97eae3046 rt61pci: use entry directly
2ceb813798e1 rt2x00: call entry directly in rt2x00_dump_frame
cf81db30a6ed rt2x00: remove queue_entry from skbdesc
--
https://patchwork.kernel.org/patch/9562469/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: Move items out of rtl_pci_priv and rtl_usb_priv
From: Kalle Valo @ 2017-02-08 15:25 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger
In-Reply-To: <20170207151421.32559-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit 6773386f977c ("rtlwifi: rtl8192c-common: Fix "BUG: KASAN:"),
> a BUG detected when CONFIG_KASAN=y was fixed by reordering the layouts
> of struct rtl_pci_priv, and struct rtl_usb_priv so that the variables
> used by both PCI and USB drivers have the same offsets in both structs.
> The better fix of relocating the critical variables into struct rtl_priv
> was deferred as these changes do not have to be applied to stable
> kernels.
>
> This change also removes CamelCase variables with pLed0 => pled0.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers-next.git, thanks.
d5efe1535af0 rtlwifi: Move items out of rtl_pci_priv and rtl_usb_priv
--
https://patchwork.kernel.org/patch/9560369/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V3,1/9] brcmfmac: merge two brcmf_err macros into one
From: Kalle Valo @ 2017-02-08 15:24 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170202213321.11591-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This allows simplifying the code by adding a simple IS_ENABLED check for
> CONFIG_BRCMDB symbol.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
3 patches applied to wireless-drivers-next.git, thanks.
9587a01a7ead brcmfmac: merge two brcmf_err macros into one
087fa712a006 brcmfmac: switch to C function (__brcmf_err) for printing errors
d0630555650a brcmfmac: merge two remaining brcmf_err macros
--
https://patchwork.kernel.org/patch/9553249/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wil6210: include moduleparam.h
From: Kalle Valo @ 2017-02-08 15:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20170207143328.22529-1-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This now declares a module parameter, so include the necessary
> header file for that.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Patch applied to ath-next branch of ath.git, thanks.
949c2d009675 wil6210: include moduleparam.h
--
https://patchwork.kernel.org/patch/9560281/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: select WANT_DEV_COREDUMP
From: Kalle Valo @ 2017-02-08 15:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20170207222933.12701-1-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This is necessary so that - if ath10k is the only driver using
> dev_coredump*() - the functionality is built into the kernel.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Patch applied to ath-next branch of ath.git, thanks.
5524ddd4c1f1 ath10k: select WANT_DEV_COREDUMP
--
https://patchwork.kernel.org/patch/9561349/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN
From: Andrey Ryabinin @ 2017-02-08 14:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Johannes Berg, David Miller, Networking, stable,
Linux Kernel Mailing List, nikolay, nicolas.dichtel, adobriyan,
linux-wireless
In-Reply-To: <CAK8P3a2fHm9j7roYjTAXJ_zsdXF88p_6Y-hCF6aWjJzcAaQ3Uw@mail.gmail.com>
2017-02-08 16:10 GMT+03:00 Arnd Bergmann <arnd@arndb.de>:
> On Wed, Feb 8, 2017 at 1:24 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> Btw, what's causing this to start with? Can't the compiler reuse the
>> stack places?
>
> I have no idea. It's trying to find out of bounds accesses for
> objects on the stack, so maybe it gives each variable a separate
> stack location in order to see which one caused problems?
>
If compiler cannot prove that access to the local variable is valid it
will add redzones around that variable
to be able to detect out of bounds accesses.
For example:
static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
{
return nla_put(skb, attrtype, sizeof(u8), &value);
}
compiler will surround 'value' with redzones to catch potential oob
access in nla_put().
Another way to fix this, would be something like this:
#ifdef CONFIG_KASAN
/* don't bloat stack */
#define __noinline_for_kasan __noinline __maybe_unused
#else
#define __noinline_for_kasan inline
#endif
static __noinline_for_kasan int nla_put_u8(struct sk_buff *skb, int
attrtype, u8 value)
{
return nla_put(skb, attrtype, sizeof(u8), &value);
}
^ permalink raw reply
* Re: [PATCH V3 4/9] brcmfmac: add struct brcmf_pub parameter to the __brcmf_err
From: Kalle Valo @ 2017-02-08 14:52 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend Van Spriel, Rafał Miłecki, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <209e8eef55927a76470d44482c6d0090@milecki.pl>
Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl> writes:
> On 2017-02-08 10:54, Arend Van Spriel wrote:
>> On 2-2-2017 22:33, Rafa=C5=82 Mi=C5=82ecki wrote:
>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>
>>> This will allow getting struct device reference from the passed
>>> brcmf_pub for the needs of dev_err. More detailed messages are really
>>> important for home routers which frequently have 2 (or even 3)
>>> wireless
>>> cards supported by brcmfmac.
>>>
>>> Note that all calls are yet to be updated as for now brcmf_err macro
>>> always passes NULL. This will be handled in following patch to make
>>> this
>>> change easier to review.
>>
>> I prefer brcmf_err() to have struct device reference directly
>> instead of
>> using brcmf_pub. That would remove the need for patches 5 till 7 as bus
>> specific code already has struct device. So I have acked the first
>> three
>> patches, but would like to revise 8 and 9.
>>
>> Kalle,
>>
>> I acked the first three patches. Can those three still go in for 4.11?
>
> Sounds OK to me. Kalle, I ack Arend's request if it isn't too late.
Ok, I'll try. My plan is to get everything ready for linux-next by
tomorrow morning (Finland time), let's see how it goes.
Related to this, Rafa=C5=82 are you still deleting the patches from patchwo=
rk
which should be dropped? I think you are as I can't see patches 4-9
anymore.
Now that my patchwork setup is much better (compared to how it was over
a year ago) I would actually prefer that you don't do that anymore. The
problem is that when you delete the patch from patchwork it completely
disappears from patchwork and I can't check the patch or discussion
anymore. And I'm so accustomed to use patchwork that only seldom I use
email to find the patch.
So it would be better to leave the patches as is and let me drop them
(=3Dchange the state Changes Requested, Rejected or similar), which is
trivial with my script. Otherwise I get this unsure feeling of what
happened to the patch :)
--=20
Kalle Valo
^ permalink raw reply
* [PATCH] mac80211: fix CSA in IBSS mode
From: Koen Vandeputte @ 2017-02-08 14:32 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, Koen Vandeputte, Piotr Gawlowicz,
Mikołaj Chwalisz
Add the missing IBSS capability flag during capability init as it needs
to be inserted into the generated beacon in order for CSA to work.
Signed-off-by: Piotr Gawlowicz <gawlowicz@tkn.tu-berlin.de>
Signed-off-by: Mikołaj Chwalisz <chwalisz@tkn.tu-berlin.de>
Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
---
net/mac80211/ibss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index a31d307..98999d3 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -487,14 +487,14 @@ int ieee80211_ibss_csa_beacon(struct ieee80211_sub_if_data *sdata,
struct beacon_data *presp, *old_presp;
struct cfg80211_bss *cbss;
const struct cfg80211_bss_ies *ies;
- u16 capability = 0;
+ u16 capability = WLAN_CAPABILITY_IBSS;
u64 tsf;
int ret = 0;
sdata_assert_lock(sdata);
if (ifibss->privacy)
- capability = WLAN_CAPABILITY_PRIVACY;
+ capability |= WLAN_CAPABILITY_PRIVACY;
cbss = cfg80211_get_bss(sdata->local->hw.wiphy, ifibss->chandef.chan,
ifibss->bssid, ifibss->ssid,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 00/17] iwlwifi: updates intended for v4.11 2017-02-08
From: Coelho, Luciano @ 2017-02-08 14:31 UTC (permalink / raw)
To: kvalo@codeaurora.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <87vaskn4bo.fsf@kamboji.qca.qualcomm.com>
T24gV2VkLCAyMDE3LTAyLTA4IGF0IDE2OjI5ICswMjAwLCBLYWxsZSBWYWxvIHdyb3RlOg0KPiBM
dWNhIENvZWxobyA8bHVjYUBjb2VsaG8uZmk+IHdyaXRlczoNCj4gDQo+ID4gVGhpcyBpcyB0aGUg
dGhpcmQgYW5kIGZpbmFsIHB1bGwtcmVxdWVzdCBiZWZvcmUgNC4xMSdzIG1lcmdlIHdpbmRvdy4N
Cj4gPiBUaGlzIHRpbWUgSSBjb25jZW50cmF0ZWQgaW4gYnVnZml4ZXM6DQo+ID4gDQo+ID4gKiBG
aXggODAyLjExdywgd2hpY2ggd2FzIGZhaWxpbmcgdG8gZHVlIGFuIElHVEsgYnVnOw0KPiA+ICog
QSBmZXcgbW9yZSBidWd6aWxsYSBidWcgZml4ZXM7DQo+ID4gKiBBIGNoYW5uZWwtc3dpdGNoIHJh
Y2UgY29uZGl0aW9uIGZpeDsNCj4gPiAqIFNvbWUgZml4ZXMgcmVsYXRlZCB0byBzdXNwZW5kL3Jl
c3VtZSB3aXRoIG5ldyBIVzsNCj4gPiAqIFRoZSBSRi1raWxsIHNhZ2EgY29udGludWVzOw0KPiA+
ICogQW5kIHNvbWUgb3RoZXIgZml4ZXMgaGVyZSBhbmQgdGhlcmUuLi4NCj4gPiANCj4gPiBBcyB1
c3VhbCwgSSdtIHB1c2hpbmcgdGhpcyB0byBhIHBlbmRpbmcgYnJhbmNoLCBmb3Iga2J1aWxkIGJv
dCwgYW5kDQo+ID4gd2lsbCBzZW5kIGEgcHVsbC1yZXF1ZXN0IGxhdGVyLg0KPiA+IA0KPiA+IFBs
ZWFzZSByZXZpZXcuDQo+IA0KPiBJIG9ubHkgc2VlIHBhdGNoZXMgMS04IGluIHRoZSBtYWlsaW5n
IGxpc3Qgb3IgaW4gbXkgaW5ib3gsIHdoYXQgaGFwcGVuZWQNCj4gdG8gdGhlIHJlc3Q/DQoNCk5v
dCBzdXJlLCBtYXliZSB0aGV5IGFyZSBzdGlsbCBxdWV1ZWQgaW4gbXkgc2VydmVyPyBMZXQgbWUg
Y2hlY2suDQoNCi0tDQpMdWNhLg==
^ permalink raw reply
* Re: [PATCH 00/17] iwlwifi: updates intended for v4.11 2017-02-08
From: Kalle Valo @ 2017-02-08 14:29 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <20170208112322.29413-1-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> This is the third and final pull-request before 4.11's merge window.
> This time I concentrated in bugfixes:
>
> * Fix 802.11w, which was failing to due an IGTK bug;
> * A few more bugzilla bug fixes;
> * A channel-switch race condition fix;
> * Some fixes related to suspend/resume with new HW;
> * The RF-kill saga continues;
> * And some other fixes here and there...
>
> As usual, I'm pushing this to a pending branch, for kbuild bot, and
> will send a pull-request later.
>
> Please review.
I only see patches 1-8 in the mailing list or in my inbox, what happened
to the rest?
--
Kalle Valo
^ permalink raw reply
* ANNOUNCE: Netdev 2.1 seeking netdev conferences reporter(s)
From: Jamal Hadi Salim @ 2017-02-08 14:10 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: netfilter-devel, netfilter, info, linux-wireless, tech-committee,
David Miller, Stephen Jaworski, Rob Echlin, lwn, people
Folks,
We are seeking for qualified people who love to write to cover the
netdev 2.1 conference.
The idea is to attend the different sessions and describe what
was discussed in a timely manner. We would like to publish the
events on a daily basis.
Requirements:
1) Passion about netdev
2) Knowledge of the different technical topics under discussion.
We will work to have you access knowledgeable people in the
different topics including the speaker.
3) Average writting skills. We will work to give you access to
people who have better writing skills than you.
4) Desire to be famous
cheers,
jamal
^ permalink raw reply
* [PATCH v4] wlcore: disable multicast filter in AP mode
From: Iain Hunter @ 2017-02-08 14:09 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
In-Reply-To: <20170131104840.10366-1-i-hunter1@ti.com>
Enable AP support for allmulticast for MDNS. It can be enabled by bringing
up the interface with ip command with argument allmulticast on
---
PATCH v4: fixes space in signed-off, tabbing for comment and indentation of closing bracket
drivers/net/wireless/ti/wlcore/main.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..242111cd016 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,21 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI) {
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+ if (ret < 0)
+ goto out_sleep;
+ }
+ }
}
/*
--
2.11.0
^ permalink raw reply related
* Re: [PATCH V3 4/9] brcmfmac: add struct brcmf_pub parameter to the __brcmf_err
From: Rafał Miłecki @ 2017-02-08 10:00 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Rafał Miłecki, Kalle Valo, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <2812805e-9108-284f-2165-34624d603364@broadcom.com>
On 2017-02-08 10:54, Arend Van Spriel wrote:
> On 2-2-2017 22:33, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> This will allow getting struct device reference from the passed
>> brcmf_pub for the needs of dev_err. More detailed messages are really
>> important for home routers which frequently have 2 (or even 3)
>> wireless
>> cards supported by brcmfmac.
>>
>> Note that all calls are yet to be updated as for now brcmf_err macro
>> always passes NULL. This will be handled in following patch to make
>> this
>> change easier to review.
>
> I prefer brcmf_err() to have struct device reference directly instead
> of
> using brcmf_pub. That would remove the need for patches 5 till 7 as bus
> specific code already has struct device. So I have acked the first
> three
> patches, but would like to revise 8 and 9.
>
> Kalle,
>
> I acked the first three patches. Can those three still go in for 4.11?
Sounds OK to me. Kalle, I ack Arend's request if it isn't too late.
^ permalink raw reply
* [PATCH 0/3] rt2x00 skb_desc cleanup
From: Stanislaw Gruszka @ 2017-02-08 12:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa
Remove entry field from skb_desc in order to use this skb_desc
place for other pointer.
This is intended to -next.
Stanislaw Gruszka (3):
rt61pci: use entry directly
rt2x00: call entry directly in rt2x00_dump_frame
rt2x00: remove queue_entry from skbdesc
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 7 ++++---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 5 +----
drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 2 --
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 5 ++---
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 2 +-
11 files changed, 16 insertions(+), 21 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH 1/3] rt61pci: use entry directly
From: Stanislaw Gruszka @ 2017-02-08 12:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa
In-Reply-To: <1486558291-1615-1-git-send-email-sgruszka@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt61pci.c b/drivers/net/wireless/ralink/rt2x00/rt61pci.c
index 5306a3b..8adb5f3 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt61pci.c
@@ -1903,8 +1903,7 @@ static void rt61pci_write_tx_desc(struct queue_entry *entry,
rt2x00_desc_read(txd, 5, &word);
rt2x00_set_field32(&word, TXD_W5_PID_TYPE, entry->queue->qid);
- rt2x00_set_field32(&word, TXD_W5_PID_SUBTYPE,
- skbdesc->entry->entry_idx);
+ rt2x00_set_field32(&word, TXD_W5_PID_SUBTYPE, entry->entry_idx);
rt2x00_set_field32(&word, TXD_W5_TX_POWER,
TXPOWER_TO_DEV(entry->queue->rt2x00dev->tx_power));
rt2x00_set_field32(&word, TXD_W5_WAITING_DMA_DONE_INT, 1);
--
1.8.3.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