* [PATCH v4] ath10k: create debugfs interface to trigger fw crash
From: Michal Kazior @ 2013-07-22 12:08 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <878v1122id.fsf@kamboji.qca.qualcomm.com>
This can be useful for testing. To perform a
forced firmware crash write 'crash' to
'simulate_fw_crash' debugfs file. E.g.
echo crash > /sys/kernel/debug/ieee80211/phy1/ath10k/simulate_fw_crash
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
v3: return an appropriate errno instead of using ath10k_warn()
drivers/net/wireless/ath/ath10k/debug.c | 57 +++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 65279f5..3d65594 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -445,6 +445,60 @@ static const struct file_operations fops_fw_stats = {
.llseek = default_llseek,
};
+static ssize_t ath10k_read_simulate_fw_crash(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ const char buf[] = "To simulate firmware crash write the keyword"
+ " `crash` to this file.\nThis will force firmware"
+ " to report a crash to the host system.\n";
+ return simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));
+}
+
+static ssize_t ath10k_write_simulate_fw_crash(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ char buf[32] = {};
+ int ret;
+
+ mutex_lock(&ar->conf_mutex);
+
+ simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count);
+ if (strcmp(buf, "crash") && strcmp(buf, "crash\n")) {
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ if (ar->state != ATH10K_STATE_ON &&
+ ar->state != ATH10K_STATE_RESTARTED) {
+ ret = -ENETDOWN;
+ goto exit;
+ }
+
+ ath10k_info("simulating firmware crash\n");
+
+ ret = ath10k_wmi_force_fw_hang(ar, WMI_FORCE_FW_HANG_ASSERT, 0);
+ if (ret)
+ ath10k_warn("failed to force fw hang (%d)\n", ret);
+
+ if (ret == 0)
+ ret = count;
+
+exit:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
+static const struct file_operations fops_simulate_fw_crash = {
+ .read = ath10k_read_simulate_fw_crash,
+ .write = ath10k_write_simulate_fw_crash,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
int ath10k_debug_create(struct ath10k *ar)
{
ar->debug.debugfs_phy = debugfs_create_dir("ath10k",
@@ -461,6 +515,9 @@ int ath10k_debug_create(struct ath10k *ar)
debugfs_create_file("wmi_services", S_IRUSR, ar->debug.debugfs_phy, ar,
&fops_wmi_services);
+ debugfs_create_file("simulate_fw_crash", S_IRUSR, ar->debug.debugfs_phy,
+ ar, &fops_simulate_fw_crash);
+
return 0;
}
#endif /* CONFIG_ATH10K_DEBUGFS */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/4] ath10k: fixes
From: Michal Kazior @ 2013-07-22 12:13 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374129193-3533-1-git-send-email-michal.kazior@tieto.com>
Hi,
Here are some fixes for ath10k. The rts threshold
patch addresses my mistake in commit
9aeb6fe53d1f0d6e58658484ce9ad7b59f0ef16b which
caused rts to be always enabled causing throughput
issues in some cases.
v2: first patch is split now into two as requested
rebased on top of latest github master branch
Michal Kazior (4):
ath10k: prevent HTC from being used after stopping
ath10k: don't reset HTC endpoints unnecessarily
ath10k: fix memleak in mac setup
ath10k: fix rts/fragmentation threshold setup
drivers/net/wireless/ath/ath10k/htc.c | 28 ++++++------
drivers/net/wireless/ath/ath10k/htc.h | 4 +-
drivers/net/wireless/ath/ath10k/mac.c | 80 ++++++++++++++++++---------------
3 files changed, 58 insertions(+), 54 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/4] ath10k: prevent HTC from being used after stopping
From: Michal Kazior @ 2013-07-22 12:13 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374495211-20353-1-git-send-email-michal.kazior@tieto.com>
It was possible to submit new HTC commands
after/while HTC stopped. This led to memory
corruption in some rare cases.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 27 +++++++++++++--------------
drivers/net/wireless/ath/ath10k/htc.h | 4 ++--
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 72e072c..47b7752 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -254,10 +254,14 @@ int ath10k_htc_send(struct ath10k_htc *htc,
return -ENOENT;
}
- skb_push(skb, sizeof(struct ath10k_htc_hdr));
-
spin_lock_bh(&htc->tx_lock);
+ if (htc->stopped) {
+ spin_unlock_bh(&htc->tx_lock);
+ return -ESHUTDOWN;
+ }
+
__skb_queue_tail(&ep->tx_queue, skb);
+ skb_push(skb, sizeof(struct ath10k_htc_hdr));
spin_unlock_bh(&htc->tx_lock);
queue_work(htc->ar->workqueue, &ep->send_work);
@@ -270,23 +274,17 @@ static int ath10k_htc_tx_completion_handler(struct ath10k *ar,
{
struct ath10k_htc *htc = &ar->htc;
struct ath10k_htc_ep *ep = &htc->endpoint[eid];
- bool stopping;
ath10k_htc_notify_tx_completion(ep, skb);
/* the skb now belongs to the completion handler */
+ /* note: when using TX credit flow, the re-checking of queues happens
+ * when credits flow back from the target. in the non-TX credit case,
+ * we recheck after the packet completes */
spin_lock_bh(&htc->tx_lock);
- stopping = htc->stopping;
- spin_unlock_bh(&htc->tx_lock);
-
- if (!ep->tx_credit_flow_enabled && !stopping)
- /*
- * note: when using TX credit flow, the re-checking of
- * queues happens when credits flow back from the target.
- * in the non-TX credit case, we recheck after the packet
- * completes
- */
+ if (!ep->tx_credit_flow_enabled && !htc->stopped)
queue_work(ar->workqueue, &ep->send_work);
+ spin_unlock_bh(&htc->tx_lock);
return 0;
}
@@ -951,7 +949,7 @@ void ath10k_htc_stop(struct ath10k_htc *htc)
struct ath10k_htc_ep *ep;
spin_lock_bh(&htc->tx_lock);
- htc->stopping = true;
+ htc->stopped = true;
spin_unlock_bh(&htc->tx_lock);
for (i = ATH10K_HTC_EP_0; i < ATH10K_HTC_EP_COUNT; i++) {
@@ -972,6 +970,7 @@ int ath10k_htc_init(struct ath10k *ar)
spin_lock_init(&htc->tx_lock);
+ htc->stopped = false;
ath10k_htc_reset_endpoint_states(htc);
/* setup HIF layer callbacks */
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index 1606c9f..e1dd8c7 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -335,7 +335,7 @@ struct ath10k_htc {
struct ath10k *ar;
struct ath10k_htc_ep endpoint[ATH10K_HTC_EP_COUNT];
- /* protects endpoint and stopping fields */
+ /* protects endpoint and stopped fields */
spinlock_t tx_lock;
struct ath10k_htc_ops htc_ops;
@@ -349,7 +349,7 @@ struct ath10k_htc {
struct ath10k_htc_svc_tx_credits service_tx_alloc[ATH10K_HTC_EP_COUNT];
int target_credit_size;
- bool stopping;
+ bool stopped;
};
int ath10k_htc_init(struct ath10k *ar);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/4] ath10k: don't reset HTC endpoints unnecessarily
From: Michal Kazior @ 2013-07-22 12:13 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374495211-20353-1-git-send-email-michal.kazior@tieto.com>
Endpoints are re-initialized upon HTC start anyway
so there's no need to do that twice in case of
restarting HTC (i.e. in case of hardware
recovery).
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 47b7752..ef3329e 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -958,7 +958,6 @@ void ath10k_htc_stop(struct ath10k_htc *htc)
}
ath10k_hif_stop(htc->ar);
- ath10k_htc_reset_endpoint_states(htc);
}
/* registered target arrival callback from the HIF layer */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/4] ath10k: fix memleak in mac setup
From: Michal Kazior @ 2013-07-22 12:13 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374495211-20353-1-git-send-email-michal.kazior@tieto.com>
In some cases channel arrays were never freed.
The patch also unifies error handling in the mac
setup function.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 07e5f7d..6144b3b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3225,8 +3225,10 @@ int ath10k_mac_register(struct ath10k *ar)
channels = kmemdup(ath10k_2ghz_channels,
sizeof(ath10k_2ghz_channels),
GFP_KERNEL);
- if (!channels)
- return -ENOMEM;
+ if (!channels) {
+ ret = -ENOMEM;
+ goto err_free;
+ }
band = &ar->mac.sbands[IEEE80211_BAND_2GHZ];
band->n_channels = ARRAY_SIZE(ath10k_2ghz_channels);
@@ -3245,11 +3247,8 @@ int ath10k_mac_register(struct ath10k *ar)
sizeof(ath10k_5ghz_channels),
GFP_KERNEL);
if (!channels) {
- if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY) {
- band = &ar->mac.sbands[IEEE80211_BAND_2GHZ];
- kfree(band->channels);
- }
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_free;
}
band = &ar->mac.sbands[IEEE80211_BAND_5GHZ];
@@ -3313,25 +3312,30 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_reg_notifier);
if (ret) {
ath10k_err("Regulatory initialization failed\n");
- return ret;
+ goto err_free;
}
ret = ieee80211_register_hw(ar->hw);
if (ret) {
ath10k_err("ieee80211 registration failed: %d\n", ret);
- return ret;
+ goto err_free;
}
if (!ath_is_world_regd(&ar->ath_common.regulatory)) {
ret = regulatory_hint(ar->hw->wiphy,
ar->ath_common.regulatory.alpha2);
if (ret)
- goto exit;
+ goto err_unregister;
}
return 0;
-exit:
+
+err_unregister:
ieee80211_unregister_hw(ar->hw);
+err_free:
+ kfree(ar->mac.sbands[IEEE80211_BAND_2GHZ].channels);
+ kfree(ar->mac.sbands[IEEE80211_BAND_5GHZ].channels);
+
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/4] ath10k: fix rts/fragmentation threshold setup
From: Michal Kazior @ 2013-07-22 12:13 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374495211-20353-1-git-send-email-michal.kazior@tieto.com>
If RTS and fragmentation threshold values are
0xFFFFFFFF they should be considered disabled and
no min/max limits must be applied.
This fixes some issues with throughput issues,
especially with VHT.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 54 +++++++++++++++++----------------
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6144b3b..d0a7761 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -332,6 +332,29 @@ static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr)
return 0;
}
+static int ath10k_mac_set_rts(struct ath10k_vif *arvif, u32 value)
+{
+ if (value != 0xFFFFFFFF)
+ value = min_t(u32, arvif->ar->hw->wiphy->rts_threshold,
+ ATH10K_RTS_MAX);
+
+ return ath10k_wmi_vdev_set_param(arvif->ar, arvif->vdev_id,
+ WMI_VDEV_PARAM_RTS_THRESHOLD,
+ value);
+}
+
+static int ath10k_mac_set_frag(struct ath10k_vif *arvif, u32 value)
+{
+ if (value != 0xFFFFFFFF)
+ value = clamp_t(u32, arvif->ar->hw->wiphy->frag_threshold,
+ ATH10K_FRAGMT_THRESHOLD_MIN,
+ ATH10K_FRAGMT_THRESHOLD_MAX);
+
+ return ath10k_wmi_vdev_set_param(arvif->ar, arvif->vdev_id,
+ WMI_VDEV_PARAM_FRAGMENTATION_THRESHOLD,
+ value);
+}
+
static int ath10k_peer_delete(struct ath10k *ar, u32 vdev_id, const u8 *addr)
{
int ret;
@@ -1897,7 +1920,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
enum wmi_sta_powersave_param param;
int ret = 0;
- u32 value, rts, frag;
+ u32 value;
int bit;
mutex_lock(&ar->conf_mutex);
@@ -2000,20 +2023,12 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
ath10k_warn("Failed to set PSPOLL count: %d\n", ret);
}
- rts = min_t(u32, ar->hw->wiphy->rts_threshold, ATH10K_RTS_MAX);
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
- WMI_VDEV_PARAM_RTS_THRESHOLD,
- rts);
+ ret = ath10k_mac_set_rts(arvif, ar->hw->wiphy->rts_threshold);
if (ret)
ath10k_warn("failed to set rts threshold for vdev %d (%d)\n",
arvif->vdev_id, ret);
- frag = clamp_t(u32, ar->hw->wiphy->frag_threshold,
- ATH10K_FRAGMT_THRESHOLD_MIN,
- ATH10K_FRAGMT_THRESHOLD_MAX);
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
- WMI_VDEV_PARAM_FRAGMENTATION_THRESHOLD,
- frag);
+ ret = ath10k_mac_set_frag(arvif, ar->hw->wiphy->frag_threshold);
if (ret)
ath10k_warn("failed to set frag threshold for vdev %d (%d)\n",
arvif->vdev_id, ret);
@@ -2728,11 +2743,7 @@ static void ath10k_set_rts_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
if (ar_iter->ar->state == ATH10K_STATE_RESTARTED)
return;
- rts = min_t(u32, rts, ATH10K_RTS_MAX);
-
- ar_iter->ret = ath10k_wmi_vdev_set_param(ar_iter->ar, arvif->vdev_id,
- WMI_VDEV_PARAM_RTS_THRESHOLD,
- rts);
+ ar_iter->ret = ath10k_mac_set_rts(arvif, rts);
if (ar_iter->ret)
ath10k_warn("Failed to set RTS threshold for VDEV: %d\n",
arvif->vdev_id);
@@ -2764,7 +2775,6 @@ static void ath10k_set_frag_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
struct ath10k_generic_iter *ar_iter = data;
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
u32 frag = ar_iter->ar->hw->wiphy->frag_threshold;
- int ret;
lockdep_assert_held(&arvif->ar->conf_mutex);
@@ -2775,15 +2785,7 @@ static void ath10k_set_frag_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
if (ar_iter->ar->state == ATH10K_STATE_RESTARTED)
return;
- frag = clamp_t(u32, frag,
- ATH10K_FRAGMT_THRESHOLD_MIN,
- ATH10K_FRAGMT_THRESHOLD_MAX);
-
- ret = ath10k_wmi_vdev_set_param(ar_iter->ar, arvif->vdev_id,
- WMI_VDEV_PARAM_FRAGMENTATION_THRESHOLD,
- frag);
-
- ar_iter->ret = ret;
+ ar_iter->ret = ath10k_mac_set_frag(arvif, frag);
if (ar_iter->ret)
ath10k_warn("Failed to set frag threshold for VDEV: %d\n",
arvif->vdev_id);
--
1.7.9.5
^ permalink raw reply related
* Re: Wake-On-Wireless and Deauthentication
From: greg.huber @ 2013-07-22 12:22 UTC (permalink / raw)
To: Arend van Spriel
Cc: Luis R. Rodriguez, linux-wireless, daniel.wagner, Dan Williams
In-Reply-To: <51EABFCA.4060307@broadcom.com>
Arend, Thank You.
I was able to disable NetworkManager and wpa_supplicant and then
restarted the supplicant manually. The system did not disconnect when
suspended, but it would not wake up on magic packet (what I set it to).
On resume it again disconnected and reconnected however.
I put a WOW compatible NIC in my laptop and will do some more
testing. I also need to verify that the wake packets are making it
onto the air.
Thank you for all your help.
Greg
On 07/20/2013 12:50 PM, Arend van Spriel wrote:
> On 07/19/13 20:06, greg.huber wrote:
>> Thank you for your reply, I'm trying this now.
>>
>> Greg
>>
>> On 07/18/2013 09:38 PM, Luis R. Rodriguez wrote:
>>> On Wed, Jul 17, 2013 at 11:11 AM, greg.huber<greg.huber@carestream.com> wrote:
>>>> I'm trying to get Wake-on-wireless working with an Atheros AR9462.
>>>> The problem I seem to be having is that there is a Deauth requested
>>>> when the system is suspended. Does anyone know how to keep the
>>>> association while suspended?? I'm using kernel 3.9.9.
>>>>
>>>> The log after waking (from keyboard)
>>>>
>>>> [ 320.117062] wlp3s0: deauthenticating from 00:24:01:12:de:7a by local choice
>>>> (reason=3)
>>> Typical managers for networking will disassociate you (and therefore
>>> deauth first) prior to kicking the system to suspend. To test WoW you
>>> need to run the supplicant manually because as far as I can tell the
>>> GUI managers don't consider if WoW was enabled or not. In such a case
>>> that WoW was enabled the GUI managers should not send the
>>> deauth/disassoc.
>
> There has been recent commit, which may affect you:
>
> commit 8125696991194aacb1173b6e8196d19098b44e17
> Author: Stanislaw Gruszka <sgruszka@redhat.com>
> Date: Thu Feb 28 10:55:25 2013 +0100
>
> cfg80211/mac80211: disconnect on suspend
>
> It is mentioning something about wowlan so I am not sure whether it does. As
> you are on 3.9.9 I guess you do not have this commit.
>
> Regards,
> Arend
>
>
^ permalink raw reply
* [PATCH] ath10k: improve tx throughput on slow machines
From: Michal Kazior @ 2013-07-22 12:25 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
It is more efficient to move just the 802.11
header instead of the whole payload in most cases.
This has no measurable effect on modern hardware.
It should improve performance by a few percent on
hardware such as an Access Point that have a slow
CPU compared to a typical desktop CPU.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 07e5f7d..6705bc8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1383,9 +1383,9 @@ static void ath10k_tx_h_qos_workaround(struct ieee80211_hw *hw,
return;
qos_ctl = ieee80211_get_qos_ctl(hdr);
- memmove(qos_ctl, qos_ctl + IEEE80211_QOS_CTL_LEN,
- skb->len - ieee80211_hdrlen(hdr->frame_control));
- skb_trim(skb, skb->len - IEEE80211_QOS_CTL_LEN);
+ memmove(skb->data + IEEE80211_QOS_CTL_LEN,
+ skb->data, (void *)qos_ctl - (void *)skb->data);
+ skb_pull(skb, IEEE80211_QOS_CTL_LEN);
}
static void ath10k_tx_h_update_wep_key(struct sk_buff *skb)
--
1.7.9.5
^ permalink raw reply related
* [PATCH] mac80211: add debugfs for driver-buffered TID bitmap
From: Johannes Berg @ 2013-07-22 12:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Add a per-station debugfs file indicating the TIDs (as
a bitmap) that the driver has data buffered on.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/debugfs_sta.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 44e201d..19c54a4 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -455,6 +455,15 @@ void ieee80211_sta_debugfs_add(struct sta_info *sta)
DEBUGFS_ADD_COUNTER(tx_retry_count, tx_retry_count);
DEBUGFS_ADD_COUNTER(wep_weak_iv_count, wep_weak_iv_count);
+ if (sizeof(sta->driver_buffered_tids) == sizeof(u32))
+ debugfs_create_x32("driver_buffered_tids", 0400,
+ sta->debugfs.dir,
+ (u32 *)&sta->driver_buffered_tids);
+ else
+ debugfs_create_x64("driver_buffered_tids", 0400,
+ sta->debugfs.dir,
+ (u64 *)&sta->driver_buffered_tids);
+
drv_sta_add_debugfs(local, sdata, &sta->sta, sta->debugfs.dir);
}
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v2] mac80211: prevent the buffering or frame transmission to non-assoc mesh STA
From: Johannes Berg @ 2013-07-22 13:33 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville
In-Reply-To: <1374226659-2929-1-git-send-email-yeohchunyeow@gmail.com>
On Fri, 2013-07-19 at 17:37 +0800, Chun-Yeow Yeoh wrote:
> This patch is intended to avoid the buffering to non-assoc mesh STA
> and also to avoid the triggering of frame to non-assoc mesh STA which
> could cause kernel panic in specific hw.
Applied. I still find checking the station state a bit odd, but I guess
making sure the station is fine in the callers isn't possible?
johannes
^ permalink raw reply
* Any way to disable RTS/CTS in minstrel_ht?
From: Harshal Chhaya @ 2013-07-22 14:26 UTC (permalink / raw)
To: linux-wireless
On an AR9342-based AP with several AR6102 and AR6203 clients,
minstrel_ht uses RTS/CTS more often than it seems necessary.
Is there a way to disable RTS/CTS in minstrel_ht?
I found a discussion from a couple of years back that talked about
adding an option that tells minstel_ht to really, really turn off
RTS/CTS but I can't determine if that was implemented.
Thanks,
- Harshal
^ permalink raw reply
* Re: So, which IEEE<->Frequency mappings should we be all using?
From: Johannes Berg @ 2013-07-22 14:40 UTC (permalink / raw)
To: Adrian Chadd; +Cc: freebsd-wireless, linux-wireless
In-Reply-To: <CAJ-Vmo=yvHUgv6pwK42n+NhPrAu9shxc5pigRkhZE+x91W_FoA@mail.gmail.com>
On Wed, 2013-07-17 at 10:42 -0700, Adrian Chadd wrote:
> * 420MHz
> * 700MHz
> * 900MHz (which we already have, due to history);
> * 3.6GHz
> * 4.9GHz
3.6 should have been defined in the spec recently, 4.9 surely is defined
already (though the whole stack will have to support the
dot11ChannelStartingFactor)
The others are kinda non-standard extensions, and you probably won't
even be able to properly support them since they're kinda
pretend-handled like 2.4 GHz.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: add ath10k
From: Joe Perches @ 2013-07-22 14:44 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
In-Reply-To: <20130722093220.26562.14270.stgit@localhost6.localdomain6>
On Mon, 2013-07-22 at 12:32 +0300, Kalle Valo wrote:
> I forgot to add an entry to MAINTAINERS when submitting the driver.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> +QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
It's odd to not find ATH6KL next to ATH10K.
Maybe it's time to rename all the ATH sections
to make them QUALCOMM?
^ permalink raw reply
* Re: [PATCH v3 00/20] rt2x00: add experimental support for RT3593
From: Gertjan van Wingerde @ 2013-07-22 15:48 UTC (permalink / raw)
To: Gabor Juhos
Cc: John Linville, linux-wireless@vger.kernel.org, rt2x00 Users List
In-Reply-To: <1373292515-21332-1-git-send-email-juhosg@openwrt.org>
On Mon, Jul 8, 2013 at 4:08 PM, Gabor Juhos <juhosg@openwrt.org> wrote:
> This patch-set implements experiemental support for the
> RT3593 chipset. The patches are tested on the Linksys
> AE3000 USB device only, however other USB devices which
> are using the RT3573 chips might work as well.
>
> The patch-set depends on the following series:
> 'rt2x00: rt2800lib: add support for extended EEPROM of three-chain devices'
>
> Changes since v2:
> - keep case values in aplhabetical order
>
> Changes since v1:
> - add missing patch
> - make Linksys AE3000 support optional
>
I finally found the time to look at this over the weekend. To me it
looks good enough for inclusion.
For the whole series:
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
Gertjan
^ permalink raw reply
* Re: [PATCH] ath: wil6210: Fix build error
From: Luis R. Rodriguez @ 2013-07-22 16:17 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: Larry Finger, linville, linux-wireless, netdev, wil6210, Stable,
Thomas Fjellstrom
In-Reply-To: <1958736.oRuXAUfNGd@lx-vladimir>
On Sun, Jul 21, 2013 at 10:06:31AM +0300, Vladimir Kondratiev wrote:
> Hmm, I have no warning for this with neither 3.10 nor 3.11 kernel version; but
> patch is correct, and here is my
> Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
If you agree with a patch you don't say you Sign-off-by it as well,
you say Acked-by. The Signed-off-by tag has a very specific meaning
from development to a maintainer's hands, and its definition is on
the Developer Certificate or Origin.
So in this case Acked-by is better.
Luis
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: add ath10k
From: Kalle Valo @ 2013-07-22 16:58 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-wireless, ath10k
In-Reply-To: <1374504278.2061.35.camel@joe-AO722>
Joe Perches <joe@perches.com> writes:
> On Mon, 2013-07-22 at 12:32 +0300, Kalle Valo wrote:
>> I forgot to add an entry to MAINTAINERS when submitting the driver.
> []
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> +QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
>
> It's odd to not find ATH6KL next to ATH10K.
I was wondering the same, but decided to put the entries in alphabetical
order still.
> Maybe it's time to rename all the ATH sections
> to make them QUALCOMM?
Maybe, but does it really matter? Changing the MAINTAINERS file just
creates unnecessary conficts for git merges.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: add ath10k
From: Joe Perches @ 2013-07-22 17:04 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
In-Reply-To: <87zjtewmzg.fsf@kamboji.qca.qualcomm.com>
On Mon, 2013-07-22 at 19:58 +0300, Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
>
> > On Mon, 2013-07-22 at 12:32 +0300, Kalle Valo wrote:
> >> I forgot to add an entry to MAINTAINERS when submitting the driver.
> > []
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> > []
> >> +QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
> >
> > It's odd to not find ATH6KL next to ATH10K.
>
> I was wondering the same, but decided to put the entries in alphabetical
> order still.
>
> > Maybe it's time to rename all the ATH sections
> > to make them QUALCOMM?
>
> Maybe, but does it really matter?
Only to those that actually read the MAINTAINERS
file instead of using tools to search it.
> Changing the MAINTAINERS file just
> creates unnecessary conficts for git merges.
Those are always trivially resolved if they
ever really occur.
It's not a big deal, just wanted to note it.
^ permalink raw reply
* Re: So, which IEEE<->Frequency mappings should we be all using?
From: Adrian Chadd @ 2013-07-22 17:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: freebsd-wireless, linux-wireless
In-Reply-To: <1374504059.14517.12.camel@jlt4.sipsolutions.net>
Well, the UHF stuff is available now and vendors are making cards for
them. I'm happy just mapping them to 2.4GHz channels for now but it
severely restricts the channels (ie, spacing/width) we can use in that
range.
adrian
On 22 July 2013 07:40, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2013-07-17 at 10:42 -0700, Adrian Chadd wrote:
>
>> * 420MHz
>> * 700MHz
>> * 900MHz (which we already have, due to history);
>> * 3.6GHz
>> * 4.9GHz
>
> 3.6 should have been defined in the spec recently, 4.9 surely is defined
> already (though the whole stack will have to support the
> dot11ChannelStartingFactor)
>
> The others are kinda non-standard extensions, and you probably won't
> even be able to properly support them since they're kinda
> pretend-handled like 2.4 GHz.
>
> johannes
>
^ permalink raw reply
* [PATCH V2 for-3.11 1/2] brcmfmac: decrement pending 8021x count upon tx failure
From: Arend van Spriel @ 2013-07-22 18:31 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1374489984-18250-2-git-send-email-arend@broadcom.com>
If the transmit fails because there are no hanger slots or
any other reason and the packet was an EAPOL packet the
pending counter should be decreased although it was not
transmitted so the driver does not end up in a dead-lock.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
Fixed typo in commit message: coutner -> counter.
Replaces patch with:
Message-ID: <1374489984-18250-2-git-send-email-arend@broadcom.com>
Regards,
Arend
---
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
index f0d9f7f..29b1f24 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
@@ -1744,13 +1744,14 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
ulong flags;
int fifo = BRCMF_FWS_FIFO_BCMC;
bool multicast = is_multicast_ether_addr(eh->h_dest);
+ bool pae = eh->h_proto == htons(ETH_P_PAE);
/* determine the priority */
if (!skb->priority)
skb->priority = cfg80211_classify8021d(skb);
drvr->tx_multicast += !!multicast;
- if (ntohs(eh->h_proto) == ETH_P_PAE)
+ if (pae)
atomic_inc(&ifp->pend_8021x_cnt);
if (!brcmf_fws_fc_active(fws)) {
@@ -1781,6 +1782,11 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
brcmf_fws_schedule_deq(fws);
} else {
brcmf_err("drop skb: no hanger slot\n");
+ if (pae) {
+ atomic_dec(&ifp->pend_8021x_cnt);
+ if (waitqueue_active(&ifp->pend_8021x_wait))
+ wake_up(&ifp->pend_8021x_wait);
+ }
brcmu_pkt_buf_free_skb(skb);
}
brcmf_fws_unlock(drvr, flags);
--
1.7.10.4
^ permalink raw reply related
* Re: [BUG] 3.10 regression: hang on suspend
From: Ortwin Glück @ 2013-07-22 19:05 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Arend van Spriel, linux-kernel, linux-wireless
In-Reply-To: <20130722112236.GA7364@redhat.com>
On 07/22/2013 01:22 PM, Stanislaw Gruszka wrote:
> We remove interface that we do not add in the driver. I think I found
> reason of that - I removed below code in bad commit:
>
> list_for_each_entry(sdata, &local->interfaces, list) {
> [snip]
> - switch (sdata->vif.type) {
> - case NL80211_IFTYPE_AP_VLAN:
> - case NL80211_IFTYPE_MONITOR:
> - /* skip these */
> - continue;
Oh yes, that makes a lot of sense! I have an extra monitoring interface
configured. If I remove that before suspend, the crash does not occur.
And your patch does fix the problem. Very nice!
Thank you,
Ortwin
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Christian Lamparter @ 2013-07-22 19:54 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee
In-Reply-To: <51ED4E12.8030006@rempel-privat.de>
Hello!
On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> accidentally discovered that 9170 have it too. Are there any issue with
> usb-suspend + xhci controllers by you? Did you some how specially
> handled it?
No, I haven't heard any complains about xhci + suspend. In fact,
it's working fine with the NEC xhci I have. I also have a AR9271
and AR7010, so if you want I could try if they survive a suspend
+resume cycle when attached.
But, I do have a bug-report from someone else who has/had? problems
with carl9170 and xhci. If you want, you can get the details from:
"carl9170 A-MPDU transmit problem":
<http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
The likely cause is related to Intel's xhci silicon (Ivy Bridge is
affected, but I don't know about Haswell):
<http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
However, I haven't heard back from Sarah or Seth about this matter
(Added them to the CC. so "PLEASE" join if either of you think to
have something to add about carl9170 transmit problem or ath9k_htc's
suspend issue... of course, if it was fixed, then it would be really
great to know which commit "fixed it"...)
Regards
Christian
^ permalink raw reply
* Dokumentation Athros Chips
From: Maximilian Kürth @ 2013-07-22 20:02 UTC (permalink / raw)
To: linux-wireless
Hello guys,
i need documentation about AR9104 and AR9170 for a work on TL-WN822N (v1).
If anyone got hands on them and could pass it to me, i would be very pleased.
Best regards
^ permalink raw reply
* Re: pull-request: 2013-07-22
From: John W. Linville @ 2013-07-22 20:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1374494325.14517.4.camel@jlt4.sipsolutions.net>
On Mon, Jul 22, 2013 at 01:58:45PM +0200, Johannes Berg wrote:
> John,
>
> Here's a pull request for 3.11 (and some fixes with cc stable), sorry
> for the delay - I was travelling.
>
> Here I have a fix for RSSI thresholds in mesh, two minstrel fixes from
> Felix, an nl80211 fix from Michal and four various fixes I did myself.
>
> Let me know if there's any problem.
>
> johannes
>
>
>
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
>
> Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
>
> for you to fetch changes up to 5c9fc93bc9bc417418fc1b6366833ae6a07b804d:
>
> mac80211/minstrel: fix NULL pointer dereference issue (2013-07-16 17:48:14 +0300)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull-request: iwlwifi-fixes 2013-07-22
From: John W. Linville @ 2013-07-22 20:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1374494473.14517.8.camel@jlt4.sipsolutions.net>
On Mon, Jul 22, 2013 at 02:01:13PM +0200, Johannes Berg wrote:
> John,
>
> And another one for iwlwifi.
>
> Here I have a fix for debugfs directory creation (causing a spurious
> error message), two scanning fixes from David Spinadel, an LED fix and
> two patches related to a BA session problem that eventually caused
> firmware crashes from Emmanuel and a small BT fix for older devices as
> well as a workaround for a firmware problem with APs with very small
> beacon intervals from myself.
>
> Let me know if there's any problem.
>
> johannes
>
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
>
> Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git for-john
>
> for you to fetch changes up to a590ad411891de551e6de1b51ea635c0484148d6:
>
> iwlwifi: mvm: remove extra SSID from probe request (2013-07-16 13:55:15 +0300)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Dokumentation Athros Chips
From: Christian Lamparter @ 2013-07-22 20:25 UTC (permalink / raw)
To: Maximilian Kürth; +Cc: linux-wireless
In-Reply-To: <2515287.MZDuQ7LknB@w0rk0n>
Hello,
On Monday, July 22, 2013 10:02:33 PM Maximilian Kürth wrote:
> i need documentation about AR9104 and AR9170 for a work on TL-WN822N (v1).
> If anyone got hands on them and could pass it to me, i would be very pleased.
You should be able to get the documentations directly from Qualcomm Atheros (QCA).
Yup, QCA provides access to documentation, source code and hardware for
developers who wish to work with them on improving their open source
support through "Qualcomm Atheros' open source NDA" program.
I don't know who handles new applications, but <mcgrof@qca.qualcomm.com>
should be able to point you into the right direction with this.
Of course, if you have any specific questions about the driver
(and the hardware) you can always ask them on this ML and we tell
you what we know (no NDA necessary here ;-) ).
Regards
Christian
^ 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