* [RFC 3/3] ath10k: add support for HTT 3.0
From: Michal Kazior @ 2013-08-08 8:08 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949298-7159-1-git-send-email-michal.kazior@tieto.com>
New firmware comes with new HTT protocol version.
In 3.0 the separate mgmt tx command has been
removed. All traffic is to be pushed through data
tx (tx_frm) command with a twist - FW seems to not
be able (yet?) to access tx fragment table so for
manamgement frames frame pointer is passed
directly.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htt.c | 16 +++----
drivers/net/wireless/ath/ath10k/htt.h | 6 +--
drivers/net/wireless/ath/ath10k/htt_tx.c | 70 ++++++++++++++++++++----------
drivers/net/wireless/ath/ath10k/hw.h | 3 ++
drivers/net/wireless/ath/ath10k/mac.c | 11 ++++-
5 files changed, 69 insertions(+), 37 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.c b/drivers/net/wireless/ath/ath10k/htt.c
index 39342c5..44facc1 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -104,21 +104,15 @@ err_htc_attach:
static int ath10k_htt_verify_version(struct ath10k_htt *htt)
{
- ath10k_dbg(ATH10K_DBG_HTT,
- "htt target version %d.%d; host version %d.%d\n",
- htt->target_version_major,
- htt->target_version_minor,
- HTT_CURRENT_VERSION_MAJOR,
- HTT_CURRENT_VERSION_MINOR);
-
- if (htt->target_version_major != HTT_CURRENT_VERSION_MAJOR) {
+ ath10k_dbg(ATH10K_DBG_HTT, "htt target version %d.%d\n",
+ htt->target_version_major, htt->target_version_minor);
+
+ if (htt->target_version_major != 2 &&
+ htt->target_version_major != 3) {
ath10k_err("htt major versions are incompatible!\n");
return -ENOTSUPP;
}
- if (htt->target_version_minor != HTT_CURRENT_VERSION_MINOR)
- ath10k_warn("htt minor version differ but still compatible\n");
-
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index de45d02..2488623 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -23,9 +23,6 @@
#include "htc.h"
#include "rx_desc.h"
-#define HTT_CURRENT_VERSION_MAJOR 2
-#define HTT_CURRENT_VERSION_MINOR 1
-
enum htt_dbg_stats_type {
HTT_DBG_STATS_WAL_PDEV_TXRX = 1 << 0,
HTT_DBG_STATS_RX_REORDER = 1 << 1,
@@ -45,6 +42,9 @@ enum htt_h2t_msg_type { /* host-to-target */
HTT_H2T_MSG_TYPE_SYNC = 4,
HTT_H2T_MSG_TYPE_AGGR_CFG = 5,
HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG = 6,
+
+ /* This command is used for sending management frames in HTT < 3.0.
+ * HTT >= 3.0 uses TX_FRM for everything. */
HTT_H2T_MSG_TYPE_MGMT_TX = 7,
HTT_H2T_NUM_MSGS /* keep this last */
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 656c254..dce128a 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -401,10 +401,15 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
goto err;
}
- txfrag = dev_alloc_skb(frag_len);
- if (!txfrag) {
- res = -ENOMEM;
- goto err;
+ /* Since HTT 3.0 there is no separate mgmt tx command. However in case
+ * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
+ * fragment list host driver specifies directly frame pointer. */
+ if (!(htt->target_version_major >= 3 && ieee80211_is_mgmt(hdr->frame_control))) {
+ txfrag = dev_alloc_skb(frag_len);
+ if (!txfrag) {
+ res = -ENOMEM;
+ goto err;
+ }
}
if (!IS_ALIGNED((unsigned long)txdesc->data, 4)) {
@@ -427,23 +432,30 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
if (res)
goto err;
- /* tx fragment list must be terminated with zero-entry */
- skb_put(txfrag, frag_len);
- tx_frags = (struct htt_data_tx_desc_frag *)txfrag->data;
- tx_frags[0].paddr = __cpu_to_le32(ATH10K_SKB_CB(msdu)->paddr);
- tx_frags[0].len = __cpu_to_le32(msdu->len);
- tx_frags[1].paddr = __cpu_to_le32(0);
- tx_frags[1].len = __cpu_to_le32(0);
-
- res = ath10k_skb_map(dev, txfrag);
- if (res)
- goto err;
+ /* Since HTT 3.0 there is no separate mgmt tx command. However in case
+ * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
+ * fragment list host driver specifies directly frame pointer. */
+ if (!(htt->target_version_major >= 3 && ieee80211_is_mgmt(hdr->frame_control))) {
+ /* tx fragment list must be terminated with zero-entry */
+ skb_put(txfrag, frag_len);
+ tx_frags = (struct htt_data_tx_desc_frag *)txfrag->data;
+ tx_frags[0].paddr = __cpu_to_le32(ATH10K_SKB_CB(msdu)->paddr);
+ tx_frags[0].len = __cpu_to_le32(msdu->len);
+ tx_frags[1].paddr = __cpu_to_le32(0);
+ tx_frags[1].len = __cpu_to_le32(0);
+
+ res = ath10k_skb_map(dev, txfrag);
+ if (res)
+ goto err;
+
+ ath10k_dbg(ATH10K_DBG_HTT, "txfrag 0x%llx\n",
+ (unsigned long long) ATH10K_SKB_CB(txfrag)->paddr);
+ ath10k_dbg_dump(ATH10K_DBG_HTT_DUMP, NULL, "txfrag: ",
+ txfrag->data, frag_len);
+ }
- ath10k_dbg(ATH10K_DBG_HTT, "txfrag 0x%llx msdu 0x%llx\n",
- (unsigned long long) ATH10K_SKB_CB(txfrag)->paddr,
+ ath10k_dbg(ATH10K_DBG_HTT, "msdu 0x%llx\n",
(unsigned long long) ATH10K_SKB_CB(msdu)->paddr);
- ath10k_dbg_dump(ATH10K_DBG_HTT_DUMP, NULL, "txfrag: ",
- txfrag->data, frag_len);
ath10k_dbg_dump(ATH10K_DBG_HTT_DUMP, NULL, "msdu: ",
msdu->data, msdu->len);
@@ -459,8 +471,16 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
if (!ieee80211_has_protected(hdr->frame_control))
flags0 |= HTT_DATA_TX_DESC_FLAGS0_NO_ENCRYPT;
flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
- flags0 |= SM(ATH10K_HW_TXRX_NATIVE_WIFI,
- HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+
+ /* Since HTT 3.0 there is no separate mgmt tx command. However in case
+ * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
+ * fragment list host driver specifies directly frame pointer. */
+ if (htt->target_version_major >= 3 && ieee80211_is_mgmt(hdr->frame_control))
+ flags0 |= SM(ATH10K_HW_TXRX_MGMT,
+ HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+ else
+ flags0 |= SM(ATH10K_HW_TXRX_NATIVE_WIFI,
+ HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
flags1 = 0;
flags1 |= SM((u16)vdev_id, HTT_DATA_TX_DESC_FLAGS1_VDEV_ID);
@@ -468,7 +488,13 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L3_OFFLOAD;
flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L4_OFFLOAD;
- frags_paddr = ATH10K_SKB_CB(txfrag)->paddr;
+ /* Since HTT 3.0 there is no separate mgmt tx command. However in case
+ * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
+ * fragment list host driver specifies directly frame pointer. */
+ if (htt->target_version_major >= 3 && ieee80211_is_mgmt(hdr->frame_control))
+ frags_paddr = ATH10K_SKB_CB(msdu)->paddr;
+ else
+ frags_paddr = ATH10K_SKB_CB(txfrag)->paddr;
cmd->hdr.msg_type = HTT_H2T_MSG_TYPE_TX_FRM;
cmd->data_tx.flags0 = flags0;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 44ed5af..9c5d6fc 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -53,6 +53,9 @@ enum ath10k_hw_txrx_mode {
ATH10K_HW_TXRX_RAW = 0,
ATH10K_HW_TXRX_NATIVE_WIFI = 1,
ATH10K_HW_TXRX_ETHERNET = 2,
+
+ /* Valid for HTT >= 3.0. Used for management frames in TX_FRM. */
+ ATH10K_HW_TXRX_MGMT = 3,
};
enum ath10k_mcast2ucast_mode {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index fb1f24f..aca423c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1480,6 +1480,12 @@ static void ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
int ret;
+ if (ar->htt.target_version_major >= 3) {
+ /* Since HTT 3.0 there is no separate mgmt tx command */
+ ret = ath10k_htt_tx(&ar->htt, skb);
+ goto exit;
+ }
+
if (ieee80211_is_mgmt(hdr->frame_control))
ret = ath10k_htt_mgmt_tx(&ar->htt, skb);
else if (ieee80211_is_nullfunc(hdr->frame_control))
@@ -1491,6 +1497,7 @@ static void ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb)
else
ret = ath10k_htt_tx(&ar->htt, skb);
+exit:
if (ret) {
ath10k_warn("tx failed (%d). dropping packet.\n", ret);
ieee80211_free_txskb(ar->hw, skb);
@@ -1726,7 +1733,9 @@ static void ath10k_tx(struct ieee80211_hw *hw,
/* we must calculate tid before we apply qos workaround
* as we'd lose the qos control field */
- if (ieee80211_is_data_qos(hdr->frame_control) &&
+ if (ieee80211_is_mgmt(hdr->frame_control))
+ tid = HTT_DATA_TX_EXT_TID_MGMT;
+ else if (ieee80211_is_data_qos(hdr->frame_control) &&
is_unicast_ether_addr(ieee80211_get_DA(hdr))) {
u8 *qc = ieee80211_get_qos_ctl(hdr);
tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/4] ath10k: cleanups
From: Michal Kazior @ 2013-08-08 8:14 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This patchset contains a few non-functional clean
ups.
Michal Kazior (4):
ath10k: clean up monitor start code
ath10k: use sizeof(*var) in kmalloc
ath10k: clean up PCI completion states
ath10k: print errcode when CE ring setup fails
drivers/net/wireless/ath/ath10k/ce.c | 15 +++++++++------
drivers/net/wireless/ath/ath10k/mac.c | 3 ---
drivers/net/wireless/ath/ath10k/pci.c | 24 ++++++++++++++++--------
drivers/net/wireless/ath/ath10k/pci.h | 13 +++++++------
4 files changed, 32 insertions(+), 23 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/4] ath10k: clean up monitor start code
From: Michal Kazior @ 2013-08-08 8:14 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949650-9699-1-git-send-email-michal.kazior@tieto.com>
Remove useless code that was causing WARN_ON when
a 80MHz+ vif entered promiscuous mode or monitor
interface was started.
The channel mode is already computed by
chan_to_phymode().
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index cf2ba4d..05f5f76 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -503,13 +503,10 @@ static int ath10k_monitor_start(struct ath10k *ar, int vdev_id)
{
struct ieee80211_channel *channel = ar->hw->conf.chandef.chan;
struct wmi_vdev_start_request_arg arg = {};
- enum nl80211_channel_type type;
int ret = 0;
lockdep_assert_held(&ar->conf_mutex);
- type = cfg80211_get_chandef_type(&ar->hw->conf.chandef);
-
arg.vdev_id = vdev_id;
arg.channel.freq = channel->center_freq;
arg.channel.band_center_freq1 = ar->hw->conf.chandef.center_freq1;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] ath10k: use sizeof(*var) in kmalloc
From: Michal Kazior @ 2013-08-08 8:14 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949650-9699-1-git-send-email-michal.kazior@tieto.com>
This fixes checkpatch warning from the latest
3.11-rc kernel tree.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index d95439b..1814af1 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -803,8 +803,7 @@ static int ath10k_pci_start_ce(struct ath10k *ar)
continue;
for (i = 0; i < completions; i++) {
- compl = kmalloc(sizeof(struct ath10k_pci_compl),
- GFP_KERNEL);
+ compl = kmalloc(sizeof(*compl), GFP_KERNEL);
if (!compl) {
ath10k_warn("No memory for completion state\n");
ath10k_pci_stop_ce(ar);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] ath10k: clean up PCI completion states
From: Michal Kazior @ 2013-08-08 8:14 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949650-9699-1-git-send-email-michal.kazior@tieto.com>
Improve code readability by using enum and a
switch-case.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 21 +++++++++++++++------
drivers/net/wireless/ath/ath10k/pci.h | 13 +++++++------
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 1814af1..321cc88 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -538,7 +538,7 @@ static void ath10k_pci_ce_send_done(struct ce_state *ce_state,
if (!compl)
break;
- compl->send_or_recv = HIF_CE_COMPLETE_SEND;
+ compl->state = ATH10K_PCI_COMPL_SEND;
compl->ce_state = ce_state;
compl->pipe_info = pipe_info;
compl->transfer_context = transfer_context;
@@ -588,7 +588,7 @@ static void ath10k_pci_ce_recv_data(struct ce_state *ce_state,
if (!compl)
break;
- compl->send_or_recv = HIF_CE_COMPLETE_RECV;
+ compl->state = ATH10K_PCI_COMPL_RECV;
compl->ce_state = ce_state;
compl->pipe_info = pipe_info;
compl->transfer_context = transfer_context;
@@ -810,7 +810,7 @@ static int ath10k_pci_start_ce(struct ath10k *ar)
return -ENOMEM;
}
- compl->send_or_recv = HIF_CE_COMPLETE_FREE;
+ compl->state = ATH10K_PCI_COMPL_FREE;
list_add_tail(&compl->list, &pipe_info->compl_free);
}
}
@@ -909,12 +909,14 @@ static void ath10k_pci_process_ce(struct ath10k *ar)
list_del(&compl->list);
spin_unlock_bh(&ar_pci->compl_lock);
- if (compl->send_or_recv == HIF_CE_COMPLETE_SEND) {
+ switch (compl->state) {
+ case ATH10K_PCI_COMPL_SEND:
cb->tx_completion(ar,
compl->transfer_context,
compl->transfer_id);
send_done = 1;
- } else {
+ break;
+ case ATH10K_PCI_COMPL_RECV:
ret = ath10k_pci_post_rx_pipe(compl->pipe_info, 1);
if (ret) {
ath10k_warn("Unable to post recv buffer for pipe: %d\n",
@@ -941,9 +943,16 @@ static void ath10k_pci_process_ce(struct ath10k *ar)
nbytes,
skb->len + skb_tailroom(skb));
}
+ break;
+ case ATH10K_PCI_COMPL_FREE:
+ ath10k_warn("free completion cannot be processed\n");
+ break;
+ default:
+ ath10k_warn("invalid completion state (%d)\n", compl->state);
+ break;
}
- compl->send_or_recv = HIF_CE_COMPLETE_FREE;
+ compl->state = ATH10K_PCI_COMPL_FREE;
/*
* Add completion back to the pipe's free list.
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index d3a2e6c..1908d61 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -43,9 +43,15 @@ struct bmi_xfer {
u32 resp_len;
};
+enum ath10k_pci_compl_state {
+ ATH10K_PCI_COMPL_FREE = 0,
+ ATH10K_PCI_COMPL_SEND,
+ ATH10K_PCI_COMPL_RECV,
+};
+
struct ath10k_pci_compl {
struct list_head list;
- int send_or_recv;
+ enum ath10k_pci_compl_state state;
struct ce_state *ce_state;
struct hif_ce_pipe_info *pipe_info;
void *transfer_context;
@@ -54,11 +60,6 @@ struct ath10k_pci_compl {
unsigned int flags;
};
-/* compl_state.send_or_recv */
-#define HIF_CE_COMPLETE_FREE 0
-#define HIF_CE_COMPLETE_SEND 1
-#define HIF_CE_COMPLETE_RECV 2
-
/*
* PCI-specific Target state
*
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] ath10k: print errcode when CE ring setup fails
From: Michal Kazior @ 2013-08-08 8:14 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949650-9699-1-git-send-email-michal.kazior@tieto.com>
This makes it possible to see the reason why the
setup fails. It also adheres to code style of
error checking in ath drivers.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index f8b969f..50d2ea2 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1128,6 +1128,7 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
{
struct ce_state *ce_state;
u32 ctrl_addr = ath10k_ce_base_address(ce_id);
+ int ret;
ce_state = ath10k_ce_init_state(ar, ce_id, attr);
if (!ce_state) {
@@ -1136,18 +1137,20 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
}
if (attr->src_nentries) {
- if (ath10k_ce_init_src_ring(ar, ce_id, ce_state, attr)) {
- ath10k_err("Failed to initialize CE src ring for ID: %d\n",
- ce_id);
+ ret = ath10k_ce_init_src_ring(ar, ce_id, ce_state, attr);
+ if (ret) {
+ ath10k_err("Failed to initialize CE src ring for ID: %d (%d)\n",
+ ce_id, ret);
ath10k_ce_deinit(ce_state);
return NULL;
}
}
if (attr->dest_nentries) {
- if (ath10k_ce_init_dest_ring(ar, ce_id, ce_state, attr)) {
- ath10k_err("Failed to initialize CE dest ring for ID: %d\n",
- ce_id);
+ ret = ath10k_ce_init_dest_ring(ar, ce_id, ce_state, attr);
+ if (ret) {
+ ath10k_err("Failed to initialize CE dest ring for ID: %d (%d)\n",
+ ce_id, ret);
ath10k_ce_deinit(ce_state);
return NULL;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/4] ath10k: fixes
From: Michal Kazior @ 2013-08-08 8:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This patchset contains some bugfixes and
improvements.
Michal Kazior (4):
ath10k: fix HTT service setup
ath10k: fix HTC endpoint worker starvation
ath10k: implement 802.3 SNAP rx decap type A-MSDU handling
ath10k: plug possible memory leak in WMI
drivers/net/wireless/ath/ath10k/htc.c | 25 +++++++++++++------------
drivers/net/wireless/ath/ath10k/htc.h | 3 ++-
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++++++--
drivers/net/wireless/ath/ath10k/wmi.c | 1 +
4 files changed, 26 insertions(+), 15 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/4] ath10k: fix HTT service setup
From: Michal Kazior @ 2013-08-08 8:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949813-10969-1-git-send-email-michal.kazior@tieto.com>
The "disable credit flow" flag was set too late
and it never was in the HTC service request
message.
This patch prevents firmware from reporting
(useless) HTC credits for HTT service. HTT service
doesn't use nor need credits.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index ef3329e..7d445d3 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -772,16 +772,16 @@ int ath10k_htc_connect_service(struct ath10k_htc *htc,
flags |= SM(tx_alloc, ATH10K_HTC_CONN_FLAGS_RECV_ALLOC);
- req_msg = &msg->connect_service;
- req_msg->flags = __cpu_to_le16(flags);
- req_msg->service_id = __cpu_to_le16(conn_req->service_id);
-
/* Only enable credit flow control for WMI ctrl service */
if (conn_req->service_id != ATH10K_HTC_SVC_ID_WMI_CONTROL) {
flags |= ATH10K_HTC_CONN_FLAGS_DISABLE_CREDIT_FLOW_CTRL;
disable_credit_flow_ctrl = true;
}
+ req_msg = &msg->connect_service;
+ req_msg->flags = __cpu_to_le16(flags);
+ req_msg->service_id = __cpu_to_le16(conn_req->service_id);
+
INIT_COMPLETION(htc->ctl_resp);
status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] ath10k: fix HTC endpoint worker starvation
From: Michal Kazior @ 2013-08-08 8:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949813-10969-1-git-send-email-michal.kazior@tieto.com>
HTC used a worker for each endpoint. This worked
until a slow host machine was flooded with massive
number of TX requests. HTT related worker would
remain active while WMI worker was starved. This
ended up with "could not send beacon" in AP mode.
It was even possible to see userspace being
starved.
The patch switches from using workers to using
tasklets for processing and submitting HTC frames
to HIF.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 17 +++++++++--------
drivers/net/wireless/ath/ath10k/htc.h | 3 ++-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 7d445d3..4b1dd0e 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -15,6 +15,7 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include <linux/interrupt.h>
#include "core.h"
#include "hif.h"
#include "debug.h"
@@ -210,10 +211,9 @@ static struct sk_buff *ath10k_htc_get_skb_credit_based(struct ath10k_htc *htc,
return skb;
}
-static void ath10k_htc_send_work(struct work_struct *work)
+static void ath10k_htc_send_task(unsigned long ptr)
{
- struct ath10k_htc_ep *ep = container_of(work,
- struct ath10k_htc_ep, send_work);
+ struct ath10k_htc_ep *ep = (struct ath10k_htc_ep *)ptr;
struct ath10k_htc *htc = ep->htc;
struct sk_buff *skb;
u8 credits = 0;
@@ -264,7 +264,7 @@ int ath10k_htc_send(struct ath10k_htc *htc,
skb_push(skb, sizeof(struct ath10k_htc_hdr));
spin_unlock_bh(&htc->tx_lock);
- queue_work(htc->ar->workqueue, &ep->send_work);
+ tasklet_schedule(&ep->send_task);
return 0;
}
@@ -283,7 +283,7 @@ static int ath10k_htc_tx_completion_handler(struct ath10k *ar,
* we recheck after the packet completes */
spin_lock_bh(&htc->tx_lock);
if (!ep->tx_credit_flow_enabled && !htc->stopped)
- queue_work(ar->workqueue, &ep->send_work);
+ tasklet_schedule(&ep->send_task);
spin_unlock_bh(&htc->tx_lock);
return 0;
@@ -308,7 +308,7 @@ static void ath10k_htc_flush_endpoint_tx(struct ath10k_htc *htc,
}
spin_unlock_bh(&htc->tx_lock);
- cancel_work_sync(&ep->send_work);
+ tasklet_kill(&ep->send_task);
}
/***********/
@@ -341,7 +341,7 @@ ath10k_htc_process_credit_report(struct ath10k_htc *htc,
ep->tx_credits += report->credits;
if (ep->tx_credits && !skb_queue_empty(&ep->tx_queue))
- queue_work(htc->ar->workqueue, &ep->send_work);
+ tasklet_schedule(&ep->send_task);
}
spin_unlock_bh(&htc->tx_lock);
}
@@ -602,7 +602,8 @@ static void ath10k_htc_reset_endpoint_states(struct ath10k_htc *htc)
skb_queue_head_init(&ep->tx_queue);
ep->htc = htc;
ep->tx_credit_flow_enabled = true;
- INIT_WORK(&ep->send_work, ath10k_htc_send_work);
+ tasklet_init(&ep->send_task, ath10k_htc_send_task,
+ (unsigned long)ep);
}
}
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index e1dd8c7..6afa175 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -24,6 +24,7 @@
#include <linux/skbuff.h>
#include <linux/semaphore.h>
#include <linux/timer.h>
+#include <linux/interrupt.h>
struct ath10k;
@@ -323,7 +324,7 @@ struct ath10k_htc_ep {
int tx_credits_per_max_message;
bool tx_credit_flow_enabled;
- struct work_struct send_work;
+ struct tasklet_struct send_task;
};
struct ath10k_htc_svc_tx_credits {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] ath10k: implement 802.3 SNAP rx decap type A-MSDU handling
From: Michal Kazior @ 2013-08-08 8:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949813-10969-1-git-send-email-michal.kazior@tieto.com>
This enables driver to rx another decapped a-msdu
frames. It should possibly help with throughputs
in some cases and reduce (or eliminate) number of
messages like this:
ath10k: error processing msdus -524
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index e784c40..9b93aed 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -610,8 +610,7 @@ static int ath10k_htt_rx_amsdu(struct ath10k_htt *htt,
RX_MPDU_START_INFO0_ENCRYPT_TYPE);
/* FIXME: No idea what assumptions are safe here. Need logs */
- if ((fmt == RX_MSDU_DECAP_RAW && skb->next) ||
- (fmt == RX_MSDU_DECAP_8023_SNAP_LLC)) {
+ if ((fmt == RX_MSDU_DECAP_RAW && skb->next)) {
ath10k_htt_rx_free_msdu_chain(skb->next);
skb->next = NULL;
return -ENOTSUPP;
@@ -659,6 +658,15 @@ static int ath10k_htt_rx_amsdu(struct ath10k_htt *htt,
decap_hdr += roundup(crypto_len, 4);
}
+ if (fmt == RX_MSDU_DECAP_8023_SNAP_LLC) {
+ /* SNAP 802.3 consists of:
+ * [dst:6][src:6][len:2][dsap:1][ssap:1][ctl:1][snap:5]
+ * [data][fcs:4].
+ *
+ * Since this overlaps with A-MSDU header (da, sa, len)
+ * there's nothing extra to do. */
+ }
+
if (fmt == RX_MSDU_DECAP_ETHERNET2_DIX) {
/* Ethernet2 decap inserts ethernet header in place of
* A-MSDU subframe header. */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] ath10k: plug possible memory leak in WMI
From: Michal Kazior @ 2013-08-08 8:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949813-10969-1-git-send-email-michal.kazior@tieto.com>
There was a possible memory leak when WMI command
queue reached it's limit. Command buffers were not
freed.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 55f90c7..775fedf 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -110,6 +110,7 @@ static int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb,
if (atomic_add_return(1, &ar->wmi.pending_tx_count) >
WMI_MAX_PENDING_TX_COUNT) {
/* avoid using up memory when FW hangs */
+ dev_kfree_skb(skb);
atomic_dec(&ar->wmi.pending_tx_count);
return -EBUSY;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC 1/3] ath10k: add support for firmware newer than 636
From: Kalle Valo @ 2013-08-08 8:46 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1375949298-7159-2-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> The mgmt_rx event structure has been expanded.
> Since the structure header is expanded the payload
> (i.e. mgmt frame) is shifted by a few bytes. This
> needs to be taken into account in order to support
> both old and new firmware.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> @@ -325,13 +327,24 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
> u32 rate;
> u32 buf_len;
> u16 fc;
> + int pull_len;
> +
> + if (ar->fw_version_build > 636) {
> + ev_abi2 = (struct wmi_mgmt_rx_event_abi2 *)skb->data;
> + ev_hdr = &ev_abi2->hdr.abi1;
> + pull_len = sizeof(*ev_abi2);
> + } else {
> + ev_abi1 = (struct wmi_mgmt_rx_event_abi1 *)skb->data;
> + ev_hdr = &ev_abi1->hdr;
> + pull_len = sizeof(*ev_abi1);
> + }
I would prefer to have ar->fw_features (or similar) bitmap for handling
this. That way we can group all firmware version tests into one place
and not sprinkle them around. I suspect there will be more tests like
this.
[...]
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -1268,7 +1268,7 @@ struct wmi_scan_event {
> * good idea to pass all the fields in the RX status
> * descriptor up to the host.
> */
> -struct wmi_mgmt_rx_hdr {
> +struct wmi_mgmt_rx_hdr_abi1 {
> __le32 channel;
> __le32 snr;
> __le32 rate;
> @@ -1277,8 +1277,18 @@ struct wmi_mgmt_rx_hdr {
> __le32 status; /* %WMI_RX_STATUS_ */
> } __packed;
>
> -struct wmi_mgmt_rx_event {
> - struct wmi_mgmt_rx_hdr hdr;
> +struct wmi_mgmt_rx_hdr_abi2 {
> + struct wmi_mgmt_rx_hdr_abi1 abi1;
> + __le32 rssi_ctl[4];
> +} __packed;
> +
> +struct wmi_mgmt_rx_event_abi1 {
> + struct wmi_mgmt_rx_hdr_abi1 hdr;
> + u8 buf[0];
> +} __packed;
> +
> +struct wmi_mgmt_rx_event_abi2 {
> + struct wmi_mgmt_rx_hdr_abi2 hdr;
> u8 buf[0];
> } __packed;
I would prefer to use v1 and v2 instead on abi1 and abi2.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 3/3] ath10k: add support for HTT 3.0
From: Kalle Valo @ 2013-08-08 9:05 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1375949298-7159-4-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> New firmware comes with new HTT protocol version.
> In 3.0 the separate mgmt tx command has been
> removed. All traffic is to be pushed through data
> tx (tx_frm) command with a twist - FW seems to not
> be able (yet?) to access tx fragment table so for
> manamgement frames frame pointer is passed
> directly.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> static int ath10k_htt_verify_version(struct ath10k_htt *htt)
> {
> - ath10k_dbg(ATH10K_DBG_HTT,
> - "htt target version %d.%d; host version %d.%d\n",
> - htt->target_version_major,
> - htt->target_version_minor,
> - HTT_CURRENT_VERSION_MAJOR,
> - HTT_CURRENT_VERSION_MINOR);
> -
> - if (htt->target_version_major != HTT_CURRENT_VERSION_MAJOR) {
> + ath10k_dbg(ATH10K_DBG_HTT, "htt target version %d.%d\n",
> + htt->target_version_major, htt->target_version_minor);
This debug print is good to have, but with the new htt version it would
be good to print it always using the info level. For example, can we add
it to the same line with "firmware %s booted" string?
(Please take into account that the info messages still need to be
compact, by default they should not be longer than five lines or so.)
> + if (htt->target_version_major != 2 &&
> + htt->target_version_major != 3) {
> ath10k_err("htt major versions are incompatible!\n");
> return -ENOTSUPP;
> }
Print the htt version in the error message as well?
> @@ -401,10 +401,15 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
> goto err;
> }
>
> - txfrag = dev_alloc_skb(frag_len);
> - if (!txfrag) {
> - res = -ENOMEM;
> - goto err;
> + /* Since HTT 3.0 there is no separate mgmt tx command. However in case
> + * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
> + * fragment list host driver specifies directly frame pointer. */
> + if (!(htt->target_version_major >= 3 && ieee80211_is_mgmt(hdr->frame_control))) {
I think using "< 3" is more readable:
if (htt->target_version_major < 3 &&
!ieee80211_is_mgmt(hdr->frame_control)) {
...
}
And is the single line too long? Didn't count it, though.
> @@ -427,23 +432,30 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
> if (res)
> goto err;
>
> - /* tx fragment list must be terminated with zero-entry */
> - skb_put(txfrag, frag_len);
> - tx_frags = (struct htt_data_tx_desc_frag *)txfrag->data;
> - tx_frags[0].paddr = __cpu_to_le32(ATH10K_SKB_CB(msdu)->paddr);
> - tx_frags[0].len = __cpu_to_le32(msdu->len);
> - tx_frags[1].paddr = __cpu_to_le32(0);
> - tx_frags[1].len = __cpu_to_le32(0);
> -
> - res = ath10k_skb_map(dev, txfrag);
> - if (res)
> - goto err;
> + /* Since HTT 3.0 there is no separate mgmt tx command. However in case
> + * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
> + * fragment list host driver specifies directly frame pointer. */
> + if (!(htt->target_version_major >= 3 && ieee80211_is_mgmt(hdr->frame_control))) {
Ditto.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 0/3] ath10k: firmware-related updates
From: Kalle Valo @ 2013-08-08 9:07 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1375949298-7159-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This patchset contains 2 firmware-related upgrades
> and 1 fix (that I though is a good pick to include
> here, since it's related with HTT tx).
>
> This keeps backward compatbility with old
> firmware.
Thanks, looks very good! I just had more or less cosmetic comments.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 3/3] ath10k: add support for HTT 3.0
From: Michal Kazior @ 2013-08-08 9:12 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87eha4363n.fsf@kamboji.qca.qualcomm.com>
On 8 August 2013 11:05, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> New firmware comes with new HTT protocol version.
>> In 3.0 the separate mgmt tx command has been
>> removed. All traffic is to be pushed through data
>> tx (tx_frm) command with a twist - FW seems to not
>> be able (yet?) to access tx fragment table so for
>> manamgement frames frame pointer is passed
>> directly.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> [...]
>
>> static int ath10k_htt_verify_version(struct ath10k_htt *htt)
>> {
>> - ath10k_dbg(ATH10K_DBG_HTT,
>> - "htt target version %d.%d; host version %d.%d\n",
>> - htt->target_version_major,
>> - htt->target_version_minor,
>> - HTT_CURRENT_VERSION_MAJOR,
>> - HTT_CURRENT_VERSION_MINOR);
>> -
>> - if (htt->target_version_major != HTT_CURRENT_VERSION_MAJOR) {
>> + ath10k_dbg(ATH10K_DBG_HTT, "htt target version %d.%d\n",
>> + htt->target_version_major, htt->target_version_minor);
>
> This debug print is good to have, but with the new htt version it would
> be good to print it always using the info level. For example, can we add
> it to the same line with "firmware %s booted" string?
HTT target version is not known when firmware boots up. It's not known
until everything other (HTC, WMI) is set up. We then send a version
request command and we get a response.
We need to print it in a separate line.
> (Please take into account that the info messages still need to be
> compact, by default they should not be longer than five lines or so.)
>
>> + if (htt->target_version_major != 2 &&
>> + htt->target_version_major != 3) {
>> ath10k_err("htt major versions are incompatible!\n");
>> return -ENOTSUPP;
>> }
>
> Print the htt version in the error message as well?
Target version is printed in ath10k_dbg() now. If we change that to
ath10k_info() I don't see any reason to print the version again on
error. We may want to print the list of supported HTT major version
numbers though?
>> @@ -401,10 +401,15 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
>> goto err;
>> }
>>
>> - txfrag = dev_alloc_skb(frag_len);
>> - if (!txfrag) {
>> - res = -ENOMEM;
>> - goto err;
>> + /* Since HTT 3.0 there is no separate mgmt tx command. However in case
>> + * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
>> + * fragment list host driver specifies directly frame pointer. */
>> + if (!(htt->target_version_major >= 3 && ieee80211_is_mgmt(hdr->frame_control))) {
>
> I think using "< 3" is more readable:
>
> if (htt->target_version_major < 3 &&
> !ieee80211_is_mgmt(hdr->frame_control)) {
> ...
> }
I don't have a problem with changing that.
> And is the single line too long? Didn't count it, though.
Ah, I didn't check that. Sorry. Good catch.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [RFC 3/3] ath10k: add support for HTT 3.0
From: Kalle Valo @ 2013-08-08 9:22 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, ath10k
In-Reply-To: <CA+BoTQnoVmQcMnajTx3vsKwct5PLCNOt6w2qo17fyigm=gO5-w@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 8 August 2013 11:05, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> This debug print is good to have, but with the new htt version it would
>> be good to print it always using the info level. For example, can we add
>> it to the same line with "firmware %s booted" string?
>
> HTT target version is not known when firmware boots up. It's not known
> until everything other (HTC, WMI) is set up. We then send a version
> request command and we get a response.
Oh, missed that.
> We need to print it in a separate line.
Or could we print the "firmware booted" message later?
>> (Please take into account that the info messages still need to be
>> compact, by default they should not be longer than five lines or so.)
>>
>>> + if (htt->target_version_major != 2 &&
>>> + htt->target_version_major != 3) {
>>> ath10k_err("htt major versions are incompatible!\n");
>>> return -ENOTSUPP;
>>> }
>>
>> Print the htt version in the error message as well?
>
> Target version is printed in ath10k_dbg() now. If we change that to
> ath10k_info() I don't see any reason to print the version again on
> error.
Frequently users just copy the error message, that's why it's better to
have the firmware's htt version in the error message as well.
> We may want to print the list of supported HTT major version numbers
> though?
That's good to have as well, at least in the debug messages.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 3/3] ath10k: add support for HTT 3.0
From: Michal Kazior @ 2013-08-08 9:29 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
In-Reply-To: <871u6435c6.fsf@kamboji.qca.qualcomm.com>
On 8 August 2013 11:22, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> On 8 August 2013 11:05, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>
>>> This debug print is good to have, but with the new htt version it would
>>> be good to print it always using the info level. For example, can we add
>>> it to the same line with "firmware %s booted" string?
>>
>> HTT target version is not known when firmware boots up. It's not known
>> until everything other (HTC, WMI) is set up. We then send a version
>> request command and we get a response.
>
> Oh, missed that.
>
>> We need to print it in a separate line.
>
> Or could we print the "firmware booted" message later?
I'm worried it may be error-prone in case of firmware loading failure
in-between (i.e. firmware is booted, but WMI init fails). We'd need to
print the firmware version in the error path then.
>
>>> (Please take into account that the info messages still need to be
>>> compact, by default they should not be longer than five lines or so.)
>>>
>>>> + if (htt->target_version_major != 2 &&
>>>> + htt->target_version_major != 3) {
>>>> ath10k_err("htt major versions are incompatible!\n");
>>>> return -ENOTSUPP;
>>>> }
>>>
>>> Print the htt version in the error message as well?
>>
>> Target version is printed in ath10k_dbg() now. If we change that to
>> ath10k_info() I don't see any reason to print the version again on
>> error.
>
> Frequently users just copy the error message, that's why it's better to
> have the firmware's htt version in the error message as well.
Good point.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [RFC 3/3] ath10k: add support for HTT 3.0
From: Kalle Valo @ 2013-08-08 9:42 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, ath10k
In-Reply-To: <CA+BoTQnsH6XxpgoBh0tTNCjXvNz-fL6OaCp=LP-Eap_4tqYNkw@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 8 August 2013 11:22, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> On 8 August 2013 11:05, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>
>>>> This debug print is good to have, but with the new htt version it would
>>>> be good to print it always using the info level. For example, can we add
>>>> it to the same line with "firmware %s booted" string?
>>>
>>> HTT target version is not known when firmware boots up. It's not known
>>> until everything other (HTC, WMI) is set up. We then send a version
>>> request command and we get a response.
>>
>> Oh, missed that.
>>
>>> We need to print it in a separate line.
>>
>> Or could we print the "firmware booted" message later?
>
> I'm worried it may be error-prone in case of firmware loading failure
> in-between (i.e. firmware is booted, but WMI init fails). We'd need to
> print the firmware version in the error path then.
True, let's just print in a separate line. We can worry about compacting
it later.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/4] ath10k: fix HTC endpoint worker starvation
From: Michal Kazior @ 2013-08-08 10:12 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949813-10969-3-git-send-email-michal.kazior@tieto.com>
On 8 August 2013 10:16, Michal Kazior <michal.kazior@tieto.com> wrote:
> HTC used a worker for each endpoint. This worked
> until a slow host machine was flooded with massive
> number of TX requests. HTT related worker would
> remain active while WMI worker was starved. This
> ended up with "could not send beacon" in AP mode.
> It was even possible to see userspace being
> starved.
>
> The patch switches from using workers to using
> tasklets for processing and submitting HTC frames
> to HIF.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> (...)
>
> @@ -602,7 +602,8 @@ static void ath10k_htc_reset_endpoint_states(struct ath10k_htc *htc)
> skb_queue_head_init(&ep->tx_queue);
> ep->htc = htc;
> ep->tx_credit_flow_enabled = true;
> - INIT_WORK(&ep->send_work, ath10k_htc_send_work);
> + tasklet_init(&ep->send_task, ath10k_htc_send_task,
> + (unsigned long)ep);
> }
> }
>
Indentation is off by one here. Is it okay if I just resend this
single patch or is it easier for applying if I resend the whole
patchset?
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* [RFC] mac80211: add support for split-MAC implementations
From: Johan Almbladh @ 2013-08-08 13:21 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Johan Almbladh
This patch enables power save processing for encrypted frames even if the
encryption key is not set. This is a requirement when implementing split-MAC
systems like Anyfi.net [1] and CAPWAP [2] on mac80211 using monitor frame
injection and reception. The mac80211 RX handlers are reordered slightly so
that the power save handler is invoked before the decryption handler.
The patch is minimal in the sense that it provides the required functionality
with a minimal change, but I am open to suggestions if this change is too
intrusive. Please let me know what you think.
[1] http://anyfi.net/documentation#architecture
[2] http://tools.ietf.org/html/rfc5416
Signed-off-by: Johan Almbladh <ja@anyfi.net>
---
net/mac80211/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 6b85f95..0f0017d 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2939,10 +2939,10 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
*/
rx->skb = skb;
- CALL_RXH(ieee80211_rx_h_decrypt)
CALL_RXH(ieee80211_rx_h_check_more_data)
CALL_RXH(ieee80211_rx_h_uapsd_and_pspoll)
CALL_RXH(ieee80211_rx_h_sta_process)
+ CALL_RXH(ieee80211_rx_h_decrypt)
CALL_RXH(ieee80211_rx_h_defragment)
CALL_RXH(ieee80211_rx_h_michael_mic_verify)
/* must be after MMIC verify so header is counted in MPDU mic */
--
1.7.9.5
^ permalink raw reply related
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-08-08 15:35 UTC (permalink / raw)
To: Christian Lamparter
Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless
In-Reply-To: <51F8B42F.102@rempel-privat.de>
[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]
Am 31.07.2013 08:52, schrieb Oleksij Rempel:
> Am 28.07.2013 22:41, schrieb Christian Lamparter:
>> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
>>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
>>>> Am 28.07.2013 13:38, schrieb Christian Lamparter:
>>>>
>>>>>> before rmmod.
>>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc"
>>>>> module
>>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>>>>>
>>>>> Furthermore, I did the same test with one of the ehci-only ports
>>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
>>>>> came back after autosuspend there.
>>>>
>>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
>>>> work here :( Suddenly i have no more ideas.
>>>>
>>>> Sarah, it's your turn now.
>>>
>>> Christian,
>>> can you please provide some more info about your xhci controller. I'll
>>> try to get me same.
>>
>> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
>> same setup will be difficult. However, since the uPD720200 was/is
>> very popular, it should be very easy to find one. [It's probably
>> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
>> got a free 1x-pcie port you should be good.]
>>
>> Here's the lspci summary:
>>
>> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
>> Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
>> Subsystem: Hewlett-Packard Company Device [103c:1657]
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
>> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 19
>> Region 0: Memory at d3400000 (64-bit, non-prefetchable)
>> [size=8K]
>> Capabilities: <access denied>
>> Kernel driver in use: xhci_hcd
>>
>
> Thx... i purchased on random on ebay, will see what i get.
>
> I know now why carl9170 don't triggering this bug. Carl uses EP4 as
> Interrupt with packet size 64. ath9k-htc initially have EP4=Intr,
> Interval=1, but will reconfigure it to Bulk, Interval=0.
> It mean, before usb suspend EP4=Bulk, Interval=0 and after resume
> EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may
> be interval stay 0, and xhci will overfill usb buffer on adapter - at
> least it looks so.
Christian,
can you please test one more patch. It is working for me, but who knows.
More testing is never bad idea ;)
--
Regards,
Oleksij
[-- Attachment #2: interval.diff --]
[-- Type: text/x-patch, Size: 510 bytes --]
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 5205a36..6f4f39c 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1053,7 +1053,7 @@ static int ath9k_hif_usb_dev_init(struct hif_device_usb *hif_dev)
== USB_ENDPOINT_XFER_INT) {
endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK;
endp->bmAttributes |= USB_ENDPOINT_XFER_BULK;
- endp->bInterval = 0;
+ // endp->bInterval = 0;
}
}
^ permalink raw reply related
* pull request: wireless 2013-08-08
From: John W. Linville @ 2013-08-08 17:29 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 12537 bytes --]
Dave,
This is a batch of fixes intended for the 3.11 queue...
Regarding the mac80211 (and related) bits, Johannes says:
"I have a fix from Chris for an infinite loop along with fixes from
myself to prevent it entering the loop to start with (continue using
disabled channels, many thanks to Chris for his debug/test help) and a
workaround for broken APs that advertise a bad HT primary channel in
their beacons. Additionally, a fix for another attrbuf race in mac80211
and a fix to clean up properly while P2P GO interfaces go down."
Along with that...
Solomon Peachy corrects a range check in cw1200 that would lead to
a BUG_ON when starting AP mode.
Stanislaw Gruszka provides an iwl4965 patch to power-up the device
earlier (avoiding microcode errors), and another iwl4965 fix that
resets the firmware after turning rfkill off (resolving a bug in the
Red Hat Bugzilla).
Please let me know if there are problems!
John
---
The following changes since commit 3e3be275851bc6fc90bfdcd732cd95563acd982b:
ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match (2013-08-07 17:17:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 1826ff2357d69d3a2627df51e4ba07d24087b698:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-08-08 13:12:42 -0400)
----------------------------------------------------------------
Chris Wright (1):
mac80211: fix infinite loop in ieee80211_determine_chantype
Johannes Berg (5):
nl80211: fix another nl80211_fam.attrbuf race
mac80211: don't wait for TX status forever
mac80211: ignore HT primary channel while connected
cfg80211: fix P2P GO interface teardown
mac80211: continue using disabled channels while connected
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Solomon Peachy (1):
cw1200: Fix spurious BUG_ON() trigger when starting AP mode.
Stanislaw Gruszka (2):
iwl4965: set power mode early
iwl4965: reset firmware after rfkill off
drivers/net/wireless/cw1200/sta.c | 7 ++---
drivers/net/wireless/iwlegacy/4965-mac.c | 16 +++++-----
drivers/net/wireless/iwlegacy/common.c | 1 +
net/mac80211/mlme.c | 54 +++++++++++++++++++++-----------
net/wireless/core.c | 1 +
net/wireless/nl80211.c | 6 ++--
6 files changed, 52 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/cw1200/sta.c b/drivers/net/wireless/cw1200/sta.c
index 7365674..010b252 100644
--- a/drivers/net/wireless/cw1200/sta.c
+++ b/drivers/net/wireless/cw1200/sta.c
@@ -1406,11 +1406,8 @@ static void cw1200_do_unjoin(struct cw1200_common *priv)
if (!priv->join_status)
goto done;
- if (priv->join_status > CW1200_JOIN_STATUS_IBSS) {
- wiphy_err(priv->hw->wiphy, "Unexpected: join status: %d\n",
- priv->join_status);
- BUG_ON(1);
- }
+ if (priv->join_status == CW1200_JOIN_STATUS_AP)
+ goto done;
cancel_work_sync(&priv->update_filtering_work);
cancel_work_sync(&priv->set_beacon_wakeup_period_work);
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index b9b2bb5..f2ed62e 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -4460,12 +4460,12 @@ il4965_irq_tasklet(struct il_priv *il)
* is killed. Hence update the killswitch state here. The
* rfkill handler will care about restarting if needed.
*/
- if (!test_bit(S_ALIVE, &il->status)) {
- if (hw_rf_kill)
- set_bit(S_RFKILL, &il->status);
- else
- clear_bit(S_RFKILL, &il->status);
+ if (hw_rf_kill) {
+ set_bit(S_RFKILL, &il->status);
+ } else {
+ clear_bit(S_RFKILL, &il->status);
wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill);
+ il_force_reset(il, true);
}
handled |= CSR_INT_BIT_RF_KILL;
@@ -5334,6 +5334,9 @@ il4965_alive_start(struct il_priv *il)
il->active_rate = RATES_MASK;
+ il_power_update_mode(il, true);
+ D_INFO("Updated power mode\n");
+
if (il_is_associated(il)) {
struct il_rxon_cmd *active_rxon =
(struct il_rxon_cmd *)&il->active;
@@ -5364,9 +5367,6 @@ il4965_alive_start(struct il_priv *il)
D_INFO("ALIVE processing complete.\n");
wake_up(&il->wait_command_queue);
- il_power_update_mode(il, true);
- D_INFO("Updated power mode\n");
-
return;
restart:
diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
index 3195aad..b03e22e 100644
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -4660,6 +4660,7 @@ il_force_reset(struct il_priv *il, bool external)
return 0;
}
+EXPORT_SYMBOL(il_force_reset);
int
il_mac_change_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ae31968..cc9e02d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,10 +31,12 @@
#include "led.h"
#define IEEE80211_AUTH_TIMEOUT (HZ / 5)
+#define IEEE80211_AUTH_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_AUTH_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_AUTH_WAIT_ASSOC (HZ * 5)
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
+#define IEEE80211_ASSOC_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_ASSOC_MAX_TRIES 3
@@ -209,8 +211,9 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel *channel,
const struct ieee80211_ht_operation *ht_oper,
const struct ieee80211_vht_operation *vht_oper,
- struct cfg80211_chan_def *chandef, bool verbose)
+ struct cfg80211_chan_def *chandef, bool tracking)
{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct cfg80211_chan_def vht_chandef;
u32 ht_cfreq, ret;
@@ -229,7 +232,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
ht_cfreq = ieee80211_channel_to_frequency(ht_oper->primary_chan,
channel->band);
/* check that channel matches the right operating channel */
- if (channel->center_freq != ht_cfreq) {
+ if (!tracking && channel->center_freq != ht_cfreq) {
/*
* It's possible that some APs are confused here;
* Netgear WNDR3700 sometimes reports 4 higher than
@@ -237,11 +240,10 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
* since we look at probe response/beacon data here
* it should be OK.
*/
- if (verbose)
- sdata_info(sdata,
- "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
- channel->center_freq, ht_cfreq,
- ht_oper->primary_chan, channel->band);
+ sdata_info(sdata,
+ "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
+ channel->center_freq, ht_cfreq,
+ ht_oper->primary_chan, channel->band);
ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
goto out;
}
@@ -295,7 +297,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
channel->band);
break;
default:
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT operation IE has invalid channel width (%d), disable VHT\n",
vht_oper->chan_width);
@@ -304,7 +306,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_valid(&vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information is invalid, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -317,7 +319,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_compatible(chandef, &vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information doesn't match HT, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -333,18 +335,27 @@ out:
if (ret & IEEE80211_STA_DISABLE_VHT)
vht_chandef = *chandef;
+ /*
+ * Ignore the DISABLED flag when we're already connected and only
+ * tracking the APs beacon for bandwidth changes - otherwise we
+ * might get disconnected here if we connect to an AP, update our
+ * regulatory information based on the AP's country IE and the
+ * information we have is wrong/outdated and disables the channel
+ * that we're actually using for the connection to the AP.
+ */
while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef,
- IEEE80211_CHAN_DISABLED)) {
+ tracking ? 0 :
+ IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) {
ret = IEEE80211_STA_DISABLE_HT |
IEEE80211_STA_DISABLE_VHT;
- goto out;
+ break;
}
ret |= chandef_downgrade(chandef);
}
- if (chandef->width != vht_chandef.width && verbose)
+ if (chandef->width != vht_chandef.width && !tracking)
sdata_info(sdata,
"capabilities/regulatory prevented using AP HT/VHT configuration, downgraded\n");
@@ -384,7 +395,7 @@ static int ieee80211_config_bw(struct ieee80211_sub_if_data *sdata,
/* calculate new channel (type) based on HT/VHT operation IEs */
flags = ieee80211_determine_chantype(sdata, sband, chan, ht_oper,
- vht_oper, &chandef, false);
+ vht_oper, &chandef, true);
/*
* Downgrade the new channel if we associated with restricted
@@ -3394,10 +3405,13 @@ static int ieee80211_probe_auth(struct ieee80211_sub_if_data *sdata)
if (tx_flags == 0) {
auth_data->timeout = jiffies + IEEE80211_AUTH_TIMEOUT;
- ifmgd->auth_data->timeout_started = true;
+ auth_data->timeout_started = true;
run_again(sdata, auth_data->timeout);
} else {
- auth_data->timeout_started = false;
+ auth_data->timeout =
+ round_jiffies_up(jiffies + IEEE80211_AUTH_TIMEOUT_LONG);
+ auth_data->timeout_started = true;
+ run_again(sdata, auth_data->timeout);
}
return 0;
@@ -3434,7 +3448,11 @@ static int ieee80211_do_assoc(struct ieee80211_sub_if_data *sdata)
assoc_data->timeout_started = true;
run_again(sdata, assoc_data->timeout);
} else {
- assoc_data->timeout_started = false;
+ assoc_data->timeout =
+ round_jiffies_up(jiffies +
+ IEEE80211_ASSOC_TIMEOUT_LONG);
+ assoc_data->timeout_started = true;
+ run_again(sdata, assoc_data->timeout);
}
return 0;
@@ -3829,7 +3847,7 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
ifmgd->flags |= ieee80211_determine_chantype(sdata, sband,
cbss->channel,
ht_oper, vht_oper,
- &chandef, true);
+ &chandef, false);
sdata->needed_rx_chains = min(ieee80211_ht_vht_rx_chains(sdata, cbss),
local->rx_chains);
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 4f9f216..a8c29fa 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -765,6 +765,7 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev,
cfg80211_leave_mesh(rdev, dev);
break;
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_P2P_GO:
cfg80211_stop_ap(rdev, dev);
break;
default:
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 25d217d..3fcba69 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -441,10 +441,12 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
goto out_unlock;
}
*rdev = wiphy_to_dev((*wdev)->wiphy);
- cb->args[0] = (*rdev)->wiphy_idx;
+ /* 0 is the first index - add 1 to parse only once */
+ cb->args[0] = (*rdev)->wiphy_idx + 1;
cb->args[1] = (*wdev)->identifier;
} else {
- struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0]);
+ /* subtract the 1 again here */
+ struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0] - 1);
struct wireless_dev *tmp;
if (!wiphy) {
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Linux Wireless Mini-Summit in New Orleans -- 19-20 September (6 weeks from today!)
From: John W. Linville @ 2013-08-08 18:54 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, marcel, Samuel Ortiz, Gustavo Padovan
Greetings!
This is a reminder that we will have a Linux Wireless Mini-Summit in
New Orleans this year on 19-20 September. This will immediately follow
LinuxCon and will run concurrently with Linux Plumber's Conference.
This event includes Linux developers for wireless LAN (802.11),
Bluetooth, and NFC technologies. Both kernel and userland developers
are welcomed and heartily encouraged to attend!
http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
The link above is a Wiki. We are using it to collect discussion
topics and to negotiate agenda/scheduling options for the event.
Please go there to record your intent to attend the event and to
propopse topics for discussion.
Please be aware that in order to attend the event above one must
register for either LinuxCon or for Linux Plumbers Conference.
Act now, before those events fill-up and close their registrations!
We are allotted one "large" room (up to ~80 people "theater style"), and
two "small" rooms (up to ~25 people) for this event. Based on history
and the numbers of contributors, the larger room will primarily be
for the 802.11 discussions and any "plenary" topics while the smaller
rooms will be for Bluetooth, NFC, and any "breakout" topics.
So...thoughts? Topics to discuss?
John
--
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: Linux Wireless Mini-Summit in New Orleans -- 19-20 September (6 weeks from today!)
From: John W. Linville @ 2013-08-08 19:04 UTC (permalink / raw)
To: linux-wireless
Cc: johannes, marcel, Samuel Ortiz, Gustavo Padovan, linux-bluetooth,
linux-nfc
In-Reply-To: <20130808185410.GD30925@tuxdriver.com>
Sorry, forgot to copy linux-bluetooth and linux-nfc...
On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
> Greetings!
>
> This is a reminder that we will have a Linux Wireless Mini-Summit in
> New Orleans this year on 19-20 September. This will immediately follow
> LinuxCon and will run concurrently with Linux Plumber's Conference.
> This event includes Linux developers for wireless LAN (802.11),
> Bluetooth, and NFC technologies. Both kernel and userland developers
> are welcomed and heartily encouraged to attend!
>
> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>
> The link above is a Wiki. We are using it to collect discussion
> topics and to negotiate agenda/scheduling options for the event.
> Please go there to record your intent to attend the event and to
> propopse topics for discussion.
>
> Please be aware that in order to attend the event above one must
> register for either LinuxCon or for Linux Plumbers Conference.
> Act now, before those events fill-up and close their registrations!
>
> We are allotted one "large" room (up to ~80 people "theater style"), and
> two "small" rooms (up to ~25 people) for this event. Based on history
> and the numbers of contributors, the larger room will primarily be
> for the 802.11 discussions and any "plenary" topics while the smaller
> rooms will be for Bluetooth, NFC, and any "breakout" topics.
>
> So...thoughts? Topics to discuss?
>
> John
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: FUSB200 xhci issue
From: Christian Lamparter @ 2013-08-08 19:09 UTC (permalink / raw)
To: Oleksij Rempel, Alan Stern
Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless
In-Reply-To: <5203BAC6.8070905@rempel-privat.de>
On Thursday 08 August 2013 17:35:34 Oleksij Rempel wrote:
> Am 31.07.2013 08:52, schrieb Oleksij Rempel:
> > Am 28.07.2013 22:41, schrieb Christian Lamparter:
> >> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
> >>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
> >>>> Am 28.07.2013 13:38, schrieb Christian Lamparter:
> >>>>
> >>>>>> before rmmod.
> >>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc"
> >>>>> module
> >>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
> >>>>>
> >>>>> Furthermore, I did the same test with one of the ehci-only ports
> >>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
> >>>>> came back after autosuspend there.
> >>>>
> >>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
> >>>> work here :( Suddenly i have no more ideas.
> >>>>
> >>>> Sarah, it's your turn now.
> >>>
> >>> Christian,
> >>> can you please provide some more info about your xhci controller. I'll
> >>> try to get me same.
> >>
> >> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
> >> same setup will be difficult. However, since the uPD720200 was/is
> >> very popular, it should be very easy to find one. [It's probably
> >> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
> >> got a free 1x-pcie port you should be good.]
> >>
> >> Here's the lspci summary:
> >>
> >> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
> >> Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
> >> Subsystem: Hewlett-Packard Company Device [103c:1657]
> >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> >> ParErr- Stepping- SERR- FastB2B- DisINTx+
> >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
> >> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> Latency: 0, Cache Line Size: 64 bytes
> >> Interrupt: pin A routed to IRQ 19
> >> Region 0: Memory at d3400000 (64-bit, non-prefetchable)
> >> [size=8K]
> >> Capabilities: <access denied>
> >> Kernel driver in use: xhci_hcd
> >>
> >
> > Thx... i purchased on random on ebay, will see what i get.
> >
> > I know now why carl9170 don't triggering this bug. Carl uses EP4 as
> > Interrupt with packet size 64. ath9k-htc initially have EP4=Intr,
> > Interval=1, but will reconfigure it to Bulk, Interval=0.
> > It mean, before usb suspend EP4=Bulk, Interval=0 and after resume
> > EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may
> > be interval stay 0, and xhci will overfill usb buffer on adapter - at
> > least it looks so.
>
> Christian,
> can you please test one more patch. It is working for me, but who knows.
> More testing is never bad idea ;)
It sort of works, but not without a hiccup:
I get the following messages when I try to load the driver
again after an autosuspend cycle (ar9271, NEC xhci):
ath: phy6: Reading Magic # failed
ath9k_htc: Failed to Initialize the device
usb 2-1: ath9k_htc: USB layer deinitialized
....
However, the device is resetted automatically and it
comes back on the second probe attempt.
Anyway, I do have a question about something else too.
in ath9k_htc's hif_usb:
> struct usb_host_interface *alt = &hif_dev->interface->altsetting[0];
> struct usb_endpoint_descriptor *endp;
> ...
> /* On downloading the firmware to the target, the USB descriptor of EP4
> * is 'patched' to change the type of the endpoint to Bulk. This will
> * bring down CPU usage during the scan period. */
>
> for (idx = 0; idx < alt->desc.bNumEndpoints; idx++) {
> endp = &alt->endpoint[idx].desc;
> if ((endp->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT) {
> endp->bmAttributes &= ~USB_ENDPOINT_XFERTYPE_MASK;
> endp->bmAttributes |= USB_ENDPOINT_XFER_BULK;
>// endp->bInterval = 0;
> }
> }
Alan, can you please tell us, if it is really safe to
override the bmAttributes this way? After all (according to
the comment) the device has "morphed" (EP4 has changed).
Or, is it necessary for the driver call "usb_reset_device"
or (usb_reset_configuration) in this case?
Regards,
Chr
^ 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