[ath9k-devel] [PATCH 2/2] ath10k: Neaten ath10k_level uses
Standardize the logging messages a bit.
A couple of typos were fixed.
Standardize the use of VDEV:%d instead of mixing in some VDEV: %d.
Signed-off-by: Joe Perches j...@perches.com
---
Resending to ath9k per Kalle
drivers/net/wireless/ath/ath10k/ce.c | 6 +-
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/htc.c| 24 +++
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 +-
drivers/net/wireless/ath/ath10k/mac.c| 119 ---
drivers/net/wireless/ath/ath10k/pci.c| 44 ++--
drivers/net/wireless/ath/ath10k/wmi.c| 4 +-
8 files changed, 102 insertions(+), 101 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c
b/drivers/net/wireless/ath/ath10k/ce.c
index 61a8ac7..36aa524 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1126,13 +1126,13 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
ce_state = ath10k_ce_init_state(ar, ce_id, attr);
if (!ce_state) {
- ath10k_err(Failed to initialize CE state for ID: %d\n, ce_id);
+ ath10k_err(failed to initialize CE state for ID: %d\n, ce_id);
return NULL;
}
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,
+ ath10k_err(failed to initialize CE src ring for ID:
%d\n,
ce_id);
ath10k_ce_deinit(ce_state);
return NULL;
@@ -1141,7 +1141,7 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
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,
+ 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/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index b258042..c13de8b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -84,7 +84,7 @@ static int ath10k_check_fw_version(struct ath10k *ar)
SUPPORTED_FW_MAJOR, SUPPORTED_FW_MINOR,
SUPPORTED_FW_RELEASE, SUPPORTED_FW_BUILD);
- ath10k_warn(WARNING: Firmware version %s is not officially
supported.\n,
+ 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);
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index 9b6c681..1e1251a 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -88,7 +88,7 @@ static struct sk_buff *ath10k_htc_build_tx_ctrl_skb(void *ar)
skb = dev_alloc_skb(ATH10K_HTC_CONTROL_BUFFER_SIZE);
if (!skb) {
- ath10k_warn(Unable to allocate ctrl skb\n);
+ ath10k_warn(unable to allocate ctrl skb\n);
return NULL;
}
@@ -304,7 +304,7 @@ int ath10k_htc_send(struct ath10k_htc *htc,
struct ath10k_htc_ep *ep = htc-endpoint[eid];
if (eid = ATH10K_HTC_EP_COUNT) {
- ath10k_warn(Invalid endpoint id: %d\n, eid);
+ ath10k_warn(invalid endpoint id: %d\n, eid);
return -ENOENT;
}
@@ -382,7 +382,7 @@ ath10k_htc_process_credit_report(struct ath10k_htc *htc,
int i, n_reports;
if (len % sizeof(*report))
- ath10k_warn(Uneven credit report len %d, len);
+ ath10k_warn(uneven credit report len %d, len);
n_reports = len / sizeof(*report);
@@ -427,7 +427,7 @@ static int ath10k_htc_process_trailer(struct ath10k_htc
*htc,
if (record-hdr.len length) {
/* no room left in buffer for record */
- ath10k_warn(Invalid record length: %d\n,
+ ath10k_warn(invalid record length: %d\n,
record-hdr.len);
status = -EINVAL;
break;
@@ -437,7 +437,7 @@ static int ath10k_htc_process_trailer(struct ath10k_htc
*htc,
case ATH10K_HTC_RECORD_CREDITS:
len = sizeof(struct ath10k_htc_credit_report);
if (record-hdr.len len) {
- ath10k_warn(Credit report too long\n);
+ ath10k_warn(credit report too long\n);
status = -EINVAL;
break;
Re: [ath9k-devel] [PATCH 1/2] ath10k: Convert ath10k_dbg uses
On 16/05/13 09:03, Joe Perches wrote: Neaten and shorten the uses of ath10k_dbg and ath10k_dbg_dump. Add macros to hold the ATH10K_DBG_ mask portion of the functions. I'm not really fond of this idea. It's harder to locate symbols when doing macro name concatenation. You can't jump to, e.g. WMI symbol definition because it doesn't exist (ATH10K_DBG_WMI is what you actually want). Although you don't look for this symbol often so I guess it's okay-ish. -- Pozdrawiam / Best regards, Michal Kazior. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath10k: remove CTRY_DEFAULT assignment
The country is be overwritten by the eeprom
regdomain that we read from WMI event anyway.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 974f992..9454ff3 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2941,7 +2941,6 @@ int ath10k_mac_register(struct ath10k *ar)
ar-hw-wiphy-iface_combinations = ath10k_if_comb;
ar-hw-wiphy-n_iface_combinations = 1;
- ar-ath_common.regulatory.country_code = CTRY_DEFAULT;
ret = ath_regd_init(ar-ath_common.regulatory, ar-hw-wiphy,
ath10k_reg_notifier);
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] ath10k: remove static mac address mask
FW can dynamically adjust to multiple mac addresses. It reports it's preferred base mac address, but we can freely create derivative addresses for vdevs. Signed-off-by: Michal Kazior michal.kaz...@tieto.com --- drivers/net/wireless/ath/ath10k/wmi.c |8 1 file changed, 8 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index 0d5070d..895567b 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -907,14 +907,6 @@ static int ath10k_wmi_ready_event_rx(struct ath10k *ar, struct sk_buff *skb) memcpy(ar-mac_addr, ev-mac_addr.addr, ETH_ALEN); - /* FIXME: FW should report possible addresses we can use. This is a -*development workaround. wpa_supplicant generates addresses -*that do not work with the FW without this. Once this is -*submitted upstream we should either get rid of this either by -*reducing functionality or forcing FW team to take action. */ - memcpy(ar-hw-wiphy-perm_addr, ev-mac_addr.addr, ETH_ALEN); - memcpy(ar-hw-wiphy-addr_mask, \x00\x00\x00\xFF\xFF\xFF, ETH_ALEN); - ath10k_dbg(ATH10K_DBG_WMI, wmi event ready sw_version %u abi_version %u mac_addr %pM status %d\n, __le32_to_cpu(ev-sw_version), -- 1.7.9.5 ___ 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 (repost 3)
Hallo all, so, there is no updates or critic on this topic. That mean, every thing is OK. I assume suggested-fields/MCS extension for STBC and Ness http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness can be moved to defined-fields/MCS http://www.radiotap.org/defined-fields/MCS Johannes, your word ;) Am 09.05.2013 11:55, schrieb Oleksij Rempel: Hallo all, this is probably third repost of this standardisation request. History: - 11 May 2012. initial request made by Simon Barber. http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness - 1 Okt 2012, Wireshark support this fields. Patches provided by Wojciech Dubowik. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6720 - 1 Nov 2012. patches for intel adapters, ieee80211 and wireshark was uploaded by Simon. http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness?action=AttachFile - 17 Nov 2012. Simon posted new thread as suggested Johannes Berg. - 1 May 2013. I restarted this discussion. link to initial discussion: http://comments.gmane.org/gmane.network.wireless.radiotap/302 As you can see it is already long standing issue... Now to proposal mad by Simon. Please add comments like: agreed or not agreed and why. Proposal === This proposal is to extend the current MCS radiotap header to carry STBC and Ness information. This information is carried in the 802.11 HT-SIG field that carries all the other fields currently in this radiotap MCS header. Both STBC and Ness fields are needed alongside the others to calculate the length (duration in time) of a frame. This proposal adds 3 bits to the known field and the flags field. See below for proposed text. = MCS = Bit Number:: 19 Structure:: u8 known, u8 flags, u8 mcs Required Alignment:: 1 The `mcs` field indicates the MCS rate index as in [[http://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates|IEEE_802.11n-2009]] The `known` field indicates which information is known: ||'''flag'''||'''definition'''|| || `0x01` || bandwidth || || `0x02` || MCS index known (in `mcs` part of the field) || || `0x04` || guard interval || || `0x08` || HT format || || `0x10` || FEC type || || `0x20` || STBC known || || `0x40` || Ness known (Number of extension spatial streams) || || `0x80` || Ness data - bit 1 (MSB) of Number of extension spatial streams || The `flags` field is any combination of the following: || '''flag''' || '''definition''' || || `0x03` || bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U || || `0x04` || guard interval - 0: long GI, 1: short GI || || `0x08` || HT format - 0: mixed, 1: greenfield || || `0x10` || FEC type - 0: BCC, 1: LDPC || || `0x60` || Number of STBC streams || || `0x80` || Ness - bit 0 (LSB) of Number of extension spatial streams | -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/7] ath10k: tx flow control fixes
This addresses some `tx failed` issues and minor issues I've found along. This is a resend as a PATCH rather than an RFC. Updates include: * added `ath10k: detect htt pending tx limit at runtime` * dropped htc tx polling with a timer patch * dropped explicit htt tx polling from `ath10k: introduce proper htt tx flow control` (this was deadlocking, and is no longer necessary anyway) Michal Kazior (7): ath10k: change errno if we run out of msdu_ids ath10k: ath10k_htc_prepare_tx_skb() never fails ath10k: add lockdep asserts to htc skb dequeuing ath10k: simplify htc flow control ath10k: remove unused queue limit ath10k: introduce proper htt tx flow control ath10k: detect htt pending tx limit at runtime drivers/net/wireless/ath/ath10k/htc.c| 106 +++--- drivers/net/wireless/ath/ath10k/htc.h|4 -- drivers/net/wireless/ath/ath10k/htt.c| 25 ++- drivers/net/wireless/ath/ath10k/htt.h| 26 ++-- drivers/net/wireless/ath/ath10k/htt_tx.c | 83 +-- drivers/net/wireless/ath/ath10k/mac.c|2 +- drivers/net/wireless/ath/ath10k/txrx.c |5 +- 7 files changed, 116 insertions(+), 135 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 2/7] ath10k: ath10k_htc_prepare_tx_skb() never fails
It shouldn't report any result.
ath10k_htc_restore_tx_skb() assumes
ath10k_htc_prepare_tx_skb() always succeeds. If
ath10k_htc_prepare_tx_skb() was to fail we'd
errornously skb_pull(). This patch is for clarity
and sanity.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/htc.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index af95e87..820444b 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -139,8 +139,8 @@ static bool ath10k_htc_ep_need_credit_update(struct
ath10k_htc_ep *ep)
return true;
}
-static int ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
-struct sk_buff *skb)
+static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
+ struct sk_buff *skb)
{
struct ath10k_htc_hdr *hdr;
@@ -157,8 +157,6 @@ static int ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep
*ep,
hdr-flags |= ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE;
spin_unlock_bh(ep-htc-tx_lock);
-
- return 0;
}
static int ath10k_htc_issue_skb(struct ath10k_htc *htc,
@@ -172,9 +170,7 @@ static int ath10k_htc_issue_skb(struct ath10k_htc *htc,
ath10k_dbg(ATH10K_DBG_HTC, %s: ep %d skb %p\n, __func__,
ep-eid, skb);
- ret = ath10k_htc_prepare_tx_skb(ep, skb);
- if (ret)
- goto err;
+ ath10k_htc_prepare_tx_skb(ep, skb);
ret = ath10k_skb_map(htc-ar-dev, skb);
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 3/7] ath10k: add lockdep asserts to htc skb dequeuing
Signed-off-by: Michal Kazior michal.kaz...@tieto.com --- 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 820444b..ac211f1 100644 --- a/drivers/net/wireless/ath/ath10k/htc.c +++ b/drivers/net/wireless/ath/ath10k/htc.c @@ -198,7 +198,6 @@ err: return ret; } -/* assumes tx_lock is held */ static struct sk_buff *ath10k_htc_get_skb_credit_based(struct ath10k_htc *htc, struct ath10k_htc_ep *ep, u8 *credits) @@ -209,6 +208,8 @@ static struct sk_buff *ath10k_htc_get_skb_credit_based(struct ath10k_htc *htc, int remainder; unsigned int transfer_len; + lockdep_assert_held(htc-tx_lock); + skb = __skb_dequeue(ep-tx_queue); if (!skb) return NULL; @@ -241,7 +242,6 @@ static struct sk_buff *ath10k_htc_get_skb_credit_based(struct ath10k_htc *htc, return skb; } -/* assumes tx_lock is held */ static struct sk_buff *ath10k_htc_get_skb(struct ath10k_htc *htc, struct ath10k_htc_ep *ep, int resources) @@ -249,6 +249,8 @@ static struct sk_buff *ath10k_htc_get_skb(struct ath10k_htc *htc, struct sk_buff *skb; struct ath10k_skb_cb *skb_cb; + lockdep_assert_held(htc-tx_lock); + if (!resources) return NULL; -- 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/7] ath10k: simplify htc flow control
Credit-based flow is designed around HTC, and HTC
is supposed to manage the credit count and
reservation.
For non credit-based endpoints we must depend on
the HIF pipe tx resources. This is CE ringbuffer
size/usage for PCI backend. This is not managed by
HTC but by the HIF. We could mirror the
tx_resources and sync it in HTC and perform
mirror-reservation in HTC but it doesn't really
make much sense. It's far simpler to reinsert skb
if we're out of resources.
Queue control in HTC is ineffective and does
virtually nothing. This will be replaced in the
future.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/htc.c | 94 ++---
drivers/net/wireless/ath/ath10k/htc.h |4 --
drivers/net/wireless/ath/ath10k/htt.c | 12 -
3 files changed, 17 insertions(+), 93 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index ac211f1..74363c9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -23,48 +23,6 @@
/* Send */
//
-static inline void ath10k_htc_stop_queue(struct ath10k_htc_ep *ep)
-{
- if (ep-tx_queue_stopped)
- return;
-
- if (ep-ep_ops.stop_queue)
- ep-ep_ops.stop_queue(ep-htc-ar);
-
- ath10k_dbg(ATH10K_DBG_HTC, ep %d stop\n, ep-eid);
- ep-tx_queue_stopped = true;
-}
-
-static inline void ath10k_htc_wake_queue(struct ath10k_htc_ep *ep)
-{
- if (!ep-tx_queue_stopped)
- return;
-
- if (ep-ep_ops.wake_queue)
- ep-ep_ops.wake_queue(ep-htc-ar);
-
- ath10k_dbg(ATH10K_DBG_HTC, ep %d wake\n, ep-eid);
- ep-tx_queue_stopped = false;
-}
-
-static inline void ath10k_htc_recalc_queue(struct ath10k_htc_ep *ep, int delta)
-{
- ath10k_dbg(ATH10K_DBG_HTC, ep %d queue len %d +%d max %d\n,
- ep-eid, ep-tx_queue_len, delta, ep-max_tx_queue_depth);
-
- if (ep-max_tx_queue_depth == 0)
- return;
-
- ep-tx_queue_len += delta;
-
- if (ep-tx_queue_stopped) {
- if (ep-tx_queue_len = ep-max_tx_queue_depth/2)
- ath10k_htc_wake_queue(ep);
- } else if (ep-tx_queue_len = ep-max_tx_queue_depth) {
- ath10k_htc_stop_queue(ep);
- }
-}
-
static inline void ath10k_htc_send_complete_check(struct ath10k_htc_ep *ep,
int force)
{
@@ -192,6 +150,17 @@ err:
ep-tx_credits += credits;
spin_unlock_bh(htc-tx_lock);
+ /* this is the simplest way to handle out-of-resources for non-credit
+* based endpoints. credit based endpoints can still get -ENOSR, but
+* this is highly unlikely as credit reservation should prevent that */
+ if (ret == -ENOSR) {
+ spin_lock_bh(htc-tx_lock);
+ __skb_queue_head(ep-tx_queue, skb);
+ spin_unlock_bh(htc-tx_lock);
+
+ return ret;
+ }
+
skb_cb-is_aborted = true;
ath10k_htc_notify_tx_completion(ep, skb);
@@ -233,7 +202,6 @@ static struct sk_buff
*ath10k_htc_get_skb_credit_based(struct ath10k_htc *htc,
if (ep-tx_credits credits_required) {
__skb_queue_head(ep-tx_queue, skb);
- ath10k_htc_recalc_queue(ep, 1);
return NULL;
}
@@ -242,59 +210,33 @@ static struct sk_buff
*ath10k_htc_get_skb_credit_based(struct ath10k_htc *htc,
return skb;
}
-static struct sk_buff *ath10k_htc_get_skb(struct ath10k_htc *htc,
- struct ath10k_htc_ep *ep,
- int resources)
-{
- struct sk_buff *skb;
- struct ath10k_skb_cb *skb_cb;
-
- lockdep_assert_held(htc-tx_lock);
-
- if (!resources)
- return NULL;
-
- skb = __skb_dequeue(ep-tx_queue);
- if (!skb)
- return NULL;
-
- skb_cb = ATH10K_SKB_CB(skb);
- ath10k_htc_recalc_queue(ep, -1);
-
- return skb;
-}
-
static void ath10k_htc_send_work(struct work_struct *work)
{
struct ath10k_htc_ep *ep = container_of(work,
struct ath10k_htc_ep, send_work);
struct ath10k_htc *htc = ep-htc;
struct sk_buff *skb;
- int tx_resources = 0;
u8 credits = 0;
+ int ret;
while (true) {
- if (!ep-tx_credit_flow_enabled)
- tx_resources = ath10k_hif_get_free_queue_number
- (htc-ar, ep-ul_pipe_id);
-
if (ep-ul_is_polled)
ath10k_htc_send_complete_check(ep, 0);
spin_lock_bh(htc-tx_lock);
-
if (ep-tx_credit_flow_enabled)
skb = ath10k_htc_get_skb_credit_based(htc, ep,
credits);
else
-
[ath9k-devel] [PATCH 5/7] ath10k: remove unused queue limit
HTT isn't credit-based and we don't need to have
an artificial limit here.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/htt.c |6 --
drivers/net/wireless/ath/ath10k/htt.h | 15 ---
2 files changed, 21 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.c
b/drivers/net/wireless/ath/ath10k/htt.c
index e1fa279..b39f5de 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -33,12 +33,6 @@ static int ath10k_htt_htc_attach(struct ath10k_htt *htt)
conn_req.ep_ops.ep_tx_complete = ath10k_htt_htc_tx_complete;
conn_req.ep_ops.ep_rx_complete = ath10k_htt_t2h_msg_handler;
- /*
-* Specify how deep to let a queue get before ath10k_htc_send will
-* call the ep_send_full function due to excessive send queue depth.
-*/
- conn_req.max_send_queue_depth = HTT_MAX_SEND_QUEUE_DEPTH;
-
/* connect to control service */
conn_req.service_id = ATH10K_HTC_SVC_ID_HTT_DATA_MSG;
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index f3c22df..85de0b3 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1302,21 +1302,6 @@ struct htt_rx_desc {
#define HTT_MAC_ADDR_LEN 6
/*
- * HTT_MAX_SEND_QUEUE_DEPTH -
- * How many packets HTC should allow to accumulate in a send queue
- * before calling the ep_send_full callback to see whether to retain
- * or drop packets.
- * This is not relevant for LL, where tx descriptors should be immediately
- * downloaded to the target.
- * This is not very relevant for HL either, since it is anticipated that
- * the HL tx download scheduler will not work this far in advance - rather,
- * it will make its decisions just-in-time, so it can be responsive to
- * changing conditions.
- * Hence, this queue depth threshold spec is mostly just a formality.
- */
-#define HTT_MAX_SEND_QUEUE_DEPTH (HTT_MAX_NUM_PENDING_TX)
-
-/*
* FIX THIS
* Should be: sizeof(struct htt_host_rx_desc) + max rx MSDU size,
* rounded up to a cache line size.
--
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/7] ath10k: introduce proper htt tx flow control
There were cases where we'd run out of msdu_ids.
This can be fixed by telling mac80211 to stop
sending us more frames if we run out of resources.
It was possible to trigger with massive TCP RX
~300mbps (e.g. using iperf).
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/htt.h|2 ++
drivers/net/wireless/ath/ath10k/htt_tx.c | 46 ++
drivers/net/wireless/ath/ath10k/txrx.c |1 +
3 files changed, 49 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 85de0b3..8ae1f03 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1262,6 +1262,7 @@ struct ath10k_htt {
/* Protects access to %pending_tx, %used_msdu_ids */
spinlock_t tx_lock;
+ int num_pending_tx;
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;
@@ -1330,6 +1331,7 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct
sk_buff *skb);
int ath10k_htt_h2t_ver_req_msg(struct ath10k_htt *htt);
int ath10k_htt_send_rx_ring_cfg_ll(struct ath10k_htt *htt);
+void __ath10k_htt_tx_dec_pending(struct ath10k_htt *htt);
int ath10k_htt_tx_alloc_msdu_id(struct ath10k_htt *htt);
void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, u16 msdu_id);
int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 21add5d..7dd366f 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -18,9 +18,44 @@
#include linux/etherdevice.h
#include htt.h
#include mac.h
+#include hif.h
#include txrx.h
#include debug.h
+void __ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
+{
+ htt-num_pending_tx--;
+ if (htt-num_pending_tx == HTT_MAX_NUM_PENDING_TX - 1)
+ ieee80211_wake_queues(htt-ar-hw);
+}
+
+static void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
+{
+ spin_lock_bh(htt-tx_lock);
+ __ath10k_htt_tx_dec_pending(htt);
+ spin_unlock_bh(htt-tx_lock);
+}
+
+static int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt)
+{
+ int ret = 0;
+
+ spin_lock_bh(htt-tx_lock);
+
+ if (htt-num_pending_tx = HTT_MAX_NUM_PENDING_TX) {
+ ret = -EBUSY;
+ goto exit;
+ }
+
+ htt-num_pending_tx++;
+ if (htt-num_pending_tx == HTT_MAX_NUM_PENDING_TX)
+ ieee80211_stop_queues(htt-ar-hw);
+
+exit:
+ spin_unlock_bh(htt-tx_lock);
+ return ret;
+}
+
int ath10k_htt_tx_alloc_msdu_id(struct ath10k_htt *htt)
{
int msdu_id;
@@ -238,6 +273,11 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct
sk_buff *msdu)
int msdu_id = -1;
int res;
+
+ res = ath10k_htt_tx_inc_pending(htt);
+ if (res)
+ return res;
+
len += sizeof(cmd-hdr);
len += sizeof(cmd-mgmt_tx);
@@ -295,6 +335,7 @@ err:
ath10k_htt_tx_free_msdu_id(htt, msdu_id);
spin_unlock_bh(htt-tx_lock);
}
+ ath10k_htt_tx_dec_pending(htt);
return res;
}
@@ -316,6 +357,10 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
u8 flags0;
u16 flags1;
+ res = ath10k_htt_tx_inc_pending(htt);
+ if (res)
+ return res;
+
prefetch_len = min(htt-prefetch_len, msdu-len);
prefetch_len = roundup(prefetch_len, 4);
@@ -431,6 +476,7 @@ err:
ath10k_htt_tx_free_msdu_id(htt, msdu_id);
spin_unlock_bh(htt-tx_lock);
}
+ ath10k_htt_tx_dec_pending(htt);
ath10k_skb_unmap(dev, msdu);
return res;
}
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c
b/drivers/net/wireless/ath/ath10k/txrx.c
index a32448c..ce44ab1 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -95,6 +95,7 @@ exit:
spin_lock_bh(htt-tx_lock);
htt-pending_tx[ATH10K_SKB_CB(txdesc)-htt.msdu_id] = NULL;
ath10k_htt_tx_free_msdu_id(htt, ATH10K_SKB_CB(txdesc)-htt.msdu_id);
+ __ath10k_htt_tx_dec_pending(htt);
if (bitmap_empty(htt-used_msdu_ids, HTT_MAX_NUM_PENDING_TX))
wake_up(htt-empty_tx_wq);
spin_unlock_bh(htt-tx_lock);
--
1.7.9.5
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 7/7] ath10k: detect htt pending tx limit at runtime
The real limit for sending htt tx is either
msdu_id storage type (u16 - 65536 different
values) or the HIF tx pipe queue length (2047 in
case of our PCI HIF).
The htt tx pipe does not use interrupts - it must
be polled. It is polled either on RX
unconditionally or on TX if HIF tx pipe has used
over 50% of the resources.
With this patch we should finally trigger the TX
polling properly. What this really means we should
have a smoother tx. Not because the tx limit is
greater, but simply because we'll be triggering
the polling properly in case of heavy tx.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/htt.c|7 -
drivers/net/wireless/ath/ath10k/htt.h|9 +++
drivers/net/wireless/ath/ath10k/htt_tx.c | 41 +-
drivers/net/wireless/ath/ath10k/mac.c|2 +-
drivers/net/wireless/ath/ath10k/txrx.c |4 +--
5 files changed, 47 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.c
b/drivers/net/wireless/ath/ath10k/htt.c
index b39f5de..185a546 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -50,6 +50,7 @@ static int ath10k_htt_htc_attach(struct ath10k_htt *htt)
struct ath10k_htt *ath10k_htt_attach(struct ath10k *ar)
{
struct ath10k_htt *htt;
+ int ret;
htt = kzalloc(sizeof(*htt), GFP_KERNEL);
if (!htt)
@@ -67,7 +68,11 @@ struct ath10k_htt *ath10k_htt_attach(struct ath10k *ar)
if (ath10k_htt_htc_attach(htt))
goto err_htc_attach;
- ath10k_htt_tx_attach(htt);
+ ret = ath10k_htt_tx_attach(htt);
+ if (ret) {
+ ath10k_err(could not attach htt tx (%d)\n, ret);
+ goto err_htc_attach;
+ }
if (ath10k_htt_rx_attach(htt))
goto err_rx_attach;
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 8ae1f03..a7a7aa0 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1184,8 +1184,6 @@ struct htt_rx_info {
bool fcs_err;
};
-#define HTT_MAX_NUM_PENDING_TX 512 /* FIXME: find proper value? */
-
struct ath10k_htt {
struct ath10k *ar;
enum ath10k_htc_ep_id eid;
@@ -1262,9 +1260,10 @@ struct ath10k_htt {
/* Protects access to %pending_tx, %used_msdu_ids */
spinlock_t tx_lock;
+ int max_num_pending_tx;
int num_pending_tx;
- struct sk_buff *pending_tx[HTT_MAX_NUM_PENDING_TX];
- DECLARE_BITMAP(used_msdu_ids, HTT_MAX_NUM_PENDING_TX);
+ struct sk_buff **pending_tx;
+ unsigned long *used_msdu_ids; /* bitmap */
wait_queue_head_t empty_tx_wq;
/* set if host-fw communication goes haywire
@@ -1322,7 +1321,7 @@ 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);
-void ath10k_htt_tx_attach(struct ath10k_htt *htt);
+int ath10k_htt_tx_attach(struct ath10k_htt *htt);
void ath10k_htt_tx_detach(struct ath10k_htt *htt);
int ath10k_htt_rx_attach(struct ath10k_htt *htt);
void ath10k_htt_rx_detach(struct ath10k_htt *htt);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 7dd366f..bd84153 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -25,7 +25,7 @@
void __ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
{
htt-num_pending_tx--;
- if (htt-num_pending_tx == HTT_MAX_NUM_PENDING_TX - 1)
+ if (htt-num_pending_tx == htt-max_num_pending_tx - 1)
ieee80211_wake_queues(htt-ar-hw);
}
@@ -42,13 +42,13 @@ static int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt)
spin_lock_bh(htt-tx_lock);
- if (htt-num_pending_tx = HTT_MAX_NUM_PENDING_TX) {
+ if (htt-num_pending_tx = htt-max_num_pending_tx) {
ret = -EBUSY;
goto exit;
}
htt-num_pending_tx++;
- if (htt-num_pending_tx == HTT_MAX_NUM_PENDING_TX)
+ if (htt-num_pending_tx == htt-max_num_pending_tx)
ieee80211_stop_queues(htt-ar-hw);
exit:
@@ -63,8 +63,8 @@ int ath10k_htt_tx_alloc_msdu_id(struct ath10k_htt *htt)
lockdep_assert_held(htt-tx_lock);
msdu_id = find_first_zero_bit(htt-used_msdu_ids,
- HTT_MAX_NUM_PENDING_TX);
- if (msdu_id == HTT_MAX_NUM_PENDING_TX)
+ htt-max_num_pending_tx);
+ if (msdu_id == htt-max_num_pending_tx)
return -ENOBUFS;
ath10k_dbg(ATH10K_DBG_HTT, htt tx alloc msdu_id %d\n, msdu_id);
@@ -83,10 +83,35 @@ void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, u16
msdu_id)
__clear_bit(msdu_id, htt-used_msdu_ids);
}
-void ath10k_htt_tx_attach(struct ath10k_htt *htt)
+int ath10k_htt_tx_attach(struct
[ath9k-devel] [PATCH] ath10k: remove unnecessary include
We already do forward declaration of ath10k and ath10k_vif in wmi.h. Signed-off-by: Michal Kazior michal.kaz...@tieto.com --- drivers/net/wireless/ath/ath10k/wmi.h |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h index ccab87e..c6e6343 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.h +++ b/drivers/net/wireless/ath/ath10k/wmi.h @@ -21,8 +21,6 @@ #include linux/types.h #include net/mac80211.h -#include core.h - /* * This file specifies the WMI interface for the Unified Software * Architecture. -- 1.7.9.5 ___ 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 (repost 3)
On Thu, 2013-05-16 at 11:01 +0200, Oleksij Rempel wrote: Hallo all, so, there is no updates or critic on this topic. That mean, every thing is OK. I tend to agree. I assume suggested-fields/MCS extension for STBC and Ness http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness can be moved to defined-fields/MCS http://www.radiotap.org/defined-fields/MCS Johannes, your word ;) I don't really have any say, but go for it, for all I care :) johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 15.05.2013 15:42, schrieb Ignacy Gawedzki: Hi everyone, This is an old issue, about which it seems the first posts date back to 2009. With the latest possible version of the firmware for AR9271 and the latest possible wireless drivers, the issue is still there. Whether this is still the exact same problem every time remains to be checked, but it is annoying enough to deserve some consideration. The problem is that the driver can't talk to the device if the following conditions are met: - The system cold boots with the USB dongle inserted or the USB dongle is inserted on a running system. - The interface is *not* brought up. - The system (warm) reboots. Then the driver complains about the target being unresponsive after uploading the firmware. Apparently the only way to make it work again is to unplug and then plug the USB dongle back, physically. It seems that if the USB port is not powered down during reboot (which happens with at least two different setups that I've tested it with), the device is left in a broken state. I would gladly help in tracing down this bug if only I knew where to start. Thanks for any suggestion. Hi Ignacy, i can't reproduce this issue on my system. I tested it with 4 different ath9_htc adapter. Without luck. Please provide as match information as possible: - Usb host controller - Adapter manufacture and version, or even better add it to the wiki, and upload some images: http://wikidevi.com/wiki/Main_Page - your kernel version I assume it is not firmware. May be there are some issue with boot loader on adapter. Are you sure that UART pins are not soldered? Current ath9k_htc do not have mechanism to reset an adapter. I will start to work on it after some other issues are done. PS: please find some way to enable uart, at least TX pin. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Thu, May 16, 2013 at 03:27:15PM +0200, thus spake Oleksij Rempel: Am 15.05.2013 15:42, schrieb Ignacy Gawedzki: Hi everyone, This is an old issue, about which it seems the first posts date back to 2009. With the latest possible version of the firmware for AR9271 and the latest possible wireless drivers, the issue is still there. Whether this is still the exact same problem every time remains to be checked, but it is annoying enough to deserve some consideration. The problem is that the driver can't talk to the device if the following conditions are met: - The system cold boots with the USB dongle inserted or the USB dongle is inserted on a running system. - The interface is *not* brought up. - The system (warm) reboots. Then the driver complains about the target being unresponsive after uploading the firmware. Apparently the only way to make it work again is to unplug and then plug the USB dongle back, physically. It seems that if the USB port is not powered down during reboot (which happens with at least two different setups that I've tested it with), the device is left in a broken state. I would gladly help in tracing down this bug if only I knew where to start. Thanks for any suggestion. Hi Ignacy, i can't reproduce this issue on my system. I tested it with 4 different ath9_htc adapter. Without luck. Without luck, but it seems you're the lucky one anyway. =) Please provide as match information as possible: - Usb host controller Tested both on Raspberry Pi and on Dell XPS 13. The latter uses Intel EHCI, 8086:1c2d and Fresco Logic 1b73:1009, I don't know which one is used exactly. - Adapter manufacture and version, or even better add it to the wiki, and upload some images: http://wikidevi.com/wiki/Main_Page TP-Link TL-WN722NC, exactly as the one on the wiki. - your kernel version Tested with 3.5.0 on XPS and 3.6.11, 3.8.12 and 3.9.2 on RPi (using a customized buildroot, but I can provide the .config if needed). I assume it is not firmware. May be there are some issue with boot loader on adapter. Are you sure that UART pins are not soldered? I opened the dongle, managed to solder the metal shield off and the pins weren't used (all four 48-51, among others). Current ath9k_htc do not have mechanism to reset an adapter. I will start to work on it after some other issues are done. Is it physically possible? PS: please find some way to enable uart, at least TX pin. I tried to solder the TX pin, but it's really too tiny. I don't have an iron so small as to be able to do it, sorry. I would really love to have an UART connection, but that's just beyond my abilities. BTW, it would really be great to have a way to send debug message up the USB link, just as with carl9170. Thanks for your help anyway, I hope we'll find a way to make that work. -- Sex on TV doesn't hurtunless you fall off. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 16.05.2013 19:20, schrieb Ignacy Gawedzki: On Thu, May 16, 2013 at 03:27:15PM +0200, thus spake Oleksij Rempel: Am 15.05.2013 15:42, schrieb Ignacy Gawedzki: Hi everyone, This is an old issue, about which it seems the first posts date back to 2009. With the latest possible version of the firmware for AR9271 and the latest possible wireless drivers, the issue is still there. Whether this is still the exact same problem every time remains to be checked, but it is annoying enough to deserve some consideration. The problem is that the driver can't talk to the device if the following conditions are met: - The system cold boots with the USB dongle inserted or the USB dongle is inserted on a running system. - The interface is *not* brought up. - The system (warm) reboots. Then the driver complains about the target being unresponsive after uploading the firmware. Apparently the only way to make it work again is to unplug and then plug the USB dongle back, physically. It seems that if the USB port is not powered down during reboot (which happens with at least two different setups that I've tested it with), the device is left in a broken state. I would gladly help in tracing down this bug if only I knew where to start. Thanks for any suggestion. Hi Ignacy, i can't reproduce this issue on my system. I tested it with 4 different ath9_htc adapter. Without luck. Without luck, but it seems you're the lucky one anyway. =) Please provide as match information as possible: - Usb host controller Tested both on Raspberry Pi and on Dell XPS 13. The latter uses Intel EHCI, 8086:1c2d and Fresco Logic 1b73:1009, I don't know which one is used exactly. - Adapter manufacture and version, or even better add it to the wiki, and upload some images: http://wikidevi.com/wiki/Main_Page TP-Link TL-WN722NC, exactly as the one on the wiki. That is interesting. I have got today TL-WN722N, but i still can't reproduce this issue. - your kernel version Tested with 3.5.0 on XPS and 3.6.11, 3.8.12 and 3.9.2 on RPi (using a customized buildroot, but I can provide the .config if needed). I assume it is not firmware. May be there are some issue with boot loader on adapter. Are you sure that UART pins are not soldered? I opened the dongle, managed to solder the metal shield off and the pins weren't used (all four 48-51, among others). Current ath9k_htc do not have mechanism to reset an adapter. I will start to work on it after some other issues are done. Is it physically possible? may be. PS: please find some way to enable uart, at least TX pin. I tried to solder the TX pin, but it's really too tiny. I don't have an iron so small as to be able to do it, sorry. I would really love to have an UART connection, but that's just beyond my abilities. BTW, it would really be great to have a way to send debug message up the USB link, just as with carl9170. That make no sense. Debug message i need, are from boot loader. There is no way, that boot loader can send messages over usb. Or if firmwre will crash, it wont send any thing too. So what do we have: - TL-WN722N is working. Or your model is different, or it is broken one. - Did you checked the cable? - usb host controller? - other options? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Thu, May 16, 2013 at 07:46:56PM +0200, thus spake Oleksij Rempel: Am 16.05.2013 19:20, schrieb Ignacy Gawedzki: TP-Link TL-WN722NC, exactly as the one on the wiki. That is interesting. I have got today TL-WN722N, but i still can't reproduce this issue. Are you sure that not any subsystem ups the interface before you have any chance to warm reboot? Or that you don't have a hub that cuts power to devices on warm reboot? I tried to solder the TX pin, but it's really too tiny. I don't have an iron so small as to be able to do it, sorry. I would really love to have an UART connection, but that's just beyond my abilities. BTW, it would really be great to have a way to send debug message up the USB link, just as with carl9170. That make no sense. Debug message i need, are from boot loader. There is no way, that boot loader can send messages over usb. Or if firmwre will crash, it wont send any thing too. I understand. So what do we have: - TL-WN722N is working. Or your model is different, or it is broken one. I happen to have 8 of them, bought at different times and all exhibit the problem. - Did you checked the cable? I usually plug the device directly to the USB port, but I also happen to use the cradle (supplied with the WN722NC version) that has a cable, when I need two wireless interfaces on the RPi (both of them don't fit at once directly on the ports). - usb host controller? I'll try on yet another one and will tell you the results. - other options? Hmmm... :/ -- -= Best Viewed Using [INLINE] =- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc max VIF limit set to 2
The current firmware architecture uses some RAM in the firmware for each vif/sta. Thus, the limitation. Adrian On 16 May 2013 11:57, Vittorio G (VittGam) linux-wirel...@vittgam.net wrote: Hello everybody, The ATH9K_HTC_MAX_VIF and ATH9K_HTC_MAX_BCN_VIF defines, as well as the ieee80211_iface_combination.max_interfaces and ieee80211_iface_limit.max properties are all set to 2 in the driver code. I'd like to know if this is some hardware or firmware limit, or if this could be changed to something higher as in the regular ath9k driver, which seems to have the limit set at 2048 STAs, 8 APs and 2048 total concurrent VIFs instead. I'm asking this before testing because I don't know if I could eventually damage the hardware if this is a hardware limitation (I don't think that it would be possible to damage the hardware by doing this, but who knows...) Thanks, Vittorio G ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki: I'll try on yet another one and will tell you the results. Just tried on ICH7, same thing. The easiest way to reproduce the bug is to boot into single user mode (recovery mode on Ubuntu), in order to prevent any NetworkManager or udev from interfering. Then, without any attempt to up the interface, reboot the system by typing reboot in a root shell. -- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Hi, On Fri, May 17, 2013 at 01:48:57AM +0200, Ignacy Gawedzki wrote: On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki: I'll try on yet another one and will tell you the results. Just tried on ICH7, same thing. The easiest way to reproduce the bug is to boot into single user mode (recovery mode on Ubuntu), in order to prevent any NetworkManager or udev from interfering. Then, without any attempt to up the interface, reboot the system by typing reboot in a root shell. FWIW, this has also been a problem for me on Ubuntu 12.04. I can reproduce it the same way. Thanks, Forest -- Forest Bond http://www.alittletooquiet.net http://www.rapidrollout.com signature.asc Description: Digital signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
