* [PATCH 2/6] iwlwifi: mvm: properly check for transport data in dump
From: Luca Coelho @ 2017-01-13 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Luca Coelho
In-Reply-To: <20170113123919.30384-1-luca@coelho.fi>
From: Johannes Berg <johannes.berg@intel.com>
When copying from vmalloc'ed memory to the SG list, don't crash
if the transport didn't provide any data.
Fixes: 7e62a699aafb ("iwlwifi: mvm: use dev_coredumpsg()")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
index 2e8e3e8e30a3..067f67f74698 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
@@ -816,11 +816,12 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
sg_nents(sg_dump_data),
fw_error_dump->op_mode_ptr,
fw_error_dump->op_mode_len, 0);
- sg_pcopy_from_buffer(sg_dump_data,
- sg_nents(sg_dump_data),
- fw_error_dump->trans_ptr->data,
- fw_error_dump->trans_ptr->len,
- fw_error_dump->op_mode_len);
+ if (fw_error_dump->trans_ptr)
+ sg_pcopy_from_buffer(sg_dump_data,
+ sg_nents(sg_dump_data),
+ fw_error_dump->trans_ptr->data,
+ fw_error_dump->trans_ptr->len,
+ fw_error_dump->op_mode_len);
dev_coredumpsg(mvm->trans->dev, sg_dump_data, file_len,
GFP_KERNEL);
}
--
2.11.0
^ permalink raw reply related
* [PATCH 4/6] iwlwifi: fix MODULE_FIRMWARE for 6030
From: Luca Coelho @ 2017-01-13 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Jürg Billeter, Luca Coelho
In-Reply-To: <20170113123919.30384-1-luca@coelho.fi>
From: Jürg Billeter <j@bitron.ch>
IWL6000G2B_UCODE_API_MAX is not defined. ucode_api_max of
IWL_DEVICE_6030 uses IWL6000G2_UCODE_API_MAX. Use this also for
MODULE_FIRMWARE.
Fixes: 9d9b21d1b616 ("iwlwifi: remove IWL_*_UCODE_API_OK")
Signed-off-by: Jürg Billeter <j@bitron.ch>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/iwl-6000.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-6000.c b/drivers/net/wireless/intel/iwlwifi/iwl-6000.c
index 0b9f6a7bc834..39335b7b0c16 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-6000.c
@@ -371,4 +371,4 @@ const struct iwl_cfg iwl6000_3agn_cfg = {
MODULE_FIRMWARE(IWL6000_MODULE_FIRMWARE(IWL6000_UCODE_API_MAX));
MODULE_FIRMWARE(IWL6050_MODULE_FIRMWARE(IWL6050_UCODE_API_MAX));
MODULE_FIRMWARE(IWL6005_MODULE_FIRMWARE(IWL6000G2_UCODE_API_MAX));
-MODULE_FIRMWARE(IWL6030_MODULE_FIRMWARE(IWL6000G2B_UCODE_API_MAX));
+MODULE_FIRMWARE(IWL6030_MODULE_FIRMWARE(IWL6000G2_UCODE_API_MAX));
--
2.11.0
^ permalink raw reply related
* [PATCH 0/6] iwlwifi: updates intended for v4.10 2017-01-13
From: Luca Coelho @ 2017-01-13 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Luca Coelho
From: Luca Coelho <luciano.coelho@intel.com>
Hi,
Here are a few fixes that I intend to send for v4.10:
* fix suspend failure with unified firmware images
* fix a potential crash when dumping debug data
* fix a couple of mistakes in FW names exported by the modules
* small fix for PS-Poll enabling via debugfs
* fix for dynamic queue allocation offchannel data
I'll wait for kbuildbot results and then I'll send a pull-request for
them.
Cheers,
Luca.
Beni Lev (1):
iwlwifi: mvm: Use aux queue for offchannel frames in dqa
Emmanuel Grumbach (1):
iwlwifi: mvm: fix PS-Poll enablement
Johannes Berg (1):
iwlwifi: mvm: properly check for transport data in dump
Jürg Billeter (2):
iwlwifi: fix double hyphen in MODULE_FIRMWARE for 8000
iwlwifi: fix MODULE_FIRMWARE for 6030
Luca Coelho (1):
iwlwifi: mvm: don't restart HW if suspend fails with unified image
drivers/net/wireless/intel/iwlwifi/iwl-6000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 13 ++++++++-----
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 11 ++++++-----
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 18 ++++++++----------
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 ++++++----
6 files changed, 30 insertions(+), 26 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 5/6] iwlwifi: mvm: fix PS-Poll enablement
From: Luca Coelho @ 2017-01-13 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20170113123919.30384-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
We added the uAPSD enabled ACs and that made the
firmware choose to pull frames with uAPSD trigger
frames instead of PS-Poll.
Fix that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/power.c b/drivers/net/wireless/intel/iwlwifi/mvm/power.c
index af6d10c23e5a..3a8e9379da2f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/power.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/power.c
@@ -174,6 +174,14 @@ static void iwl_mvm_power_configure_uapsd(struct iwl_mvm *mvm,
enum ieee80211_ac_numbers ac;
bool tid_found = false;
+#ifdef CONFIG_IWLWIFI_DEBUGFS
+ /* set advanced pm flag with no uapsd ACs to enable ps-poll */
+ if (mvmvif->dbgfs_pm.use_ps_poll) {
+ cmd->flags |= cpu_to_le16(POWER_FLAGS_ADVANCE_PM_ENA_MSK);
+ return;
+ }
+#endif
+
for (ac = IEEE80211_AC_VO; ac <= IEEE80211_AC_BK; ac++) {
if (!mvmvif->queue_params[ac].uapsd)
continue;
@@ -204,16 +212,6 @@ static void iwl_mvm_power_configure_uapsd(struct iwl_mvm *mvm,
}
}
- if (!(cmd->flags & cpu_to_le16(POWER_FLAGS_ADVANCE_PM_ENA_MSK))) {
-#ifdef CONFIG_IWLWIFI_DEBUGFS
- /* set advanced pm flag with no uapsd ACs to enable ps-poll */
- if (mvmvif->dbgfs_pm.use_ps_poll)
- cmd->flags |=
- cpu_to_le16(POWER_FLAGS_ADVANCE_PM_ENA_MSK);
-#endif
- return;
- }
-
cmd->flags |= cpu_to_le16(POWER_FLAGS_UAPSD_MISBEHAVING_ENA_MSK);
if (cmd->uapsd_ac_flags == (BIT(IEEE80211_AC_VO) |
--
2.11.0
^ permalink raw reply related
* [PATCH 1/6] iwlwifi: mvm: don't restart HW if suspend fails with unified image
From: Luca Coelho @ 2017-01-13 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Luca Coelho
In-Reply-To: <20170113123919.30384-1-luca@coelho.fi>
From: Luca Coelho <luciano.coelho@intel.com>
For unified images, we shouldn't restart the HW if suspend fails. The
only reason for restarting the HW with non-unified images is to go
back to the D0 image.
Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index b88e2048ae0b..207d8ae1e116 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -1262,12 +1262,15 @@ static int __iwl_mvm_suspend(struct ieee80211_hw *hw,
iwl_trans_d3_suspend(mvm->trans, test, !unified_image);
out:
if (ret < 0) {
- iwl_mvm_ref(mvm, IWL_MVM_REF_UCODE_DOWN);
- if (mvm->restart_fw > 0) {
- mvm->restart_fw--;
- ieee80211_restart_hw(mvm->hw);
- }
iwl_mvm_free_nd(mvm);
+
+ if (!unified_image) {
+ iwl_mvm_ref(mvm, IWL_MVM_REF_UCODE_DOWN);
+ if (mvm->restart_fw > 0) {
+ mvm->restart_fw--;
+ ieee80211_restart_hw(mvm->hw);
+ }
+ }
}
out_noreset:
mutex_unlock(&mvm->mutex);
--
2.11.0
^ permalink raw reply related
* [PATCH 3/6] iwlwifi: fix double hyphen in MODULE_FIRMWARE for 8000
From: Luca Coelho @ 2017-01-13 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Jürg Billeter, Luca Coelho
In-Reply-To: <20170113123919.30384-1-luca@coelho.fi>
From: Jürg Billeter <j@bitron.ch>
There is only a single hyphen between iwlwifi-8000C and the API version
in the firmware filename.
Fixes: e1ba684f762b ("iwlwifi: 8000: fix MODULE_FIRMWARE input")
Signed-off-by: Jürg Billeter <j@bitron.ch>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
index d02ca1491d16..8d3e53fac1da 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
@@ -91,7 +91,7 @@
#define IWL8000_FW_PRE "iwlwifi-8000C-"
#define IWL8000_MODULE_FIRMWARE(api) \
- IWL8000_FW_PRE "-" __stringify(api) ".ucode"
+ IWL8000_FW_PRE __stringify(api) ".ucode"
#define IWL8265_FW_PRE "iwlwifi-8265-"
#define IWL8265_MODULE_FIRMWARE(api) \
--
2.11.0
^ permalink raw reply related
* [PATCH 6/6] iwlwifi: mvm: Use aux queue for offchannel frames in dqa
From: Luca Coelho @ 2017-01-13 12:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Beni Lev, Luca Coelho
In-Reply-To: <20170113123919.30384-1-luca@coelho.fi>
From: Beni Lev <beni.lev@intel.com>
Since offchannel activity doesn't always require a BSS, e.g. ANQP
sessions, offchannel frames should not use the BSS queue, because it
might not be initialized. Use the auxilary queue instead.
Fixes: e3118ad74d7e ("iwlwifi: mvm: support tdls in dqa mode")
Signed-off-by: Beni Lev <beni.lev@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 66957ac12ca4..52ad6190a4b8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -563,9 +563,10 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb)
* (this is not possible for unicast packets as a TLDS discovery
* response are sent without a station entry); otherwise use the
* AUX station.
- * In DQA mode, if vif is of type STATION and frames are not multicast,
- * they should be sent from the BSS queue. For example, TDLS setup
- * frames should be sent on this queue, as they go through the AP.
+ * In DQA mode, if vif is of type STATION and frames are not multicast
+ * or offchannel, they should be sent from the BSS queue.
+ * For example, TDLS setup frames should be sent on this queue,
+ * as they go through the AP.
*/
sta_id = mvm->aux_sta.sta_id;
if (info.control.vif) {
@@ -587,7 +588,8 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb)
if (ap_sta_id != IWL_MVM_STATION_COUNT)
sta_id = ap_sta_id;
} else if (iwl_mvm_is_dqa_supported(mvm) &&
- info.control.vif->type == NL80211_IFTYPE_STATION) {
+ info.control.vif->type == NL80211_IFTYPE_STATION &&
+ queue != mvm->aux_queue) {
queue = IWL_MVM_DQA_BSS_CLIENT_QUEUE;
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH v2] mac80211: prevent skb/txq mismatch
From: Michal Kazior @ 2017-01-13 12:32 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, greearb, mohammed, Michal Kazior
In-Reply-To: <1484231321-3179-1-git-send-email-michal.kazior@tieto.com>
Station structure is considered as not uploaded
(to driver) until drv_sta_state() finishes. This
call is however done after the structure is
attached to mac80211 internal lists and hashes.
This means mac80211 can lookup (and use) station
structure before it is uploaded to a driver.
If this happens (structure exists, but
sta->uploaded is false) fast_tx path can still be
taken. Deep in the fastpath call the sta->uploaded
is checked against to derive "pubsta" argument for
ieee80211_get_txq(). If sta->uploaded is false
(and sta is actually non-NULL) ieee80211_get_txq()
effectively downgraded to vif->txq.
At first glance this may look innocent but coerces
mac80211 into a state that is almost guaranteed
(codel may drop offending skb) to crash because a
station-oriented skb gets queued up on
vif-oriented txq. The ieee80211_tx_dequeue() ends
up looking at info->control.flags and tries to use
txq->sta which in the fail case is NULL.
It's probably pointless to pretend one can
downgrade skb from sta-txq to vif-txq.
Since downgrading unicast traffic to vif->txq must
not be done there's no txq to put a frame on if
sta->uploaded is false. Therefore the code is made
to fall back to regular tx() op path if the
described condition is hit.
Only drivers using wake_tx_queue were affected.
Example crash dump before fix:
Unable to handle kernel paging request at virtual address ffffe26c
PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
[<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
[<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
[<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
[<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
[<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
[<c0572e90>] (net_rx_action+0xac/0x160)
Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
Notes:
v2:
* move sta->uploaded check to if (sta) {} block [johannes]
* explain how the change fixes the bug [johannes]
net/mac80211/tx.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 4dea18be385c..2076d62207ee 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1244,7 +1244,7 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata,
static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
struct ieee80211_vif *vif,
- struct ieee80211_sta *pubsta,
+ struct sta_info *sta,
struct sk_buff *skb)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
@@ -1258,10 +1258,13 @@ static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
if (!ieee80211_is_data(hdr->frame_control))
return NULL;
- if (pubsta) {
+ if (sta) {
u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
- txq = pubsta->txq[tid];
+ if (!sta->uploaded)
+ return NULL;
+
+ txq = sta->sta.txq[tid];
} else if (vif) {
txq = vif->txq;
}
@@ -1504,23 +1507,17 @@ static bool ieee80211_queue_skb(struct ieee80211_local *local,
struct fq *fq = &local->fq;
struct ieee80211_vif *vif;
struct txq_info *txqi;
- struct ieee80211_sta *pubsta;
if (!local->ops->wake_tx_queue ||
sdata->vif.type == NL80211_IFTYPE_MONITOR)
return false;
- if (sta && sta->uploaded)
- pubsta = &sta->sta;
- else
- pubsta = NULL;
-
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
sdata = container_of(sdata->bss,
struct ieee80211_sub_if_data, u.ap);
vif = &sdata->vif;
- txqi = ieee80211_get_txq(local, vif, pubsta, skb);
+ txqi = ieee80211_get_txq(local, vif, sta, skb);
if (!txqi)
return false;
--
2.1.4
^ permalink raw reply related
* [PATCH 4.10 fix V2] Revert "bcma: init serial console directly from ChipCommon code"
From: Rafał Miłecki @ 2017-01-13 11:23 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Felix Fietkau, Rafał Miłecki
In-Reply-To: <20170112174451.7124-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
This reverts commit 4c81acab3816 ("bcma: init serial console directly
from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
bcma_core_irq helper on SoC requires MIPS core to be set. It happens
*after* ChipCommon initialization so we can't do this so early.
This fixes a user reported regression. It wasn't critical as serial was
still somehow working but lack of IRQs was making in unreliable.
Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon code")
Reported-by: Felix Fietkau <nbd@nbd.name>
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Update commit message (regression part), add Fixes & Cc. Thanks Kalle!
---
drivers/bcma/bcma_private.h | 3 +++
drivers/bcma/driver_chipcommon.c | 11 +++--------
drivers/bcma/driver_mips.c | 3 +++
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index f642c42..168fa17 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -45,6 +45,9 @@ int bcma_sprom_get(struct bcma_bus *bus);
void bcma_core_chipcommon_early_init(struct bcma_drv_cc *cc);
void bcma_core_chipcommon_init(struct bcma_drv_cc *cc);
void bcma_chipco_bcm4331_ext_pa_lines_ctl(struct bcma_drv_cc *cc, bool enable);
+#ifdef CONFIG_BCMA_DRIVER_MIPS
+void bcma_chipco_serial_init(struct bcma_drv_cc *cc);
+#endif /* CONFIG_BCMA_DRIVER_MIPS */
/* driver_chipcommon_b.c */
int bcma_core_chipcommon_b_init(struct bcma_drv_cc_b *ccb);
diff --git a/drivers/bcma/driver_chipcommon.c b/drivers/bcma/driver_chipcommon.c
index b4f6520..62f5bfa 100644
--- a/drivers/bcma/driver_chipcommon.c
+++ b/drivers/bcma/driver_chipcommon.c
@@ -15,8 +15,6 @@
#include <linux/platform_device.h>
#include <linux/bcma/bcma.h>
-static void bcma_chipco_serial_init(struct bcma_drv_cc *cc);
-
static inline u32 bcma_cc_write32_masked(struct bcma_drv_cc *cc, u16 offset,
u32 mask, u32 value)
{
@@ -186,9 +184,6 @@ void bcma_core_chipcommon_early_init(struct bcma_drv_cc *cc)
if (cc->capabilities & BCMA_CC_CAP_PMU)
bcma_pmu_early_init(cc);
- if (IS_BUILTIN(CONFIG_BCM47XX) && bus->hosttype == BCMA_HOSTTYPE_SOC)
- bcma_chipco_serial_init(cc);
-
if (bus->hosttype == BCMA_HOSTTYPE_SOC)
bcma_core_chipcommon_flash_detect(cc);
@@ -378,9 +373,9 @@ u32 bcma_chipco_gpio_pulldown(struct bcma_drv_cc *cc, u32 mask, u32 value)
return res;
}
-static void bcma_chipco_serial_init(struct bcma_drv_cc *cc)
+#ifdef CONFIG_BCMA_DRIVER_MIPS
+void bcma_chipco_serial_init(struct bcma_drv_cc *cc)
{
-#if IS_BUILTIN(CONFIG_BCM47XX)
unsigned int irq;
u32 baud_base;
u32 i;
@@ -422,5 +417,5 @@ static void bcma_chipco_serial_init(struct bcma_drv_cc *cc)
ports[i].baud_base = baud_base;
ports[i].reg_shift = 0;
}
-#endif /* CONFIG_BCM47XX */
}
+#endif /* CONFIG_BCMA_DRIVER_MIPS */
diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index 96f1713..89af807 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -278,9 +278,12 @@ static void bcma_core_mips_nvram_init(struct bcma_drv_mips *mcore)
void bcma_core_mips_early_init(struct bcma_drv_mips *mcore)
{
+ struct bcma_bus *bus = mcore->core->bus;
+
if (mcore->early_setup_done)
return;
+ bcma_chipco_serial_init(&bus->drv_cc);
bcma_core_mips_nvram_init(mcore);
mcore->early_setup_done = true;
--
2.10.1
^ permalink raw reply related
* [PATCH] ath10k: Search SMBIOS for OEM board file extension
From: Waldemar Rymarkiewicz @ 2017-01-13 11:10 UTC (permalink / raw)
To: kvalo, ath10k
Cc: bartosz.markowski, rwchang, alanliu, linux-wireless,
Waldemar Rymarkiewicz
Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified, among others, by device and sybsystem ids.
The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.
To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
Extension to specify the extension/variant name. The driver will take the
extension suffix into consideration and will load the right (non-default)
board data file if necessary.
If it is unnecessary to use extension board data file, please leave the
SMBIOS field blank and default configuration will be used.
Example:
If a default board data file for a specific board is identified by a string
"bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
subsystem-device=0310"
then the OEM specific data file, if used, could be identified by variant
suffix:
"bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
subsystem-device=0310,variant=DE_1AB"
Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.c | 79 ++++++++++++++++++++++++++++++++--
drivers/net/wireless/ath/ath10k/core.h | 19 ++++++++
2 files changed, 95 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 874c2a755c66..e6276027ec83 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -18,6 +18,8 @@
#include <linux/module.h>
#include <linux/firmware.h>
#include <linux/of.h>
+#include <linux/dmi.h>
+#include <linux/ctype.h>
#include <asm/byteorder.h>
#include "core.h"
@@ -707,6 +709,67 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
return 0;
}
+static void ath10k_core_check_bdfext(const struct dmi_header *hdr, void *data)
+{
+ struct ath10k *ar = data;
+ const char *bdf_ext;
+ const char *magic = ATH10K_SMBIOS_BDF_EXT_MAGIC;
+ u8 bdf_enabled;
+ int i;
+
+ if (hdr->type != ATH10K_SMBIOS_BDF_EXT_TYPE)
+ return;
+
+ if (hdr->length != ATH10K_SMBIOS_BDF_EXT_LENGTH) {
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "wrong smbios bdf ext type length (%d).\n",
+ hdr->length);
+ return;
+ }
+
+ bdf_enabled = *((u8 *)hdr + ATH10K_SMBIOS_BDF_EXT_OFFSET);
+ if (!bdf_enabled) {
+ ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not found.\n");
+ return;
+ }
+
+ /* Only one string exists (per spec) */
+ bdf_ext = (char *)hdr + hdr->length;
+
+ if (memcmp(bdf_ext, magic, strlen(magic)) != 0) {
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "bdf variant magic does not match.\n");
+ return;
+ }
+
+ for (i = 0; i < strlen(bdf_ext); i++) {
+ if (!isascii(bdf_ext[i]) || !isprint(bdf_ext[i])) {
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "bdf variant name contains non ascii chars.\n");
+ return;
+ }
+ }
+
+ /* Copy extension name without magic suffix */
+ strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
+ sizeof(ar->id.bdf_ext));
+
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "found and validated bdf variant smbios_type 0x%x bdf %s\n",
+ ATH10K_SMBIOS_BDF_EXT_TYPE, bdf_ext);
+}
+
+static int ath10k_core_check_smbios(struct ath10k *ar)
+{
+ ar->id.bdf_ext[0] = '\0';
+ dmi_walk(ath10k_core_check_bdfext, ar);
+
+ if (ar->id.bdf_ext[0] == '\0')
+ return -ENODATA;
+
+ return 0;
+}
+
static int ath10k_download_and_run_otp(struct ath10k *ar)
{
u32 result, address = ar->hw_params.patch_load_addr;
@@ -1053,6 +1116,9 @@ static int ath10k_core_fetch_board_data_api_n(struct ath10k *ar,
static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
size_t name_len)
{
+ /* strlen(',variant=') + strlen(ar->id.bdf_ext) */
+ char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH];
+
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
"bus=%s,bmi-chip-id=%d,bmi-board-id=%d",
@@ -1062,12 +1128,15 @@ static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
goto out;
}
+ if (ar->id.bdf_ext[0] != '\0')
+ scnprintf(variant, sizeof(variant), ",variant=%s",
+ ar->id.bdf_ext);
+
scnprintf(name, name_len,
- "bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x",
+ "bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s",
ath10k_bus_str(ar->hif.bus),
ar->id.vendor, ar->id.device,
- ar->id.subsystem_vendor, ar->id.subsystem_device);
-
+ ar->id.subsystem_vendor, ar->id.subsystem_device, variant);
out:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using board name '%s'\n", name);
@@ -2128,6 +2197,10 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
goto err_free_firmware_files;
}
+ ret = ath10k_core_check_smbios(ar);
+ if (ret)
+ ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not set.\n");
+
ret = ath10k_core_fetch_board_file(ar);
if (ret) {
ath10k_err(ar, "failed to fetch board file: %d\n", ret);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index c7664d6569fa..c7a289a4819d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -69,6 +69,23 @@
#define ATH10K_NAPI_BUDGET 64
#define ATH10K_NAPI_QUOTA_LIMIT 60
+/* SMBIOS type containing Board Data File Name Extension */
+#define ATH10K_SMBIOS_BDF_EXT_TYPE 0xF8
+
+/* SMBIOS type structure length (excluding strings-set) */
+#define ATH10K_SMBIOS_BDF_EXT_LENGTH 0x9
+
+/* Offset pointing to Board Data File Name Extension */
+#define ATH10K_SMBIOS_BDF_EXT_OFFSET 0x8
+
+/* Board Data File Name Extension string length.
+ * String format: BDF_<Customer ID>_<Extension>\0
+ */
+#define ATH10K_SMBIOS_BDF_EXT_STR_LENGTH 0x20
+
+/* The magic used by QCA spec */
+#define ATH10K_SMBIOS_BDF_EXT_MAGIC "BDF_"
+
struct ath10k;
enum ath10k_bus {
@@ -781,6 +798,8 @@ struct ath10k {
bool bmi_ids_valid;
u8 bmi_board_id;
u8 bmi_chip_id;
+
+ char bdf_ext[ATH10K_SMBIOS_BDF_EXT_STR_LENGTH];
} id;
int fw_api;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Johannes Berg @ 2017-01-13 10:13 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, Ben Greear, Mohammed Shafi Shajakhan
In-Reply-To: <CA+BoTQnA4X+OPC2eFQO9tj+a+-z=_FTKA6UR_uJAUrQvzjZZ8Q@mail.gmail.com>
> > What I don't understand - and you haven't really described - is how
> > the changes fix it? Could you resend with a paragraph added that
> > explains that?
>
> "Since downgrading unicast traffic to vif->txq must not be done
> there's no txq to put a frame on if sta->uploaded is false. Therefore
> the code is made to fall back to regular tx() op path if the
> described condition is hit. " -- is this sufficient?
Makes sense.
> > Also, you're adding a test:
> >
> > > if (sta && !sta->uploaded)
> >
> > but couldn't do move that into the existing "if (sta)" block?
> > Everything before that only ever returns NULL anyway.
>
> Good point. It makes more sense to put the sta->uploaded check in if
> (sta) block. I'll move it.
>
Ok, thanks.
johannes
^ permalink raw reply
* Re: [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org
From: Kalle Valo @ 2017-01-13 10:46 UTC (permalink / raw)
To: Daniel Golle
Cc: linux-wireless, lede-dev, openwrt-devel, john, nbd, roman,
evaxige, c.mignanti, michel.stempin, vasilugin, Stanislaw Gruszka,
Helmut Schaa
In-Reply-To: <20170113035020.GA9063@makrotopia.org>
Daniel Golle <daniel@makrotopia.org> writes:
> In preparation to be submitted upstream I started to clean up a huge
> pile of patches for rt2x00 we have been carrying along for quite a
> while (some for more than half a decade!).
> Some of them are fixes, most importantly Serge Vasilugin fixed setting
> the HT20/HT40 filter which got us much closer to the expected
> performance when using HT40 modes.
>
> And also a lot of new added hardware support:
> Gabor Juhos wrote code for Rt3883 WiSoC.
> Daniel Golle implemented support for Rt3352 by designs with external PA
> as well as for boards using a 20MHz crystal instead of the usual 40MHz.
> Serge Vasilugin contributed support for the Rt5350 WiSoC.
> Michel Stempin, Felix Fietkau and John Crispin have been helping with
> cleaning up things and putting away legal doubts.
>
> Please review and comment, so we can get those patches merged!
No pull requests, please. Instead send these as patches, easier to
review and actually also easier for me to merge.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Revert "bcma: init serial console directly from ChipCommon code"
From: Kalle Valo @ 2017-01-13 10:42 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless@vger.kernel.org, Felix Fietkau,
Rafał Miłecki
In-Reply-To: <CACna6rwupQ68meKJNRLcHdXEg+sQXvP5mH-C4fqofNQg0Y2hTQ@mail.gmail.com>
Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
> On 13 January 2017 at 11:16, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
>>
>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>
>>> This reverts commit 4c81acab3816 ("bcma: init serial console directly
>>> from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
>>> bcma_core_irq helper on SoC requires MIPS core to be set. It happens
>>> *after* ChipCommon initialization so we can't do this so early.
>>>
>>> This fixes a regression but it seems noone noticed it for about a year.
>>> It could be it was because serial was still somehow working, just
>>> without IRQs. It doesn't look like a critical patch / fix.
>>>
>>> Reported-by: Felix Fietkau <nbd@nbd.name>
>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>
>> So this is for 4.11? What about CC stable?
>>
>> I'll add a Fixes line:
>>
>> Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon=
code")
>
> After hearing about policy for fixes getting more strict, I thought we
> can get it for next only.
As this is a user reported regression it would qualify for 4.10, but on
the other hand quite old regression so can easily wait for 4.11 as well.
Up to you really.
But I would like to add CC stable so that this gets backported to older
releases. Is that ok?
> Thanks for "Fixes:", I wasn't sure if we need that for reverts.
If you are fixing a regression it's always a good idea to add the Fixes
line. Makes it easier to backport the fix.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] mac80211: initialize SMPS field in HT capabilities
From: Johannes Berg @ 2017-01-13 10:32 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: onelektra
In-Reply-To: <20170113102825.72047-1-nbd@nbd.name>
On Fri, 2017-01-13 at 11:28 +0100, Felix Fietkau wrote:
> ibss and mesh modes copy the ht capabilites from the band without
> overriding the SMPS state. Unfortunately the default value 0 for the
> SMPS field means static SMPS instead of disabled.
>
> This results in HT ibss and mesh setups using only single-stream
> rates,
> even though SMPS is not supposed to be active.
>
> Initialize SMPS to disabled for all bands on ieee80211_hw_register to
> ensure that the value is sane where it is not overriden with the real
> SMPS state.
>
> Reported-by: Elektra Wagenrad <onelektra@gmx.net>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> v2: add comment about OR'ing the PS_DISABLED value
Applied, thanks.
I moved the TODO comment there around a bit.
johannes
^ permalink raw reply
* [PATCH] ath10k: Fix per station tx bit rate reporting
From: Mohammed Shafi Shajakhan @ 2017-01-13 10:30 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Not clearing the previous tx bit rate status
results in a ambigous tx bit rate reporting to
mac80211/cfg80211, for example the previous bit
rate status would have been marked as legacy rate
, while the current rate would have been an HT/VHT
rate with the tx bit rate flags set and this results
in exporting tx bitrate as legacy rate but with HT/VHT
rate flags set, fix this by clearing the tx bitrate
status for each event. This also fixes the below
warning when we do:
iw dev wlan#N station dump
WARNING: net/wireless/util.c:1222 cfg80211
[<c022f104>] (warn_slowpath_null) from [<bf3b9adc>]
(cfg80211_calculate_bitrate+0x110/0x1f4 [cfg80211])
[<bf3b9adc>] (cfg80211_calculate_bitrate [cfg80211]) from
[<bf3dcd54>] (nl80211_put_sta_rate+0x44/0x1dc [cfg80211])
[<bf3dcd54>] (nl80211_put_sta_rate [cfg80211]) from
[<bf3cbc34>] (nl80211_set_interface+0x724/0xd70 [cfg80211])
[<bf3cbc34>] (nl80211_set_interface [cfg80211]) from
[<bf3d0a18>] (nl80211_dump_station+0xdc/0x100 [cfg80211])
[<bf3d0a18>] (nl80211_dump_station [cfg80211])
Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0bc7fe8..74b66e5 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2231,6 +2231,8 @@ static inline bool is_valid_legacy_rate(u8 rate)
return;
}
+ memset(&arsta->txrate, 0, sizeof(arsta->txrate));
+
if (txrate.flags == WMI_RATE_PREAMBLE_CCK ||
txrate.flags == WMI_RATE_PREAMBLE_OFDM) {
rate = ATH10K_HW_LEGACY_RATE(peer_stats->ratecode);
--
1.9.1
^ permalink raw reply related
* pull-request: mac80211-next 2017-01-13
From: Johannes Berg @ 2017-01-13 10:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
This is my first pull request for net-next, and it seems a bit
bigger than the past few releases. Detailed information below,
as usual.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 8fa3b6f9392bf6d90cb7b908e07bd90166639f0a:
Merge tag 'cris-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris (2016-12-12 09:06:38 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2017-01-13
for you to fetch changes up to c88215d7050f065afaed33e9599c2ef4e5e6ee22:
cfg80211: Fix documentation for connect result (2017-01-13 09:47:08 +0100)
----------------------------------------------------------------
For 4.11, we seem to have more than in the past few releases:
* socket owner support for connections, so when the wifi
manager (e.g. wpa_supplicant) is killed, connections are
torn down - wpa_supplicant is critical to managing certain
operations, and can opt in to this where applicable
* minstrel & minstrel_ht updates to be more efficient (time and space)
* set wifi_acked/wifi_acked_valid for skb->destructor use in the
kernel, which was already available to userspace
* don't indicate new mesh peers that might be used if there's no
room to add them
* multicast-to-unicast support in mac80211, for better medium usage
(since unicast frames can use *much* higher rates, by ~3 orders of
magnitude)
* add API to read channel (frequency) limitations from DT
* add infrastructure to allow randomizing public action frames for
MAC address privacy (still requires driver support)
* many cleanups and small improvements/fixes across the board
----------------------------------------------------------------
Andrzej Zaborowski (1):
cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
Arend Van Spriel (5):
cfg80211: get rid of name indirection trick for ieee80211_get_channel()
nl80211: check NL80211_ATTR_SCHED_SCAN_INTERVAL only once
nl80211: rework {sched_,}scan event related functions
nl80211: better describe field in struct nl80211_bss_select_rssi_adjust
cfg80211: only pass sband to set_mandatory_flags_band()
Arnd Bergmann (2):
rfkill: hide unused goto label
wext: handle NULL extra data in iwe_stream_add_point better
Ben Greear (1):
mac80211: Show pending txqlen in debugfs.
David Spinadel (1):
mac80211: Add RX flag to indicate ICV stripped
Felix Fietkau (9):
mac80211: minstrel_ht: move supported bitrate mask out of group data
mac80211: minstrel_ht: move short preamble check out of get_rate
mac80211: minstrel_ht: make att_hist and succ_hist u32 instead of u64
mac80211: check for MCS in ieee80211_duration before fetching chanctx
mac80211: minstrel: remove cur_prob from debugfs
mac80211: minstrel: reduce MINSTREL_SCALE
mac80211: minstrel: store probability variance instead of standard deviation
mac80211: minstrel: make prob_ewma u16 instead of u32
mac80211: minstrel_ht: remove obsolete #if for >= 3 streams
Ilan peer (1):
mac80211: Fix addition of mesh configuration element
Johannes Berg (7):
rfkill: simplify rfkill_set_hw_state() slightly
Revert "rfkill: Add rfkill-any LED trigger"
cfg80211: sysfs: use wiphy_name()
wireless: move IEEE80211_NUM_ACS to ieee80211.h
cfg80211: size various nl80211 messages correctly
mac80211: set wifi_acked[_valid] bits for transmitted SKBs
wext: uninline stream addition functions
Jorge Ramirez-Ortiz (1):
cfg80211: wext does not need to set monitor channel in managed mode
Jouni Malinen (1):
cfg80211: Fix documentation for connect result
Kirtika Ruchandani (7):
mac80211: Remove unused 'struct ieee80211_rx_status' ptr
mac80211: Remove unused 'rates_idx' variable
mac80211: Remove unused 'struct rate_control_ref' variable
mac80211: Remove unused 'i' variable
mac80211: Remove unused 'len' variable
mac80211: Remove unused 'sband' and 'local' variables
mac80211: Remove unused 'beaconint_us' variable
Koen Vandeputte (1):
mac80211: only alloc mem if a station doesn't exist yet
Masashi Honma (3):
mac80211: Suppress NEW_PEER_CANDIDATE event if no room
mac80211: Remove invalid flag operations in mesh TSF synchronization
mac80211: Use appropriate name for functions and messages
Michael Braun (2):
nl80211: multicast_to_unicast can be changed while IFF_UP
mac80211: multicast to unicast conversion
Michał Kępień (3):
rfkill: Cleanup error handling in rfkill_init()
rfkill: Add rfkill-any LED trigger
rfkill: Add rfkill-any LED trigger
Purushottam Kushwaha (1):
cfg80211: Specify the reason for connect timeout
Rafał Miłecki (5):
cfg80211: update wireless-regdb repo url in Documentation
cfg80211: fix example REG_RULE usage in Documentation
dt-bindings: document common IEEE 802.11 frequency limit property
cfg80211: move function checking range fit to util.c
cfg80211: support ieee80211-freq-limit DT property
Thomas Huehn (1):
mac80211: minstrel: avoid port control frames for sampling
vamsi krishna (2):
cfg80211: Add support for randomizing TA of Public Action frames
cfg80211: Add support to sched scan to report better BSSs
Documentation/80211/cfg80211.rst | 3 +
.../devicetree/bindings/net/wireless/ieee80211.txt | 24 ++++
Documentation/networking/regulatory.txt | 8 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 3 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
include/linux/ieee80211.h | 2 +
include/net/cfg80211.h | 135 ++++++++++++++------
include/net/iw_handler.h | 66 ++--------
include/net/mac80211.h | 6 +-
include/uapi/linux/nl80211.h | 64 +++++++++-
net/mac80211/cfg.c | 12 ++
net/mac80211/chan.c | 4 +-
net/mac80211/debugfs.c | 27 ++++
net/mac80211/debugfs_netdev.c | 3 +
net/mac80211/ieee80211_i.h | 6 +-
net/mac80211/mesh.c | 7 +-
net/mac80211/mesh.h | 2 +-
net/mac80211/mesh_plink.c | 14 ++-
net/mac80211/mesh_sync.c | 27 ++--
net/mac80211/mlme.c | 4 -
net/mac80211/rc80211_minstrel.c | 21 ++--
net/mac80211/rc80211_minstrel.h | 33 ++---
net/mac80211/rc80211_minstrel_debugfs.c | 24 ++--
net/mac80211/rc80211_minstrel_ht.c | 68 +++-------
net/mac80211/rc80211_minstrel_ht.h | 6 +-
net/mac80211/rc80211_minstrel_ht_debugfs.c | 32 ++---
net/mac80211/rx.c | 4 -
net/mac80211/scan.c | 8 +-
net/mac80211/sta_info.c | 18 ++-
net/mac80211/status.c | 8 +-
net/mac80211/tx.c | 132 +++++++++++++++++++-
net/mac80211/vht.c | 4 -
net/mac80211/wep.c | 3 +-
net/mac80211/wpa.c | 3 +-
net/rfkill/core.c | 100 ++++++++++++---
net/wireless/Makefile | 1 +
net/wireless/core.c | 3 +
net/wireless/core.h | 8 +-
net/wireless/mlme.c | 29 ++++-
net/wireless/nl80211.c | 137 +++++++++++++-------
net/wireless/nl80211.h | 10 +-
net/wireless/of.c | 138 +++++++++++++++++++++
net/wireless/reg.c | 27 ++--
net/wireless/scan.c | 9 +-
net/wireless/sme.c | 72 +++++++++--
net/wireless/sysfs.c | 6 +-
net/wireless/util.c | 30 +++--
net/wireless/wext-core.c | 67 ++++++++++
net/wireless/wext-sme.c | 23 ----
49 files changed, 1016 insertions(+), 427 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
create mode 100644 net/wireless/of.c
^ permalink raw reply
* Re: Searching new home for ath[59]k-devel mailing lists
From: Kalle Valo @ 2017-01-13 10:28 UTC (permalink / raw)
To: Michael Renzmann; +Cc: linux-wireless, ath5k-devel, ath9k-devel
In-Reply-To: <49328.217.24.3.26.1483895726.squirrel@webmail.madwifi-project.org>
"Michael Renzmann" <mrenzmann@madwifi-project.org> writes:
> Out of history, the ath5k-devel and ath9k-devel mailing lists have been
> and still are hosted on the mailing list server of the MadWifi project. I
> intend to shut the server down, and thus I'm searching a new loving home
> for the lists.
>
> Besides a new home the lists also need some attention - both would receive
> a fair amount of spam, and thus they need someone who takes care of some
> kind of moderating posts and/or filtering spam.
>
> To be honest, I've not been following things at all for many months. From
> what I can tell it seems that ath5k-devel is pretty quiet. ath9k-devel,
> however, still sees a fair amount of communication; but I didn't look at
> how much of that traffic actually took place here on linux-wireless, just
> CC'ing ath9k-devel.
> This is to say, if there is a broad agreement that one of the lists or
> both of them are no longer required, I'm fine with just closing them in an
> ordered fashion.
I really don't see any need for ath5k-devel, according to git log there
has been five patches for ath5k during the past year.
ath9k is of course a lot more active, 99 patches over the last year. But
still I get the feeling that we don't really need an ath9k specific
mailing list, discussion via linux-wireless should work. And if there
ever comes up a demand to have a dedicated list for ath9k we can then
try find a new one, for example from infradead.org.
So feel free to close both of the lists and thanks for the heads up. Are
you planning to update the MAINTAINERS file or should I?
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] mac80211: initialize SMPS field in HT capabilities
From: Felix Fietkau @ 2017-01-13 10:28 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, onelektra
ibss and mesh modes copy the ht capabilites from the band without
overriding the SMPS state. Unfortunately the default value 0 for the
SMPS field means static SMPS instead of disabled.
This results in HT ibss and mesh setups using only single-stream rates,
even though SMPS is not supposed to be active.
Initialize SMPS to disabled for all bands on ieee80211_hw_register to
ensure that the value is sane where it is not overriden with the real
SMPS state.
Reported-by: Elektra Wagenrad <onelektra@gmx.net>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
v2: add comment about OR'ing the PS_DISABLED value
net/mac80211/main.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 1822c77f2b1c..d253ce71d472 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -913,10 +913,16 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
supp_ht = supp_ht || sband->ht_cap.ht_supported;
supp_vht = supp_vht || sband->vht_cap.vht_supported;
- if (sband->ht_cap.ht_supported)
- local->rx_chains =
- max(ieee80211_mcs_to_chains(&sband->ht_cap.mcs),
- local->rx_chains);
+ if (!sband->ht_cap.ht_supported)
+ continue;
+
+ local->rx_chains =
+ max(ieee80211_mcs_to_chains(&sband->ht_cap.mcs),
+ local->rx_chains);
+
+ /* no need to mask, SM_PS_DISABLED has all bits set */
+ sband->ht_cap.cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
+ IEEE80211_HT_CAP_SM_PS_SHIFT;
/* TODO: consider VHT for RX chains, hopefully it's the same */
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] Revert "bcma: init serial console directly from ChipCommon code"
From: Kalle Valo @ 2017-01-13 10:16 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, linux-wireless, Felix Fietkau,
Rafał Miłecki
In-Reply-To: <20170112174451.7124-1-zajec5@gmail.com>
Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> This reverts commit 4c81acab3816 ("bcma: init serial console directly
> from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
> bcma_core_irq helper on SoC requires MIPS core to be set. It happens
> *after* ChipCommon initialization so we can't do this so early.
>
> This fixes a regression but it seems noone noticed it for about a year.
> It could be it was because serial was still somehow working, just
> without IRQs. It doesn't look like a critical patch / fix.
>
> Reported-by: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
So this is for 4.11? What about CC stable?
I'll add a Fixes line:
Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon co=
de")
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Revert "bcma: init serial console directly from ChipCommon code"
From: Rafał Miłecki @ 2017-01-13 10:23 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Felix Fietkau,
Rafał Miłecki
In-Reply-To: <87fuknl0x9.fsf@codeaurora.org>
On 13 January 2017 at 11:16, Kalle Valo <kvalo@codeaurora.org> wrote:
> Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
>
>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>
>> This reverts commit 4c81acab3816 ("bcma: init serial console directly
>> from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
>> bcma_core_irq helper on SoC requires MIPS core to be set. It happens
>> *after* ChipCommon initialization so we can't do this so early.
>>
>> This fixes a regression but it seems noone noticed it for about a year.
>> It could be it was because serial was still somehow working, just
>> without IRQs. It doesn't look like a critical patch / fix.
>>
>> Reported-by: Felix Fietkau <nbd@nbd.name>
>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> So this is for 4.11? What about CC stable?
>
> I'll add a Fixes line:
>
> Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon =
code")
After hearing about policy for fixes getting more strict, I thought we
can get it for next only.
Thanks for "Fixes:", I wasn't sure if we need that for reverts.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH] mac80211: initialize SMPS field in HT capabilities
From: Johannes Berg @ 2017-01-13 10:20 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: onelektra
In-Reply-To: <ba04d61c-3f80-573f-3108-c94a9c991404@nbd.name>
On Fri, 2017-01-13 at 09:54 +0100, Felix Fietkau wrote:
> > Additionally, ath10k appears to be setting this to
> > WLAN_HT_CAP_SM_PS_DYNAMIC already, so apparently it's expecting
> > something to happen with that value? Is it really correct then to
> > be overwriting it?
>
> Actually, that code seems to leave the value at
> WLAN_HT_CAP_SM_PS_DISABLED, because it sets that first and doesn't
> mask out the field before trying to set it to
> WLAN_HT_CAP_SM_PS_DYNAMIC.
Hah, that's funny.
> I don't think it even makes sense to set WLAN_HT_CAP_SM_PS_DYNAMIC at
> this point, since it's up to mac80211 to deal with the SMPS state.
>
> Either way, WLAN_HT_CAP_SM_PS_STATIC is a really bad default to have
> at init time. If you want, I can change the patch to check for that
> value before changing it, but I don't really see the point.
No, I think I agree. But please add a comment that OR'ing in the two
bits will not result in it having strange values - it's a bit
unexpected to see this here and then one has to remember (or look up)
the value of DISABLED to understand the code is fine.
> Additionally, I found this ath10k commit:
>
>
> commit e33a99e227e430a788467e5a85dc29f6df16b983
> Author: Peter Oh <poh@qca.qualcomm.com>
> Date: Thu Dec 31 15:26:20 2015 +0200
>
> ath10k: set SM power save disabled to default value
>
> Use SMPS disabled as default because FW does not indicate
> any support of SMPS.
>
> This change will help STAs out that don’t support SMPS from
> sticking on 1SS, since they don’t have method to change it
> back to multiple chains.
>
> This change also should not affect power consumption of STAs
> supporting SMPS, because they are capable to switch the mode
> to dynamic or static either at the end of frame sequence or
> by using SMPS action frame.
Fun. Though I'd argue that this whole thing should then just be removed
from ath10k.
johannes
^ permalink raw reply
* [PATCH] mac80211: fix documentation warnings
From: Johannes Berg @ 2017-01-13 10:12 UTC (permalink / raw)
To: linux-wireless; +Cc: corbet, linux-doc, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
For a few restructured text warnings in mac80211, making the
documentation warning-free (for now). Again, this required
adding trailing whitespace to keep multiple paragraphs in a
parameter description together.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 86967b85dfd0..228c72617916 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1771,10 +1771,12 @@ struct ieee80211_sta_rates {
* @max_amsdu_len: indicates the maximal length of an A-MSDU in bytes. This
* field is always valid for packets with a VHT preamble. For packets
* with a HT preamble, additional limits apply:
- * + If the skb is transmitted as part of a BA agreement, the
- * A-MSDU maximal size is min(max_amsdu_len, 4065) bytes.
- * + If the skb is not part of a BA aggreement, the A-MSDU maximal
- * size is min(max_amsdu_len, 7935) bytes.
+ *
+ * * If the skb is transmitted as part of a BA agreement, the
+ * A-MSDU maximal size is min(max_amsdu_len, 4065) bytes.
+ * * If the skb is not part of a BA aggreement, the A-MSDU maximal
+ * size is min(max_amsdu_len, 7935) bytes.
+ *
* Both additional HT limits must be enforced by the low level driver.
* This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
* @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
@@ -3212,14 +3214,20 @@ enum ieee80211_reconfig_type {
* nor send aggregates in a way that lost frames would exceed the
* buffer size. If just limiting the aggregate size, this would be
* possible with a buf_size of 8:
- * - TX: 1.....7
- * - RX: 2....7 (lost frame #1)
- * - TX: 8..1...
+ *
+ * - ``TX: 1.....7``
+ * - ``RX: 2....7`` (lost frame #1)
+ * - ``TX: 8..1...``
+ *
* which is invalid since #1 was now re-transmitted well past the
* buffer size of 8. Correct ways to retransmit #1 would be:
- * - TX: 1 or 18 or 81
- * Even "189" would be wrong since 1 could be lost again.
- *
+ *
+ * - ``TX: 1 or``
+ * - ``TX: 18 or``
+ * - ``TX: 81``
+ *
+ * Even ``189`` would be wrong since 1 could be lost again.
+ *
* Returns a negative error code on failure.
* The callback can sleep.
*
--
2.9.3
^ permalink raw reply related
* Re: [6/9] rt2800: fallback from mcs8 to mcs7
From: Kalle Valo @ 2017-01-13 10:11 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-7-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> If we do not fallback to lower rate, we are unable to calculate
> correctly number of retries in TX status code.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Dropping per Stanislaw's request
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9500913/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 6/9] rt2800: fallback from mcs8 to mcs7
From: Stanislaw Gruszka @ 2017-01-13 9:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin, Kalle Valo
In-Reply-To: <e3c3f693-3d34-ecfc-de13-855c1d75b849@nbd.name>
On Thu, Jan 12, 2017 at 12:10:48PM +0100, Felix Fietkau wrote:
> On 2017-01-06 14:05, Stanislaw Gruszka wrote:
> > If we do not fallback to lower rate, we are unable to calculate
> > correctly number of retries in TX status code.
> >
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> I think falling back from the lowest dual-stream to the highest
> single-stream rate is a really bad idea.
Ok, Kalle please drop this patch.
> Instead you should get rid of the assumption that fallback rates are
> ordered by their MCS index.
I think I will stay with the current code. With decreased retry
limit setting in other patch, problem is mitigated. For newer
chips there is retry count TX_STA_FIFO_EXT register, so I'll look
into that.
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Michal Kazior @ 2017-01-13 9:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Ben Greear, Mohammed Shafi Shajakhan
In-Reply-To: <1484295383.19860.7.camel@sipsolutions.net>
On 13 January 2017 at 09:16, Johannes Berg <johannes@sipsolutions.net> wrot=
e:
> On Thu, 2017-01-12 at 15:28 +0100, Michal Kazior wrote:
>> Station structure is considered as not uploaded
>> (to driver) until drv_sta_state() finishes. This
>> call is however done after the structure is
>> attached to mac80211 internal lists and hashes.
>> This means mac80211 can lookup (and use) station
>> structure before it is uploaded to a driver.
>>
>> If this happens (structure exists, but
>> sta->uploaded is false) fast_tx path can still be
>> taken. Deep in the fastpath call the sta->uploaded
>> is checked against to derive "pubsta" argument for
>> ieee80211_get_txq(). If sta->uploaded is false
>> (and sta is actually non-NULL) ieee80211_get_txq()
>> effectively downgraded to vif->txq.
>>
>> At first glance this may look innocent but coerces
>> mac80211 into a state that is almost guaranteed
>> (codel may drop offending skb) to crash because a
>> station-oriented skb gets queued up on
>> vif-oriented txq. The ieee80211_tx_dequeue() ends
>> up looking at info->control.flags and tries to use
>> txq->sta which in the fail case is NULL.
>>
>> It's probably pointless to pretend one can
>> downgrade skb from sta-txq to vif-txq.
>
> Ok. I understand things until this point, more or less.
>
> What I don't understand - and you haven't really described - is how the
> changes fix it? Could you resend with a paragraph added that explains
> that?
"Since downgrading unicast traffic to vif->txq must not be done
there's no txq to put a frame on if sta->uploaded is false. Therefore
the code is made to fall back to regular tx() op path if the described
condition is hit. " -- is this sufficient?
> Also, you're adding a test:
>
>> if (sta && !sta->uploaded)
>
> but couldn't do move that into the existing "if (sta)" block?
> Everything before that only ever returns NULL anyway.
Good point. It makes more sense to put the sta->uploaded check in if
(sta) block. I'll move it.
Micha=C5=82
^ 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