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 +-
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.
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
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(-)
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
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:
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
---
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
---
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
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
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
---
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
