Re: [ath9k-devel] [PATCH 1/2] ath10k: Move debug structures to debug.h
Sujith Manoharan writes: > From: Sujith Manoharan > > Signed-off-by: Sujith Manoharan I would like to have have all struct ath10k substructures in core.h so that they don't get too much spread around. Hence I need to drop this patch. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 2/2] ath10k: Add host statistics
Sujith Manoharan writes:
> From: Sujith Manoharan
>
> Signed-off-by: Sujith Manoharan
[...]
> +static ssize_t ath10k_read_host_stats(struct file *file, char __user
> *user_buf,
> + size_t count, loff_t *ppos)
> +{
[...]
> + if (len > buf_len)
> + len = buf_len;
min()/min_t()?
> +#ifdef CONFIG_ATH10K_DEBUGFS
> +#define HOST_STAT_INC(c) ar->debug.host_stats.c++
> +#else
> +#define HOST_STAT_INC(c) do { } while (0)
> +#endif
Please add ATH10K_ prefix and argument for ar. Also we already have the
same ifdef for few debug functions which you can reuse, no need to add
new ifdef.
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC/RFT 1/2] ath10k: WMI add AP PS
Janusz Dziedzic writes:
> Add AP power save (UAPSD) structures, enums.
>
> Signed-off-by: Janusz Dziedzic
> ---
> drivers/net/wireless/ath/ath10k/wmi.c | 26 +
> drivers/net/wireless/ath/ath10k/wmi.h | 67
> +
> 2 files changed, 93 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
> b/drivers/net/wireless/ath/ath10k/wmi.c
> index 5272f18..453138b 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -1850,6 +1850,32 @@ int ath10k_wmi_set_sta_ps_param(struct ath10k *ar, u32
> vdev_id,
> return ath10k_wmi_cmd_send(ar, skb, WMI_STA_POWERSAVE_PARAM_CMDID);
> }
>
> +int ath10k_wmi_set_ap_ps_param(struct ath10k *ar, u32 vdev_id, const u8 *mac,
> +enum wmi_ap_ps_peer_param param_id, u32 value)
> +{
[...]
> + cmd->vdev_id = __cpu_to_le32(vdev_id);
> + cmd->param_id= __cpu_to_le32(param_id);
> + cmd->param_value = __cpu_to_le32(value);
No extra whitespace before '='.
> + memcpy(&cmd->peer_macaddr, mac, ETH_ALEN);
> +
> + ath10k_dbg(ATH10K_DBG_WMI,
> +"wmi ap ps param vdev_id 0x%X param %d value %d "
> +"mac_addr %pM\n", vdev_id, param_id, value, mac);
Don't split the format string into two. The long line limit doesn't
apply to logging format strings.
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
> b/drivers/net/wireless/ath/ath10k/wmi.h
> index 9946a51..b9f5b62 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -2397,6 +2397,71 @@ struct wmi_sta_mimo_ps_mode_cmd {
> __le32 mimo_pwrsave_mode;
> } __packed;
>
> +
Extra empty line.
> +/* U-APSD maximum service period of peer station */
> +enum wmi_ap_ps_peer_param_max_sp {
> + WMI_AP_PS_PEER_PARAM_MAX_SP_UNLIMITED = 0,
> + WMI_AP_PS_PEER_PARAM_MAX_SP_2 = 1,
> + WMI_AP_PS_PEER_PARAM_MAX_SP_4 = 2,
> + WMI_AP_PS_PEER_PARAM_MAX_SP_6 = 3,
> + /* keep last! */
Empty line before the comment.
> +struct wmi_ap_ps_peer_cmd {
> + /** unique id identifying the VDEV, generated by the caller */
> + __le32 vdev_id;
> + /** peer MAC address */
> + struct wmi_mac_addr peer_macaddr;
> + /** AP powersave param (see enum wmi_ap_ps_peer_param) */
> + __le32 param_id;
> + /** AP powersave param value */
> + __le32 param_value;
> +} __packed;
Empty line before the comments, except the first one.
Also there are new warnings:
drivers/net/wireless/ath/ath10k/wmi.h:2494: WARNING: line over 80 characters
drivers/net/wireless/ath/ath10k/wmi.h:2514: WARNING: line over 80 characters
drivers/net/wireless/ath/ath10k/wmi.c:1924: CHECK: No space is necessary after
a cast
drivers/net/wireless/ath/ath10k/mac.c:906: CHECK: Blank lines aren't necessary
after an open brace '{'
drivers/net/wireless/ath/ath10k/mac.c:908: WARNING: quoted string split across
lines
drivers/net/wireless/ath/ath10k/mac.c:913: WARNING: line over 80 characters
drivers/net/wireless/ath/ath10k/mac.c:916: WARNING: line over 80 characters
drivers/net/wireless/ath/ath10k/mac.c:919: WARNING: line over 80 characters
drivers/net/wireless/ath/ath10k/mac.c:922: WARNING: line over 80 characters
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath10k: Move debug structures to debug.h
Kalle Valo wrote: > I would like to have have all struct ath10k substructures in core.h so > that they don't get too much spread around. Hence I need to drop this > patch. debug.h seems an appropriate place to have debug-specific structures. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC/RFT 2/2] ath10k: add AP UAPSD support
Janusz Dziedzic writes: > Add support for AP (P2P_GO) UAPSD. > > Signed-off-by: Janusz Dziedzic [...] > + ath10k_dbg(ATH10K_DBG_MAC, "uapsd_queues: 0x%X, " > +"max_sp: %d\n", sta->uapsd_queues, > +sta->max_sp); Splitted format string. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] uart interface issues (fixed)
Am 02.05.2013 09:15, schrieb Eugene Krasnikov: > Hi Oleksij, > > Have you tried remote debugging? Or it's only about garbing logs from > the chip. Have you tried to send commands to the chip? Yes, it works. You need this resistors to make chip start with ttl adapter attached. Without them this chip may not start. > 2013/5/2 Oleksij Rempel : >> Am 28.04.2013 16:17, schrieb Oleksij Rempel: >>> >>> Am 28.04.2013 13:38, schrieb Adrian Chadd: .. is it triggering BREAK interrupts or something? >>> >>> >>> I don't know, there is no serial output on this stage. JTAG may help if >>> the protocol is some how similar to EJTAG. Are there any documentation >>> about Xtensa dubug interface ;)? >>> I will need to dig in it, but not this week. >>> >>> That may be something that the boot ROM code interprets as a magical "don't start" sequence or something. >> >> >> So, this issue is fixed now. >> >> ttl TX >--[2K]o RX pin on AR7010 >> |[4K pull up]---< 3,3V >> >> In attachment are pictures from my setup ;) >> >> -- >> Regards, >> Oleksij > > > -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/8] ath10k: cleanup ath10k_core_unregister()
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/core.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 13ffe78..a3afb79 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -615,21 +615,13 @@ EXPORT_SYMBOL(ath10k_core_register);
void ath10k_core_unregister(struct ath10k *ar)
{
- /*
-* FIXME: the ordering here may be broken!
-*mac_unregister must be done before htc is stopped,
-*since it might want to remove interfaces -> vdev_remove
-*/
+ /* We must unregister from mac80211 before we stop HTC and HIF.
+* Otherwise we will fail to submit commands to FW and mac80211 will be
+* unhappy about callback failures. */
ath10k_mac_unregister(ar);
-
- if (!WARN_ON(!ar->htc))
- ath10k_htc_stop(ar->htc);
-
- /* FIXME: we may need to free up htt tx desc here too */
+ ath10k_htc_stop(ar->htc);
ath10k_htt_detach(ar->htt);
-
ath10k_wmi_detach(ar);
-
ath10k_htc_destroy(ar->htc);
}
EXPORT_SYMBOL(ath10k_core_unregister);
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 2/8] ath10k: document some spinlocks
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/htt.h |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 63beff5..dc1f88d 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1254,15 +1254,14 @@ struct ath10k_htt {
*/
struct timer_list refill_retry_timer;
- /* FIXME: document what this protects */
+ /* Protects access to all rx ring buffer state variables */
spinlock_t lock;
} rx_ring;
unsigned int prefetch_len;
- /* FIXME: document what this protects */
+ /* Protects access to %pending_tx, %used_msdu_ids */
spinlock_t tx_lock;
-
struct sk_buff *pending_tx[HTT_MAX_NUM_PENDING_TX];
DECLARE_BITMAP(used_msdu_ids, HTT_MAX_NUM_PENDING_TX);
wait_queue_head_t empty_tx_wq;
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/8] ath10k: fixes
Here's a bunch of fixes that get rid of a few FIXMEs and plug some memleaks on driver setup failure paths. Michal Kazior (8): ath10k: cleanup ath10k_core_unregister() ath10k: document some spinlocks ath10k: remove old irrelevant FIXMEs ath10k: handle CE init failure ath10k: handle rx pipe post failure ath10k: handle CE start failure ath10k: print warning on ep0 htc rx ath10k: free skb if ath10k_htc_send() fails drivers/net/wireless/ath/ath10k/ce.c |2 + drivers/net/wireless/ath/ath10k/core.c | 16 ++- drivers/net/wireless/ath/ath10k/hif.h |4 +- drivers/net/wireless/ath/ath10k/htc.c | 39 - drivers/net/wireless/ath/ath10k/htt.h |7 +-- drivers/net/wireless/ath/ath10k/pci.c | 74 6 files changed, 94 insertions(+), 48 deletions(-) -- 1.7.9.5 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 3/8] ath10k: remove old irrelevant FIXMEs
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/htt.h |2 --
drivers/net/wireless/ath/ath10k/pci.c |1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index dc1f88d..f3c22df 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1332,8 +1332,6 @@ struct htt_rx_desc {
#define HTT_LOG2_MAX_CACHE_LINE_SIZE 7 /* 2^7 = 128 */
#define HTT_MAX_CACHE_LINE_SIZE_MASK ((1 << HTT_LOG2_MAX_CACHE_LINE_SIZE) - 1)
-/* FIXME: add htt_tx_desc_init() */
-
struct ath10k_htt *ath10k_htt_attach(struct ath10k *ar);
int ath10k_htt_attach_target(struct ath10k_htt *htt);
void ath10k_htt_detach(struct ath10k_htt *htt);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index e85d806..6b37253 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2142,7 +2142,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
*/
ret = pci_assign_resource(pdev, BAR_NUM);
if (ret) {
- /* FIXME: do we need to free something in error path? */
ath10k_err("cannot assign PCI space: %d\n", ret);
goto err_ar;
}
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 4/8] ath10k: handle CE init failure
Fixes possible memleak.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/ce.c |2 ++
drivers/net/wireless/ath/ath10k/pci.c | 14 +++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c
b/drivers/net/wireless/ath/ath10k/ce.c
index 3ef7f39..61a8ac7 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1134,6 +1134,7 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
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);
+ ath10k_ce_deinit(ce_state);
return NULL;
}
}
@@ -1142,6 +1143,7 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
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);
+ ath10k_ce_deinit(ce_state);
return NULL;
}
}
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 6b37253..dc4e2ed 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1618,7 +1618,7 @@ static int ath10k_pci_init_config(struct ath10k *ar)
-static void ath10k_pci_ce_init(struct ath10k *ar)
+static int ath10k_pci_ce_init(struct ath10k *ar)
{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
struct hif_ce_pipe_info *pipe_info;
@@ -1633,9 +1633,13 @@ static void ath10k_pci_ce_init(struct ath10k *ar)
pipe_info->ce_hdl = ath10k_ce_init(ar, pipe_num, attr);
if (pipe_info->ce_hdl == NULL) {
- /* FIXME: Handle error */
ath10k_err("Unable to initialize CE for pipe: %d\n",
pipe_num);
+
+ /* It is safe to call it here. It checks if ce_hdl is
+* valid for each pipe */
+ ath10k_pci_ce_deinit(ar);
+ return -1;
}
if (pipe_num == ar_pci->ce_count - 1) {
@@ -1662,6 +1666,8 @@ static void ath10k_pci_ce_init(struct ath10k *ar)
pipe_info = &ar_pci->pipe_info[BMI_CE_NUM_TO_HOST];
ath10k_ce_recv_cb_register(pipe_info->ce_hdl,
ath10k_pci_bmi_recv_data);
+
+ return 0;
}
static void ath10k_pci_fw_interrupt_handler(struct ath10k *ar)
@@ -2229,7 +2235,9 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
ath10k_do_pci_wake(ar);
}
- ath10k_pci_ce_init(ar);
+ ret = ath10k_pci_ce_init(ar);
+ if (ret)
+ goto err_intr;
ret = ath10k_pci_init_config(ar);
if (ret)
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 6/8] ath10k: handle CE start failure
Fixes possible memleak.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/pci.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 7efdaf1..ca09a44 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -53,6 +53,7 @@ static int ath10k_pci_post_rx(struct ath10k *ar);
static int ath10k_pci_post_rx_pipe(struct hif_ce_pipe_info *pipe_info,
int num);
static void ath10k_pci_rx_pipe_cleanup(struct hif_ce_pipe_info *pipe_info);
+static void ath10k_pci_stop_ce(struct ath10k *ar);
static const struct ce_attr host_ce_config_wlan[] = {
/* host->target HTC control and raw streams */
@@ -756,7 +757,7 @@ static void ath10k_pci_hif_post_init(struct ath10k *ar,
sizeof(ar_pci->msg_callbacks_current));
}
-static void ath10k_pci_start_ce(struct ath10k *ar)
+static int ath10k_pci_start_ce(struct ath10k *ar)
{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
struct ce_state *ce_diag = ar_pci->ce_diag;
@@ -804,13 +805,16 @@ static void ath10k_pci_start_ce(struct ath10k *ar)
GFP_KERNEL);
if (!compl) {
ath10k_warn("No memory for completion state\n");
- break;
+ ath10k_pci_stop_ce(ar);
+ return -ENOMEM;
}
compl->send_or_recv = HIF_CE_COMPLETE_FREE;
list_add_tail(&compl->list, &pipe_info->compl_free);
}
}
+
+ return 0;
}
static void ath10k_pci_stop_ce(struct ath10k *ar)
@@ -1113,7 +1117,11 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
int ret;
- ath10k_pci_start_ce(ar);
+ ret = ath10k_pci_start_ce(ar);
+ if (ret) {
+ ath10k_warn("could not start CE (%d)\n", ret);
+ return ret;
+ }
/* Post buffers once to start things off. */
ret = ath10k_pci_post_rx(ar);
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 5/8] ath10k: handle rx pipe post failure
Fixes possible memleak.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/hif.h |4 +--
drivers/net/wireless/ath/ath10k/htc.c | 23 -
drivers/net/wireless/ath/ath10k/pci.c | 45 -
3 files changed, 52 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/hif.h
b/drivers/net/wireless/ath/ath10k/hif.h
index 6983a0c..73a24d4 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -46,7 +46,7 @@ struct ath10k_hif_ops {
void *request, u32 request_len,
void *response, u32 *response_len);
- void (*start)(struct ath10k *ar);
+ int (*start)(struct ath10k *ar);
void (*stop)(struct ath10k *ar);
@@ -89,7 +89,7 @@ static inline int ath10k_hif_exchange_bmi_msg(struct ath10k
*ar,
response, response_len);
}
-static inline void ath10k_hif_start(struct ath10k *ar)
+static inline int ath10k_hif_start(struct ath10k *ar)
{
return ar->hif.ops->start(ar);
}
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index 60f471c..c7ff5c3 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -708,7 +708,11 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
INIT_COMPLETION(htc->ctl_resp);
- ath10k_hif_start(htc->ar);
+ status = ath10k_hif_start(htc->ar);
+ if (status) {
+ ath10k_err("could not start HIF (%d)\n", status);
+ goto err_start;
+ }
status = wait_for_completion_timeout(&htc->ctl_resp,
ATH10K_HTC_WAIT_TIMEOUT_HZ);
@@ -717,7 +721,7 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
status = -ETIMEDOUT;
ath10k_err("ctl_resp never came in (%d)\n", status);
- goto fail_wait_target;
+ goto err_target;
}
if (htc->control_resp_len < sizeof(msg->hdr) + sizeof(msg->ready)) {
@@ -725,7 +729,7 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
htc->control_resp_len);
status = -ECOMM;
- goto fail_wait_target;
+ goto err_target;
}
msg = (struct ath10k_htc_msg *)htc->control_resp_buffer;
@@ -736,7 +740,7 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
if (message_id != ATH10K_HTC_MSG_READY_ID) {
ath10k_err("Invalid HTC ready msg: 0x%x\n", message_id);
status = -ECOMM;
- goto fail_wait_target;
+ goto err_target;
}
htc->total_transmit_credits = credit_count;
@@ -751,7 +755,7 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
(htc->target_credit_size == 0)) {
status = -ECOMM;
ath10k_err("Invalid credit size received\n");
- goto fail_wait_target;
+ goto err_target;
}
ath10k_htc_setup_target_buffer_assignments(htc);
@@ -766,8 +770,15 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
/* connect fake service */
status = ath10k_htc_connect_service(htc, &conn_req, &conn_resp);
+ if (status) {
+ ath10k_err("could not connect to htc service (%d)\n", status);
+ goto err_target;
+ }
-fail_wait_target:
+ return 0;
+err_target:
+ ath10k_hif_stop(htc->ar);
+err_start:
return status;
}
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index dc4e2ed..7efdaf1 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -52,6 +52,7 @@ static void ath10k_pci_process_ce(struct ath10k *ar);
static int ath10k_pci_post_rx(struct ath10k *ar);
static int ath10k_pci_post_rx_pipe(struct hif_ce_pipe_info *pipe_info,
int num);
+static void ath10k_pci_rx_pipe_cleanup(struct hif_ce_pipe_info *pipe_info);
static const struct ce_attr host_ce_config_wlan[] = {
/* host->target HTC control and raw streams */
@@ -1035,9 +1036,10 @@ static int ath10k_pci_post_rx_pipe(struct
hif_ce_pipe_info *pipe_info,
for (i = 0; i < num; i++) {
skb = dev_alloc_skb(pipe_info->buf_sz);
if (!skb) {
- ath10k_warn("%s: Memory allocation failure\n",
- __func__);
- return -ENOMEM;
+ ath10k_warn("could not allocate skbuff for pipe %d\n",
+ num);
+ ret = -ENOMEM;
+ goto err;
}
WARN_ONCE((unsigned long)skb->data & 3, "unaligned skb");
@@ -1047,9 +1049,10 @@ static int ath10k_pci_post_rx_pipe
[ath9k-devel] [PATCH 7/8] ath10k: print warning on ep0 htc rx
Fixes possible memleak.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/htc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index c7ff5c3..163ddc9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -608,8 +608,10 @@ out:
static void ath10k_htc_control_rx_complete(struct ath10k *ar,
struct sk_buff *skb)
{
- /* TODO, can't receive HTC control messages yet */
- ath10k_dbg(ATH10K_DBG_HTC, "Invalid call to %s\n", __func__);
+ /* This is unexpected. FW is not supposed to send regular rx on this
+* endpoint. */
+ ath10k_warn("unexpected htc rx\n");
+ kfree_skb(skb);
}
/***/
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 8/8] ath10k: free skb if ath10k_htc_send() fails
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/htc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index 163ddc9..22abc6f 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -845,8 +845,10 @@ int ath10k_htc_connect_service(struct ath10k_htc *htc,
INIT_COMPLETION(htc->ctl_resp);
status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb);
- if (status)
+ if (status) {
+ kfree_skb(skb);
return status;
+ }
/* wait for response */
status = wait_for_completion_timeout(&htc->ctl_resp,
@@ -989,8 +991,12 @@ int ath10k_htc_start(struct ath10k_htc *htc)
ath10k_dbg(ATH10K_DBG_HTC, "HTC is using TX credit flow control\n");
status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb);
+ if (status) {
+ kfree_skb(skb);
+ return status;
+ }
- return status;
+ return 0;
}
/*
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] uart interface issues (fixed)
What kind of commands did you try to send? I will try the same with my dongle and update you if that works or not;) 2013/5/2 Oleksij Rempel : > Am 02.05.2013 09:15, schrieb Eugene Krasnikov: > >> Hi Oleksij, >> >> Have you tried remote debugging? Or it's only about garbing logs from >> the chip. Have you tried to send commands to the chip? > > > Yes, it works. You need this resistors to make chip start with ttl adapter > attached. Without them this chip may not start. > > >> 2013/5/2 Oleksij Rempel : >>> >>> Am 28.04.2013 16:17, schrieb Oleksij Rempel: Am 28.04.2013 13:38, schrieb Adrian Chadd: > > > .. is it triggering BREAK interrupts or something? I don't know, there is no serial output on this stage. JTAG may help if the protocol is some how similar to EJTAG. Are there any documentation about Xtensa dubug interface ;)? I will need to dig in it, but not this week. > That may be something that the boot ROM code interprets as a magical > "don't start" sequence or something. >>> >>> >>> >>> So, this issue is fixed now. >>> >>> ttl TX >--[2K]o RX pin on AR7010 >>> |[4K pull up]---< 3,3V >>> >>> In attachment are pictures from my setup ;) >>> >>> -- >>> Regards, >>> Oleksij >> >> >> >> > > > -- > Regards, > Oleksij -- Best regards, Eugene ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v3] ath10k: Remove unneeded locks during HTT RX attach
Sujith Manoharan writes: > From: Sujith Manoharan > > Fix two issues: > > * Bail out properly when RX buffer allocation fails at init time. > * Do not acquire the rx ring lock during attach() since we > don't rearm the replenish timer. > > Signed-off-by: Sujith Manoharan Thanks, applied. There were conflicts and sha1 ids did not match so I had to fix the conflicts manually. Please check my changes. Also please try to fix your setup so that sha1 ids are valid in the patches. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] uart interface issues (fixed)
Am 02.05.2013 09:22, schrieb Eugene Krasnikov: > What kind of commands did you try to send? I will try the same with my > dongle and update you if that works or not;) all command are here: ./target_firmware/magpie_fw_dev/target/cmnos/dbg_api.c working commands: help info ram wdt rst (restart system) wdt off (turn off watchdog) wdt on (...) memdmp 5 50010 (memdump of 0x5 0x50010 area) be careful with memdmp command. If watchdog enabled i can be triggered on memdmp, so disable it. If you hit some prottected memory area, system on chip will oops. > 2013/5/2 Oleksij Rempel : >> Am 02.05.2013 09:15, schrieb Eugene Krasnikov: >> >>> Hi Oleksij, >>> >>> Have you tried remote debugging? Or it's only about garbing logs from >>> the chip. Have you tried to send commands to the chip? >> >> >> Yes, it works. You need this resistors to make chip start with ttl adapter >> attached. Without them this chip may not start. >> >> >>> 2013/5/2 Oleksij Rempel : Am 28.04.2013 16:17, schrieb Oleksij Rempel: > > > Am 28.04.2013 13:38, schrieb Adrian Chadd: >> >> >> .. is it triggering BREAK interrupts or something? > > > > I don't know, there is no serial output on this stage. JTAG may help if > the protocol is some how similar to EJTAG. Are there any documentation > about Xtensa dubug interface ;)? > I will need to dig in it, but not this week. > > >> That may be something that the boot ROM code interprets as a magical >> "don't start" sequence or something. So, this issue is fixed now. ttl TX >--[2K]o RX pin on AR7010 |[4K pull up]---< 3,3V In attachment are pictures from my setup ;) -- Regards, Oleksij >>> >>> >>> >>> >> >> >> -- >> Regards, >> Oleksij > > > -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath10k: Fix TXOP handling
Sujith Manoharan writes: > Kalle Valo wrote: >> Please add a comment. > > [PATCH v2] ath10k: Fix TXOP handling I had to edit these out manually. This kind of comments should be after '--' so that git-am can rip them out manually. > The channel time duration programmed in the HW is in absolute microseconds, > while mac80211 gives the txop in units of 32 microseconds. Handle this > properly. > > Signed-off-by: Sujith Manoharan Thanks, applied. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath10k: unify header inclusion guard names
Bartosz Markowski writes: > Signed-off-by: Bartosz Markowski Thanks, applied. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath10k: Move debug structures to debug.h
Sujith Manoharan writes: > Kalle Valo wrote: >> I would like to have have all struct ath10k substructures in core.h so >> that they don't get too much spread around. Hence I need to drop this >> patch. > > debug.h seems an appropriate place to have debug-specific structures. The idea is that everything within ar variable can be found from core.h. That way people don't need to track down where it's actually defined. -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] uart interface issues (fixed)
Hi Oleksij, Have you tried remote debugging? Or it's only about garbing logs from the chip. Have you tried to send commands to the chip? 2013/5/2 Oleksij Rempel : > Am 28.04.2013 16:17, schrieb Oleksij Rempel: >> >> Am 28.04.2013 13:38, schrieb Adrian Chadd: >>> >>> .. is it triggering BREAK interrupts or something? >> >> >> I don't know, there is no serial output on this stage. JTAG may help if >> the protocol is some how similar to EJTAG. Are there any documentation >> about Xtensa dubug interface ;)? >> I will need to dig in it, but not this week. >> >> >>> That may be something that the boot ROM code interprets as a magical >>> "don't start" sequence or something. > > > So, this issue is fixed now. > > ttl TX >--[2K]o RX pin on AR7010 > |[4K pull up]---< 3,3V > > In attachment are pictures from my setup ;) > > -- > Regards, > Oleksij -- Best regards, Eugene ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 02/20] ath10k: Merge mac.h with core.h
Sujith Manoharan writes: > Kalle Valo wrote: >> Why do you want to delete mac.h? My idea was to avoid bloating core.h >> and that's why I wanted to have header files for each .c file. > > mac.h contains a few prototypes and most of the data structures are in core.h. > I don't think core.h is getting bloated, it has barely 300+ lines. Yes, it has 300+ lines now as I have enforced that it's not abused. But if I I let everything go to core.h how long will it end up then? Besides, I can't see what harm having mac.h brings? -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath10k: Move debug structures to debug.h
Kalle Valo wrote: > The idea is that everything within ar variable can be found from core.h. > That way people don't need to track down where it's actually defined. That doesn't seem to be the way things are organized. "ar" contains instances of HTT, HTC, WMI, BMI, HIF - which all have separate header files. Likewise, having a self-contained debug header files makes things cleaner, IMO. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/2] work sync
Hello all, this patches currently pending for review or ack. Can please some one do it untill i forgt them :) Oleksij Rempel (2): ath9k_htc: add STBC TX support ath9k: remove useless flag conversation. drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++-- drivers/net/wireless/ath/ath9k/htc.h | 2 ++ drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++ drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 drivers/net/wireless/ath/ath9k/mac.c | 11 +++ drivers/net/wireless/ath/ath9k/mac.h | 1 + drivers/net/wireless/ath/ath9k/recv.c | 5 + 7 files changed, 21 insertions(+), 10 deletions(-) -- 1.8.1.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
Signed-off-by: Oleksij Rempel
---
drivers/net/wireless/ath/ath9k/htc.h | 2 ++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..db4a793 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,8 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, "TX streams %d, RX streams: %d\n",
tx_streams, rx_streams);
+ if (tx_streams >= 2)
+ ht_info->cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info->mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info->mcs.tx_params |= ((tx_streams - 1) <<
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..af08b4a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate->rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta->ht_cap.cap & IEEE80211_HT_CAP_RX_STBC)
+ caps |= WLAN_RC_RX_STBC_FLAG;
+ if (sta->ht_cap.cap & IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
if (sta->ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) &&
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 2/2] ath9k: remove useless flag conversation.
some flags used only outside of ath9k - In this case we can use
"enum mac80211_rx_flags" and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c| 11 +++
drivers/net/wireless/ath/ath9k/mac.h| 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs->rs_status = 0;
rxs->rs_flags = 0;
+ rxs->flag = 0;
rxs->rs_datalen = rxsp->status2 & AR_DataLen;
rxs->rs_tstamp = rxsp->status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs->rs_isaggr = (rxsp->status11 & AR_RxAggr) ? 1 : 0;
rxs->rs_moreaggr = (rxsp->status11 & AR_RxMoreAggr) ? 1 : 0;
rxs->rs_antenna = (MS(rxsp->status4, AR_RxAntenna) & 0x7);
- rxs->rs_flags = (rxsp->status4 & AR_GI) ? ATH9K_RX_GI : 0;
- rxs->rs_flags |= (rxsp->status4 & AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs->flag |= (rxsp->status4 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs->flag |= (rxsp->status4 & AR_2040) ? RX_FLAG_40MHZ : 0;
rxs->evm0 = rxsp->status6;
rxs->evm1 = rxsp->status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs->rs_status = 0;
rs->rs_flags = 0;
+ rs->flag = 0;
rs->rs_datalen = ads.ds_rxstatus1 & AR_DataLen;
rs->rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
rs->rs_moreaggr =
(ads.ds_rxstatus8 & AR_RxMoreAggr) ? 1 : 0;
rs->rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs->rs_flags =
- (ads.ds_rxstatus3 & AR_GI) ? ATH9K_RX_GI : 0;
- rs->rs_flags |=
- (ads.ds_rxstatus3 & AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats->rs_rate & 0x80) {
/* HT rate */
rxs->flag |= RX_FLAG_HT;
- if (rx_stats->rs_flags & ATH9K_RX_2040)
- rxs->flag |= RX_FLAG_40MHZ;
- if (rx_stats->rs_flags & ATH9K_RX_GI)
- rxs->flag |= RX_FLAG_SHORT_GI;
+ rxs->flag |= rx_stats->flag;
rxs->rate_idx = rx_stats->rs_rate & 0x7f;
return 0;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 02/20] ath10k: Merge mac.h with core.h
Kalle Valo wrote: > Sujith Manoharan writes: > > > Kalle Valo wrote: > >> Why do you want to delete mac.h? My idea was to avoid bloating core.h > >> and that's why I wanted to have header files for each .c file. > > > > mac.h contains a few prototypes and most of the data structures are in > > core.h. > > I don't think core.h is getting bloated, it has barely 300+ lines. > > Yes, it has 300+ lines now as I have enforced that it's not abused. But > if I I let everything go to core.h how long will it end up then? > > Besides, I can't see what harm having mac.h brings? Please drop this patch. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/2] ath10k: firmware version related changes
Few simple changes how we handle firmware versions. --- Kalle Valo (2): ath10k: print firmware version string during boot ath10k: only warn about incompatible firmware versions drivers/net/wireless/ath/ath10k/core.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/2] ath10k: print firmware version string during boot
Currently we don't print firmware version at all. Move the
current "firmware dowloaded" message later once firmware
has booted and include firmware version in the message.
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 13ffe78..a511aaf 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -375,7 +375,6 @@ static int ath10k_init_download_firmware(struct ath10k *ar)
if (ret)
return ret;
- ath10k_info("firmware downloaded\n");
return ret;
}
@@ -569,6 +568,8 @@ int ath10k_core_register(struct ath10k *ar)
if (status)
goto err_htt_detach;
+ ath10k_info("firmware %s booted\n", ar->hw->wiphy->fw_version);
+
status = ath10k_check_fw_version(ar);
if (status)
goto err_disconnect_htc;
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 2/2] ath10k: only warn about incompatible firmware versions
Most of the time it does more harm than good to halt the
driver initialisation if the firmware version is not
supported. For example, sometimes it's good to test
something from older versions etc. So just change the
check to a warning.
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index a511aaf..475ca1a 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -84,10 +84,11 @@ static int ath10k_check_fw_version(struct ath10k *ar)
SUPPORTED_FW_MAJOR, SUPPORTED_FW_MINOR,
SUPPORTED_FW_RELEASE, SUPPORTED_FW_BUILD);
- ath10k_err("Firmware %s is not supported. Please use version %s (or
newer)\n",
- ar->hw->wiphy->fw_version, version);
+ ath10k_warn("WARNING: Firmware version %s is not officially
supported.\n",
+ ar->hw->wiphy->fw_version);
+ ath10k_warn("Please upgrade to version %s (or newer)\n", version);
- return -EINVAL;
+ return 0;
}
static int ath10k_init_connect_htc(struct ath10k *ar)
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 2/2] ath10k: only warn about incompatible firmware versions
On 02/05/13 11:02, Kalle Valo wrote:
> Most of the time it does more harm than good to halt the
> driver initialisation if the firmware version is not
> supported. For example, sometimes it's good to test
> something from older versions etc. So just change the
> check to a warning.
>
> Signed-off-by: Kalle Valo
> ---
> drivers/net/wireless/ath/ath10k/core.c |7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c
> b/drivers/net/wireless/ath/ath10k/core.c
> index a511aaf..475ca1a 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -84,10 +84,11 @@ static int ath10k_check_fw_version(struct ath10k *ar)
>SUPPORTED_FW_MAJOR, SUPPORTED_FW_MINOR,
>SUPPORTED_FW_RELEASE, SUPPORTED_FW_BUILD);
>
> - ath10k_err("Firmware %s is not supported. Please use version %s (or
> newer)\n",
> -ar->hw->wiphy->fw_version, version);
> + ath10k_warn("WARNING: Firmware version %s is not officially
> supported.\n",
> + ar->hw->wiphy->fw_version);
> + ath10k_warn("Please upgrade to version %s (or newer)\n", version);
>
> - return -EINVAL;
> + return 0;
> }
Perhaps we should also be taking the abi_version (from
wmi_service_ready_event) into account. I'm not sure if FW really fills
that one out though.
The "or newer" doesn't seem to suit here either. If new FW has ABI
changes we're screwed.
-- Pozdrawiam / Best regards, Michal Kazior.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
On 2 May 2013 01:11, Oleksij Rempel wrote: > +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */ > +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */ I thought we covered this; why are you marking two bits here? Atheros 11n hardware only supports 1-stream STBC RX. Have you verified that we're actually negotiating 1-stream STBC RX with a peer? (Ie, by looking at packet captures?) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Am 02.05.2013 18:55, schrieb Adrian Chadd: > On 2 May 2013 01:11, Oleksij Rempel wrote: > >> +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */ >> +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */ > > I thought we covered this; why are you marking two bits here? becouse firmware checks for two bits (and then use it as bool ;)), so i pass what firmware can handle. > Atheros 11n hardware only supports 1-stream STBC RX. Did you got my email with lots of assumptions and questions? What do you mean by 1-stream STBC RX? After i did some home work on STBC i see that it encoded from at least two spatial streams. Is 1-stream STBC RX = 2 spatial streams with mirrored data? and 2-stream STBC RX = 4 spatial streams with mirrored data? or 1-stream STBC RX = compatibility mode for one stream hardware(so only of two streams received)? That would make sense for 1x1:1 hardware, but if you say all atheros N hardware support only 1-stream STBC RX, will mean that STBC is useless on this hardware. > Have you verified that we're actually negotiating 1-stream STBC RX > with a peer? (Ie, by looking at packet captures?) Yes, i wrote this too :) I verified it, we negotiate only 1-stream STBC RX. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
On 2013-05-02 7:32 PM, Oleksij Rempel wrote: > Am 02.05.2013 18:55, schrieb Adrian Chadd: >> On 2 May 2013 01:11, Oleksij Rempel wrote: >> >>> +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */ >>> +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */ >> >> I thought we covered this; why are you marking two bits here? > > becouse firmware checks for two bits (and then use it as bool ;)), so i > pass what firmware can handle. > >> Atheros 11n hardware only supports 1-stream STBC RX. > > Did you got my email with lots of assumptions and questions? > What do you mean by 1-stream STBC RX? After i did some home work on STBC > i see that it encoded from at least two spatial streams. > Is > 1-stream STBC RX = 2 spatial streams with mirrored data? > and > 2-stream STBC RX = 4 spatial streams with mirrored data? > > or > > 1-stream STBC RX = compatibility mode for one stream hardware(so only of > two streams received)? When you're talking about 'streams', please specify where you're talking about Spatial Streams (Nss, defined by the MCS), or Space-Time Streams (Nsts). STBC is useful whenever the number of possible Space-Time streams exceeds the number of Spatial streams, i.e. if the number of tx chains is bigger than the number of spatial streams. There's an asymmetry between Rx and Tx here. If a receiver has 1 chain and the transmitter has 2 chains, tx can use 2 Space-Time streams to encode 1 Spatial stream to improve the reliability of the signal. The HT STBC capability field indicates the maximum number of Spatial Streams, not Space-Time streams. Atheros hardware only supports STBC with Nss = 1, so announcing 2-stream STBC is definitely wrong. > That would make sense for 1x1:1 hardware, but if you say all atheros N > hardware support only 1-stream STBC RX, will mean that STBC is useless > on this hardware. Only STBC With Nss=1, Nsts=2 is supported, but this does not make it useless at all. It helps, even if the receiver only has one antenna. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Well, let's dig into the firmware a bit more and tidy up how STBC is handled. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Hi Felix, thank you for your explanation and being pation with me. I learn it by my self and keywords you gave help me to find needed information. So, i continue to digg in to google books and wikis now. I see now, that my initial assumption that STBC some thing like "frequency diversity" is wrong. Well, it say by itself Space and Time, no freq :) Am 02.05.2013 20:01, schrieb Felix Fietkau: > On 2013-05-02 7:32 PM, Oleksij Rempel wrote: >> Am 02.05.2013 18:55, schrieb Adrian Chadd: >>> On 2 May 2013 01:11, Oleksij Rempel wrote: >>> +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */ +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */ >>> >>> I thought we covered this; why are you marking two bits here? >> >> becouse firmware checks for two bits (and then use it as bool ;)), so i >> pass what firmware can handle. >> >>> Atheros 11n hardware only supports 1-stream STBC RX. >> >> Did you got my email with lots of assumptions and questions? >> What do you mean by 1-stream STBC RX? After i did some home work on STBC >> i see that it encoded from at least two spatial streams. >> Is >> 1-stream STBC RX = 2 spatial streams with mirrored data? >> and >> 2-stream STBC RX = 4 spatial streams with mirrored data? >> >> or >> >> 1-stream STBC RX = compatibility mode for one stream hardware(so only of >> two streams received)? > When you're talking about 'streams', please specify where you're talking > about Spatial Streams (Nss, defined by the MCS), or Space-Time Streams > (Nsts). STBC is useful whenever the number of possible Space-Time > streams exceeds the number of Spatial streams, i.e. if the number of tx > chains is bigger than the number of spatial streams. > There's an asymmetry between Rx and Tx here. If a receiver has 1 chain > and the transmitter has 2 chains, tx can use 2 Space-Time streams to > encode 1 Spatial stream to improve the reliability of the signal. > The HT STBC capability field indicates the maximum number of Spatial > Streams, not Space-Time streams. Atheros hardware only supports STBC > with Nss = 1, so announcing 2-stream STBC is definitely wrong. Ok, i finally found it on ieee 802.11 specification. For STBC: Nsts=2 - Nss=1 Nsts=3 - Nss=2 Nsts=4 - Nss=2 Nsts=4 - Nss=3 >> That would make sense for 1x1:1 hardware, but if you say all atheros N >> hardware support only 1-stream STBC RX, will mean that STBC is useless >> on this hardware. > Only STBC With Nss=1, Nsts=2 is supported, but this does not make it > useless at all. It helps, even if the receiver only has one antenna. Found it too.. :) Thx! -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Standardisation - adding 2 bit STBC and Ness to MCS
On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: > > With this I believe we have everything needed to start the 3 week > > comment period. Yeah, I guess there was plenty of time. I would have preferred a separate thread, but I guess there's little enough traffic on this list so it doesn't really matter. > There is a bit more then 3 week now. I would like to have this approved :) > Are there any thing needed to finish this? http://www.radiotap.org/Standardisation johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc: Add ethtool stats support.
From: Ben Greear
This provides some of the same info found in
the ath9k_htc debugfs through the standard ethtool stats API.
This logic is only supported when ath9k_htc debugfs kernel
feature is enabled, since that is the only time stats
are actually gathered.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath9k/hif_usb.c |8 ++-
drivers/net/wireless/ath/ath9k/htc.h | 14
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 81
drivers/net/wireless/ath/ath9k/htc_drv_main.c |6 ++
4 files changed, 108 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..9e582e1 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -234,10 +234,15 @@ static inline void ath9k_skb_queue_complete(struct
hif_device_usb *hif_dev,
struct sk_buff *skb;
while ((skb = __skb_dequeue(queue)) != NULL) {
+#ifdef CONFIG_ATH9K_HTC_DEBUGFS
+ int ln = skb->len;
+#endif
ath9k_htc_txcompletion_cb(hif_dev->htc_handle,
skb, txok);
- if (txok)
+ if (txok) {
TX_STAT_INC(skb_success);
+ TX_STAT_ADD(skb_success_bytes, ln);
+ }
else
TX_STAT_INC(skb_failed);
}
@@ -620,6 +625,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb
*hif_dev,
err:
for (i = 0; i < pool_index; i++) {
+ RX_STAT_ADD(skb_completed_bytes, skb_pool[i]->len);
ath9k_htc_rx_msg(hif_dev->htc_handle, skb_pool[i],
skb_pool[i]->len, USB_WLAN_RX_PIPE);
RX_STAT_INC(skb_completed);
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index 8e95930..a964a60 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -317,7 +317,9 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(struct
sk_buff *skb)
#ifdef CONFIG_ATH9K_HTC_DEBUGFS
#define TX_STAT_INC(c) (hif_dev->htc_handle->drv_priv->debug.tx_stats.c++)
+#define TX_STAT_ADD(c, a) (hif_dev->htc_handle->drv_priv->debug.tx_stats.c +=
a)
#define RX_STAT_INC(c) (hif_dev->htc_handle->drv_priv->debug.rx_stats.c++)
+#define RX_STAT_ADD(c, a) (hif_dev->htc_handle->drv_priv->debug.rx_stats.c +=
a)
#define CAB_STAT_INC priv->debug.tx_stats.cab_queued++
#define TX_QSTAT_INC(q) (priv->debug.tx_stats.queue_stats[q]++)
@@ -330,6 +332,7 @@ struct ath_tx_stats {
u32 buf_completed;
u32 skb_queued;
u32 skb_success;
+ u32 skb_success_bytes;
u32 skb_failed;
u32 cab_queued;
u32 queue_stats[IEEE80211_NUM_ACS];
@@ -338,6 +341,7 @@ struct ath_tx_stats {
struct ath_rx_stats {
u32 skb_allocated;
u32 skb_completed;
+ u32 skb_completed_bytes;
u32 skb_dropped;
u32 err_crc;
u32 err_decrypt_crc;
@@ -355,10 +359,20 @@ struct ath9k_debug {
struct ath_rx_stats rx_stats;
};
+void ath9k_htc_get_et_strings(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data);
+int ath9k_htc_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset);
+void ath9k_htc_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data);
#else
#define TX_STAT_INC(c) do { } while (0)
+#define TX_STAT_ADD(c, a) do { } while (0)
#define RX_STAT_INC(c) do { } while (0)
+#define RX_STAT_ADD(c, a) do { } while (0)
#define CAB_STAT_INC do { } while (0)
#define TX_QSTAT_INC(c) do { } while (0)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
index 632d13d..7416d58 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
@@ -902,6 +902,87 @@ static const struct file_operations fops_modal_eeprom = {
.llseek = default_llseek,
};
+
+/* Ethtool support for get-stats */
+#define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
+static const char ath9k_htc_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "tx_pkts_nic",
+ "tx_bytes_nic",
+ "rx_pkts_nic",
+ "rx_bytes_nic",
+
+ AMKSTR(d_tx_pkts),
+
+ "d_rx_crc_err",
+ "d_rx_decrypt_crc_err",
+ "d_rx_phy_err",
+ "d_rx_mic_err",
+ "d_rx_pre_delim_crc_err",
+ "d_rx_post_delim_crc_err",
+ "d_rx_decrypt_busy_err",
+
+ "d_rx_phyerr_radar",
+ "d_rx_phyerr_ofdm_timing",
+ "d_rx_phyerr_cck_timing",
+
+};
+#define ATH9K_HTC_SSTATS_LEN ARRAY_SIZE(ath9k_htc_gstrings_stats)
+
+void ath9k_htc_get_et_strings(struct
Re: [ath9k-devel] varying RSSI values with ath9k_htc drivers for TL-WN721N USB wifi adapter.
Hi, I did some testing with the latest version of the ath9k_htc drivers in 3.9.0-rc8-wl which already has the patch https://patchwork.kernel.org/patch/2177921/ and the results are much better. Can you point out the AR9285 RX descriptor contents relating to antenna configuration? Regards, On Friday 26 April 2013 08:08 PM, Adrian Chadd wrote: > There's some driver work that Felix and others did or are talking > about, which tidy up the RSSI measurement. > > There's also the antenna diversity behaviour; depending upon which > antenna is used, there's a few dB difference (same as the AR9285.) > > I'm sorry, I can't work on it any more than that. I can point out what > the AR9285 RX descriptor contents are relating to antenna > configuration; that way someone can add that to ath9k and possibly > link antenna selection / configuration to the RSSI differences. But I > can't do the legwork, sorry. > > > > > Adrian > > On 26 April 2013 06:56, Trevor Cullen wrote: >> This issue totally destroyed deployment of DNUA-93F (AR9271) USB Wifi in a >> similar application. Now use Realtek with very stable results. >> >> But there is history. >> >> See https://patchwork.kernel.org/patch/2177921/ and attached. >> >> Trevor >> -Original Message- >> From: ath9k-devel-boun...@lists.ath9k.org >> [mailto:ath9k-devel-boun...@lists.ath9k.org] On Behalf Of Harshal Vora >> Sent: 26 April 2013 11:43 >> To: Adrian Chadd >> Cc: ath9k-devel@lists.ath9k.org >> Subject: Re: [ath9k-devel] varying RSSI values with ath9k_htc drivers for >> TL-WN721N USB wifi adapter. >> >> On Friday 26 April 2013 01:39 AM, Adrian Chadd wrote: >>> Have you actually verified that the output power of those devices is >>> actually constant? >>> >>> >>> >>> Adrian >>> >>> On 25 April 2013 07:08, Harshal Vora wrote: Hi, I are trying to achieve approximate location detection (room level granularity) based on RSSI. I am using TP-LINK TL-WN721N USB wifi adapter which require ath9k_htc drivers. Operating system: Ubuntu 12:04 LTS. The RSSI values recorded vary a lot, even when the transmitter (iPhone 5 and sony xPeria and other phones) and the receiver are left untouched at the same location. There is a difference of almost 15 to 20 dbm in the readings. Sometimes it is in the range of -40 to -50dbm .. sometimes -50 to -60dbm Also sometimes the RSSI values are always between -75 to -85 dbm no matter how short or long the distance is between the two devices. I am using airmon-ng to set the device in monitor mode and tshark to >> sniff. I have tried with the drivers that come with ubuntu 12.04, with compat-wireless 3.6.8-1 as well as compat-drivers 3.8.3-2 The todo list on http://wireless.kernel.org/en/users/Drivers/ath9k_htc#TODO mentions Low RSSI issue for UB91/94. Should this be a concern? Regards, ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> >> Hi, >> >> I have a MAC laptop which has inbuilt broadcom BCM 4331 chipset running on >> b43 drivers. >> >> I put the iPhone in charging and it is always unlocked and on the wifi >> settings page which displays available networks. >> From what I understand, iPhone goes in power saver mode only when locked. >> The readings on bcm4331 are much stable as compared to the wn721n usb >> adapter. >> On broadcom, the dbm values differ mostly by 3-4 dbm and sometimes I see a >> spike with a difference of 7-8dbm. >> On the other hand the dbm values using ath9k_htc drivers differ by 10-15dbm. >> >> I have also tested with a locked iPhone to get similar results. >> >> In another setup, I connected one wn721n chipset to hackberry and another to >> my laptop. >> Again I took two sets of readings with transmitter as wn721n on hackberry >> and receiver as bcm4331 in the first run and receiver as wn721n on my mac in >> the second run. >> Again similar observaions as the experiment with iPhone as transmitter. >> >> How can I measure the output transmission power? I deployed the ath9k_htc >> drivers in debug mode with value 0x. But cannot get any relevant >> information from debugfs. >> When I do ifconfig, it says power management off. >> When I run sudo iwconfig "dev" txpower "value", it returns an error. >> >> I have taken a lot of different sets of readings for ath9k_htc, and >> relatively the readings are correct. i.e. the dbm values will change as the >> distance between the transmitter and receiver changes. But sometimes the dbm >> values remain in a particular range say -75dbm to -85dbm no matter how near >> or far the transmitter is from the receiver. >> >> Regards, >> ___ >> ath9k-devel mailing list >> ath9k-devel@lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath
