On 2016-10-05 22:31, Rob Herring wrote:
> On Wed, Oct 5, 2016 at 1:36 PM, Felix Fietkau <n...@nbd.name> wrote:
>> On 2016-10-05 20:25, Martin Blumenstingl wrote:
>>> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring <robh...@kernel.org> wrote:
>>>> On Sun, O
On 2016-10-05 20:25, Martin Blumenstingl wrote:
> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring wrote:
>> On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
>> wrote:
>>> There are at least two drivers (ath9k and mt76) out there, where
>>>
On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <n...@nbd.name> writes:
>
>> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
>>> Kalle Valo <kv...@qca.qualcomm.com> writes:
>>>
>>>> Toke Høiland-Jørgensen wrote
On 2016-07-06 20:52, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <n...@nbd.name> writes:
>
>> On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote:
>>> This switches ath9k over to using the mac80211 intermediate software
>>> queueing mechanism for data pac
gt;
> Based on Tim's original patch set, but reworked quite thoroughly.
>
> Cc: Tim Shepard <s...@alum.mit.edu>
> Cc: Felix Fietkau <n...@nbd.name>
> Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk>
> ---
> Changes since v1:
> - Remove the ol
On 2016-07-04 19:46, Toke Høiland-Jørgensen wrote:
> Tim Shepard writes:
>
>> Thanks for unconfusing me a couple weeks ago, and cluing me into how
>> the limit on ->pending_frames is not really relevant for the data
>> packets that go through the new intermediate queues.
>>
>>
On 2016-06-27 14:57, Mark Rutland wrote:
> On Thu, Jun 23, 2016 at 08:14:29PM +0200, Martin Blumenstingl wrote:
>> On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland wrote:
>> > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote:
>> >> +- qca,eeprom-name: The
On 2016-06-24 14:34, Martin Blumenstingl wrote:
> Signed-off-by: Martin Blumenstingl
> ---
> this is a new patch which didn't exist in v2 yet, it prepares the new
> function ath_bus_type_to_string which will be used in patch #3
>
>
On 2016-06-17 15:48, Felix Fietkau wrote:
> On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <n...@nbd.name> writes:
>>
>>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
>>>> This patch leaves the code for ath9k's internal per-
On 2016-06-17 15:41, Tim Shepard wrote:
>> > diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
>> > b/drivers/net/wireless/ath/ath9k/ath9k.h
>> > index 93b3793..caeae10 100644
>> > --- a/drivers/net/wireless/ath/ath9k/ath9k.h
>> > +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
>> > @@ -145,8
On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <n...@nbd.name> writes:
>
>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
>>> This patch leaves the code for ath9k's internal per-node per-tid
>>> queues in place and just modifies the
On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote:
> This patch leaves the code for ath9k's internal per-node per-tid
> queues in place and just modifies the driver to also pull from
> the new mac80211 intermediate software queues, and implements
> the .wake_tx_queue method, which will cause
On 2016-06-07 15:10, Benjamin Berg wrote:
> From: Benjamin Berg
>
> Signed-off-by: Benjamin Berg
> ---
> drivers/net/wireless/ath/ath9k/main.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git
On 2016-05-17 12:54, Zefir Kurtisi wrote:
> On 05/14/2016 02:50 PM, Felix Fietkau wrote:
>> On 2016-04-01 11:37, Zefir Kurtisi wrote:
>>> Tx power limitations at upper layers are interpreted in
>>> the EIRP domain. When the user requests a given maximum
>>> txpo
On 2016-04-01 11:37, Zefir Kurtisi wrote:
> Tx power limitations at upper layers are interpreted in
> the EIRP domain. When the user requests a given maximum
> txpower, e.g. with: 'iw phy0 set txpower fixed 1500',
> he expects the EIRP to be at or below 15dBm.
>
> In ath9k_hw_apply_txpower(), the
>
> Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE
> marcros instead.
>
> Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
> Cc: Felix Fietkau <n...@openwrt.org>
> ---
> Just stumbled over that piece of code while looking
On 2015-06-22 13:59, Johannes Berg wrote:
On Mon, 2015-06-22 at 13:58 +0200, Johannes Berg wrote:
On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
mac80211 configure rxfilter per HW,
so we don't need this per channel.
As I said before, I think there's value in mac80211 doing it
On 2015-06-10 07:03, Janusz Dziedzic wrote:
This fix problem that p2p group negotiation didn't work
correctly when chanctx used, because we didn't receive
probe requests when offchannel and use_chanctx=1
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
@Felix, Sujith could you
On 2015-05-16 07:24, Oleksij Rempel wrote:
Am 15.05.2015 um 21:34 schrieb Felix Fietkau:
On 2015-05-15 14:35, Oleksij Rempel wrote:
... and move dup code from ar5008_phy.c and ar9002_phy.c to phy.c
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
We already have base functionality
On 2015-05-15 14:35, Oleksij Rempel wrote:
... and move dup code from ar5008_phy.c and ar9002_phy.c to phy.c
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
We already have base functionality for AR5008-AR9002 provided in some
ar5008_phy.c, and ar5008_hw_attach_phy_ops is called for those
On 2015-03-20 13:38, Oleksij Rempel wrote:
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/eeprom_def.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c
On 2015-03-20 13:38, Oleksij Rempel wrote:
it is possible to reduce time needed for this function
by rplacing REG_WRITE with REG_RMW (plus dummy 0) and putt all commands
in same buffer.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/eeprom_4k.c |
.
Cc: sta...@vger.kernel.org
Signed-off-by: Felix Fietkau n...@openwrt.org
---
drivers/net/wireless/ath/ath9k/beacon.c | 20
drivers/net/wireless/ath/ath9k/common.h | 2 +-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/beacon.c
b
On 2015-02-10 11:34, Yuwei Zheng wrote:
The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
chance to excute than
ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf
Hi Seongho,
that paper looks quite interesting.
Are you planning to publish code/patches for your implementation as well?
It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht.
Thanks,
- Felix
On 26/10/2014 12:14 AM, Seongho Byeon wrote:
Hi, I am Ph.d. student in Seoul
On 2014-07-14 06:25, Sujith Manoharan wrote:
Dave Taht wrote:
cc-ing ath9k-devel for this update on http://www.bufferbloat.net/issues/442
this bug, which some people (usually on macs with low signal strength)
can get to occur fairly rapidly, but I can't, is driving me 9 kinds of
crazy...
On 2014-07-13 12:18, Lorenzo Bianconi wrote:
Disable ack timeout estimation algorithm if the coverage class has been
configured
Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com
I think this is broken, since it doesn't allow you to re-enable dynack
through the same way as it was
On 2014-07-07 13:41, Thomas Hühn wrote:
+{
+struct ath_node *an;
+u32 to = 0;
+struct ath_dynack *da = ah-dynack;
+struct ath_common *common = ath9k_hw_common(ah);
+
+list_for_each_entry(an, da-nodes, list)
+if (an-ackto to)
+to =
On 2014-05-07 21:54, John W. Linville wrote:
On Wed, May 07, 2014 at 09:22:58AM +0200, David Herrmann wrote:
ah-caldata may be NULL if no channel is selected. Check for that before
accessing it.
Signed-off-by: David Herrmann dh.herrm...@gmail.com
---
Hi
This is _definitely_ only a
On 2014-04-29 14:04, Tim Harvey wrote:
On Tue, Apr 22, 2014 at 2:09 AM, Felix Fietkau n...@openwrt.org wrote:
On 2014-04-22 01:14, Tim Harvey wrote:
Implement a recv budget so that in cases of high traffic we still allow
other
taskets to get processed.
Without this, we can encounter a host
the correct TID if we are processing a
data frame. Furthermore, prevent non-data frames to get a sequence
number from a TID sequence counter by adding a check to
ath_tx_setup_buffer.
Cc: Felix Fietkau n...@openwrt.org
Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com
On 2014-04-17 02:40, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
Make sure we cannot ever assign beacon interval to zero.
Signed-off-by: Ben Greear gree...@candelatech.com
---
drivers/net/wireless/ath/ath9k/beacon.c | 4
On 2014-03-10 15:40, Michael Braun wrote:
Before, ath9k divided time in ATH_BCBUF many equally sized slots.
Each bss then was assigned to a single slot, leaving some or more slots empty.
The beacons of a bss were sent at the beginning of the slot for this bss,
and then the buffered multicast
On 2014-02-23 20:44, Marco André Dinis wrote:
Hi
I started downloding a file and this is the output from ''dmesg'' (less
than 30 sec)
[ 167.654939] wlp5s0: associated
[ 167.654953] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready
[ 174.900658] net_ratelimit: 47 callbacks
On 2014-02-17 03:27, Sujith Manoharan wrote:
Felix Fietkau wrote:
Wouldn't it be better to do this for all AR93xx chipsets in
ar9003_hw_apply_minccapwr_thresh instead of initvals?
I'm pretty sure this patch will leave most other devices non-compliant.
The threshold values are adjusted
On 2014-02-14 02:45, Dimosthenis Pediaditakis wrote:
Hi all,
I am using a capacity and available bandwidth measurement software that
compute estimates based on the gaps among packet trains/pairs.
For that reason I need to disable RX/TX interrupt mitigation for the
devices that I take the
On 2014-02-14 03:45, Sujith Manoharan wrote:
From: Sujith Manoharan c_man...@qca.qualcomm.com
The minimum CCA power threshold values have to be adjusted
for existing cards to be in compliance with new regulations.
Newer cards will make use of the values obtained from EEPROM,
support for
On 2014-02-03 12:22, Oleksij Rempel wrote:
Am 03.02.2014 03:09, schrieb Sujith Manoharan:
Oleksij Rempel wrote:
+ rx_stats = kzalloc(sizeof(struct ath_rx_status), GFP_KERNEL);
+ if (unlikely(rx_stats == NULL)) {
+ ath_err(common, rx_stats allocation filed!\n);
+ goto
(ath9k:
optimize ath9k_flush).
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Acked-by: Felix Fietkau n...@openwrt.org
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
On 2013-12-13 10:48, Sebastian Moeller wrote:
Hi Sujith,
On Dec 13, 2013, at 10:27 , Sujith Manoharan suj...@msujith.org wrote:
Sebastian Moeller wrote:
It is a net gear WNDR3700 v2, so according to:
http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2
680
MHz soc
On 2013-09-09 1:29 PM, Nicolás Echániz wrote:
I have kept testing this and was able to reproduce the same problem
every time.
The performance perception when the network is at rush hour is very
unstable so I tried to reproduce traffic conditions during late night.
I sent multiple netperfs
On 2013-08-07 8:59 AM, Sujith Manoharan wrote:
From: Sujith Manoharan c_man...@qca.qualcomm.com
The LNA combining algorithm has to be run for cards
that support the required diversity features, make
sure that that correct conditions are met before
enabing this algorithm.
Signed-off-by:
On 2013-08-06 6:04 PM, Michael Braun wrote:
On Tue, Aug 06, 2013 at 01:18:51PM +0200, Michael Braun wrote:
Also, can you please test
with the latest one (I just committed some more fixes).
those have been running for for some hours and I could not reproduce the
problem anymore,
On 2013-07-19 4:58 PM, Sergey Ryazanov wrote:
2013/7/19 Ben Greear gree...@candelatech.com:
On 07/19/2013 06:36 AM, Flavio Leonel wrote:
Ok i know that but the command iw not permited set sensitivity limit
how i can seting this limit on atth9k , this question..
I tried messing with this
On 2013-07-16 2:46 PM, Gerrit van der Bij wrote:
Hi,
I have a small project where I used a 32 Mbyte flash in a TP-Link MR-11U
running OpenWrt AA. The device is based on the AR9331 chip. The kernel
disables the SPI interface of the AR9331, so the flash is no longer
memory mapped.
To
On 2013-07-09 10:50 AM, Oleksij Rempel wrote:
How replacing AP with about MESH or AdHock+BATMAN?
Why? That sounds like a recipe for disaster to me (at least for
conference networks). The ath9k_htc stuff can't handle more peers in
mesh/ad-hoc than clients in AP mode.
In setting up a conference
On 2013-07-09 11:34 AM, Oleksij Rempel wrote:
Am 09.07.2013 11:18, schrieb Felix Fietkau:
On 2013-07-09 10:50 AM, Oleksij Rempel wrote:
How replacing AP with about MESH or AdHock+BATMAN?
Why? That sounds like a recipe for disaster to me (at least for
conference networks). The ath9k_htc stuff
On 2013-06-20 6:05 PM, Adam Allred wrote:
Hello,
I am attempting to build an AP that can support airplay streaming
between various mac devices. My current test bed is as follows:
Macbook Pro 10,2 (13 Retina), with an Airport Extreme (0x14E4, 0x10F)
card, which is using the BCM43xx driver
On 2013-06-20 6:49 PM, Adam Allred wrote:
I picked it up off of
http://ubuntuforums.org/showthread.php?t=1746326
and only tried it after I had a working connection, just to see if it
would make a difference, since it's ubuntu and a AR92xx series card in
that post. Performance is the same
On 2013-06-20 12:26 PM, David Goodenough wrote:
On Wednesday 19 Jun 2013, Ben Greear wrote:
On 06/19/2013 03:56 PM, Adrian Chadd wrote:
.. just keep in mind that adjacent high power transmitters can
actually leak enough RF to trigger ADC saturation and thus the device
may actually not try
On 2013-06-20 8:13 PM, David Goodenough wrote:
On Thursday 20 Jun 2013, Felix Fietkau wrote:
On 2013-06-20 12:26 PM, David Goodenough wrote:
On Wednesday 19 Jun 2013, Ben Greear wrote:
On 06/19/2013 03:56 PM, Adrian Chadd wrote:
.. just keep in mind that adjacent high power transmitters
On 2013-06-14 3:51 PM, shinnazar wrote:
Hi all,
Is there anybody who worked on BAW(Block Ack Window) sliding mechanism
in ath9k? Is it possible to disable this mechanism?
What would you want to do that for? It seems to me that all this would
accomplish is to get the tx path stuck after a
On 2013-06-12 10:00 AM, Calvin Owens wrote:
Copying the rate table should be done in an RCU read-side critical
section.
I think this approach is wrong. The sta entry is also under RCU
protection (no locking for read access in that part of the code.
In a normal driver tx path, no extra
On 2013-05-16 11:09 AM, Michal Kazior wrote:
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
On 2013-05-09 3:42 PM, Oleksij Rempel wrote:
Hallo Felix,
i found your patches for moving ath9k to minstrel_ht and decided to do
some testing.
For some reason, minstrel_ht exclude all HT40 rates in my network. With
native ath9k rate controller I'm able to use HT40.
Do you have any idea
On 2013-05-09 5:09 PM, Oleksij Rempel wrote:
Am 09.05.2013 16:41, schrieb Felix Fietkau:
On 2013-05-09 3:42 PM, Oleksij Rempel wrote:
Hallo Felix,
i found your patches for moving ath9k to minstrel_ht and decided to do
some testing.
For some reason, minstrel_ht exclude all HT40 rates in my
On 2013-05-07 2:03 PM, Bhavesh Kamani wrote:
Hi Ben,
I tried compat-drivers-3.9-rc4-2-su, then also same problem I faced.
I also tried compat-wireless-2.6.39-1 and compat-wireless-3.6.8-1, but
facing the same issue.
In a day more than one clients are facing the same issue.
In the
On 2013-05-04 8:50 AM, Oleksij Rempel wrote:
Am 02.05.2013 22:15, schrieb Adrian Chadd:
Well, let's dig into the firmware a bit more and tidy up how STBC is handled.
Does it mean, i should change this patch and provide a patch for
firmware too?
I still do not think, changing peer caps i a
On 2013-05-04 1:08 PM, Oleksij Rempel wrote:
Am 04.05.2013 12:02, schrieb Felix Fietkau:
On 2013-05-04 8:50 AM, Oleksij Rempel wrote:
Am 02.05.2013 22:15, schrieb Adrian Chadd:
Well, let's dig into the firmware a bit more and tidy up how STBC is
handled.
Does it mean, i should change
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 li...@rempel-privat.de 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
On 2013-05-01 6:01 PM, Ben Greear wrote:
On 04/30/2013 11:05 AM, Ben Greear wrote:
On 04/28/2013 08:05 AM, Ben Greear wrote:
On 04/27/2013 01:58 AM, Felix Fietkau wrote:
On 2013-04-27 1:46 AM, Ben Greear wrote:
Was running around 200 stations against a VAP on this system, and
then changed
On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
Collect statistics about recived duplicate and STBC packets.
This information should help see if STBC is actually working.
Tested on ar9285;
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
I thought about this patch some more, and I'm
On 2013-04-28 4:54 PM, Ben Greear wrote:
On 04/28/2013 05:51 AM, Felix Fietkau wrote:
On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
Collect statistics about recived duplicate and STBC packets.
This information should help see if STBC is actually working.
Tested on ar9285;
Signed-off
On 2013-04-28 5:15 PM, Ben Greear wrote:
On 04/28/2013 08:08 AM, Felix Fietkau wrote:
On 2013-04-28 4:54 PM, Ben Greear wrote:
On 04/28/2013 05:51 AM, Felix Fietkau wrote:
On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
Collect statistics about recived duplicate and STBC packets
On 2013-04-28 9:19 PM, Oleksij Rempel wrote:
Am 28.04.2013 17:03, schrieb Oleksij Rempel:
Am 28.04.2013 16:13, schrieb Oleksij Rempel:
Am 28.04.2013 14:51, schrieb Felix Fietkau:
On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
Collect statistics about recived duplicate and STBC packets
On 2013-04-27 1:46 AM, Ben Greear wrote:
Was running around 200 stations against a VAP on this system, and
then changed the channel from 1 to 36 (by restarting hostapd with new
config).
Looks like null-pointer de-ref... Anyone seen anything similar?
I've never seen this one. Please use gdb
On 2013-04-27 9:06 PM, Adrian Chadd wrote:
On 27 April 2013 11:53, Oleksij Rempel li...@rempel-privat.de wrote:
(And then go and re-align things inside that struct so you don't waste
space.)
hmm.. what do you mean here?
Structure alignment? Well, you typically want to have everything be
On 2013-04-22 12:08 PM, Simon Wunderlich wrote:
Hey Felix,
just wanted to bump on this issue again, as it has not been applied
yet - the patch seems still valid, and Mathias results appear to show
that as well. What do you think?
Looks ok to me, let's get it merged.
- Felix
On 2013-04-12 10:27 AM, Rougu wrote:
Hi everyone,
while I might be totally wrong with my observation, I still would like
to share it, because this issue is lingering for years now and many
users are waiting to a solid grip on it to fix it.
I'm running several freifunk-nodes in Cologne,
On 2013-04-12 6:57 PM, Jan Lühr wrote:
Hallo Felix,
Am 12.04.2013 um 17:41 schrieb Felix Fietkau:
On 2013-04-12 10:27 AM, Rougu wrote:
while I might be totally wrong with my observation, I still would like
to share it, because this issue is lingering for years now and many
users
On 2013-04-11 1:20 AM, Adrian Chadd wrote:
On 10 April 2013 15:03, Tobias Steinicke
tobias.steini...@net.t-labs.tu-berlin.de wrote:
In routine ath_tx_fill_desc(), the txpower is only set to
MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it
is (txpower * 2)
On 2013-04-02 2:03 PM, Robert Shade wrote:
On Mon, Apr 1, 2013 at 1:40 PM, Felix Fietkau n...@openwrt.org wrote:
Your patch is badly whitespace damaged.
Ouch, must be the gmail web client. I'll resubmit a fixed one.
Why the call to ath9k_hw_set_interrupts here?
Simply because that's
On 2013-04-01 4:22 PM, Robert Shade wrote:
Re-enable interrupts after a channel change failure, since
ath_complete_reset will not be called. Also schedule a reset as a
best effort method to recover the chip from whatever state caused the
channel change failure.
Signed-off-by: Robert Shade
On 2013-03-27 7:49 PM, John Clark wrote:
Many people seem to desire the bit rate to be the 'highest possible',
and have that automagically set.
What's wrong with the current behavior of picking the rate that causes
the least wasted airtime?
For some applications, I like to be able to set a
On 2013-03-24 5:26 PM, Pannirselvam Kanagaratnam wrote:
Hello,
My WiFi connection drops while running the AR9280 on a Freescale
MPC8315E platform in AP mode with hostapd. I get the following error
within 15 seconds and the WiFi connection drops. However, I do not
observe any issues when
On 2013-03-16 9:19 PM, abhinav narain wrote:
guess aggr of 1462 bytes ?),
but why are those seq. numbers never re-used ?
Your traces don't give you the full picture, because looking at this as
a per-frame thing is wrong.
If both IEEE80211_TX_CTL_AMPDU and
On 2013-03-12 7:16 PM, Ben Greear wrote:
On 02/22/2013 04:55 AM, Ben Greear wrote:
On 02/22/2013 04:38 AM, Felix Fietkau wrote:
On 2013-02-22 1:25 PM, Sujith Manoharan wrote:
Felix Fietkau wrote:
Please also check if the station(s) that the frames are queued for are
in powersave state
On 2013-03-13 12:48 AM, abhinav narain wrote:
Hi Felix, Adrian,
/* This packet was aggregated but doesn't carry status info */
if ((info-flags IEEE80211_TX_CTL_AMPDU)
!(info-flags IEEE80211_TX_STAT_AMPDU))
return;
Any packet with
On 2013-03-11 7:20 PM, abhinav narain wrote:
Is this being recorded on transmit, or transmit completion? I'm
guessing this is transmit completion on the transmit side.
Is this information coming from the driver, or from some completion
status going up to mac80211?
Partly
On 2013-03-11 8:51 PM, Ben Greear wrote:
On 03/11/2013 12:05 PM, John W. Linville wrote:
On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
Otherwise, can't get the Sparklan AR9380 NICs to be
5Ghz APs, since they are in
On 2013-03-11 10:01 PM, Ben Greear wrote:
On 03/11/2013 01:17 PM, Felix Fietkau wrote:
On 2013-03-11 8:51 PM, Ben Greear wrote:
On 03/11/2013 12:05 PM, John W. Linville wrote:
On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
On 2013-03-11 10:44 PM, Ben Greear wrote:
On 03/11/2013 02:36 PM, Felix Fietkau wrote:
On 2013-03-11 10:01 PM, Ben Greear wrote:
On 03/11/2013 01:17 PM, Felix Fietkau wrote:
I am not sure what you are suggesting. I enabled this override
only when ONUS is selected because I wanted it clear
On 2013-03-11 11:00 PM, Ben Greear wrote:
On 03/11/2013 02:51 PM, Felix Fietkau wrote:
On 2013-03-11 10:44 PM, Ben Greear wrote:
On 03/11/2013 02:36 PM, Felix Fietkau wrote:
On 2013-03-11 10:01 PM, Ben Greear wrote:
On 03/11/2013 01:17 PM, Felix Fietkau wrote:
I am not sure what you
On 2013-03-04 11:28 PM, Ben Greear wrote:
It seems there is some mac80211 framework for handling per VIF tx-power
settings now, but from what I can tell, this is not supported in ath9k.
Correct.
Any idea how feasible it is to do per-vif tx-power in ath9k? I think
it would come down to
On 2013-02-27 9:58 AM, abhinav narain wrote:
Thanks Felix, I think I wasn't clear in asking my question.
Sorry about that, is it possible you can answer one below ?
On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau n...@openwrt.org
mailto:n...@openwrt.org wrote:
On 2013-02-26 7:51 PM
On 2013-02-27 4:26 PM, abhinav narain wrote:
As the timestamp of 4 frames are the same or or the sum of bytes of 4
frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
1500 bytes (4K or 8K)
Is it because frames are split up ( before ath_tx_complete_buf()) on
On 2013-02-26 7:51 PM, abhinav narain wrote:
Thanks for the response, Felix !
I have some questions to ask :
(1) So I should interpret the ath_tx_status descriptor as :
14 retransmissions occurred while transmission of 1542*4 bytes.
Its not 14*4 retransmissions.
Aggregates are formed by the
On 2013-02-25 9:53 PM, abhinav narain wrote:
You are right in that case, Adrian.
*tsf ,retx count, rates and transmit attempts, sequence no, frame size*
*[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
*[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
*[315063930,
On 2013-02-23 9:13 PM, Oleksij Rempel wrote:
Am 23.02.2013 12:41, schrieb Adrian Chadd:
On 23 February 2013 01:54, Oleksij Rempel bug-tr...@fisher-privat.net
wrote:
Hi Adrian,
current driver has this check:
htc_drv_init.c: priv-fw_version_minor != MINOR_VERSION_REQ) {
htc_drv_init.c:
On 2013-02-22 6:26 AM, Ben Greear wrote:
On 02/21/2013 08:49 PM, Sujith Manoharan wrote:
Ben Greear wrote:
I'll be happy to test patches, but I'm not sure how to go about
debugging the real problem on my own. Maybe some stats could
be added to the xmit debugfs file to help diagnose the
On 2013-02-22 1:25 PM, Sujith Manoharan wrote:
Felix Fietkau wrote:
Please also check if the station(s) that the frames are queued for are
in powersave state for some reason. That would prevent the tx path from
throwing them in the hw queue, yet they'd still take up pending-frame
slots. I
On 2013-02-01 1:50 PM, Bernhard Urban wrote:
add an if-guard, otherwise iw(8) reports weird signal strengths.
The behaviour was fine before this commit:
7c277349ecbd66e19fad3d949fa6ef6c131a3b62
Therefore, this patch is a partially revert of it.
I think your commit message is a bit
On 2012-12-05 11:40 AM, Simon Wunderlich wrote:
I suggest experimenting around with those particular parameters. You
should be able to coax out specific numbers of spectral scan events
when you set the COUNT parameter to something other than 8. But
polling that bit isn't needed. It should be
On 2012-11-20 11:05 AM, Felix Liao wrote:
Hi Felix F, I'm Felix Liao from WatchGuard, I think we should
spin_lock_irqsave and spin_unlock_irqrestore on sc_pcu_lock
in the ath9k_tasklet() instead of spin_lock/spin_unlock, just to avoid the
tasklet being interrupted by the hardware IRQ,
do
On 2012-11-09 6:09 PM, Bernhard Urban wrote:
add an if-guard, otherwise iw(8) reports weird signal strengths.
The behaviour was fine before this commit:
7c277349ecbd66e19fad3d949fa6ef6c131a3b62
This patch is therefore a partially revert of it.
Tested with TP-Link TL-WN722N
Thanks to
On 2012-10-31 2:32 PM, Hauke Mehrtens wrote:
On 10/31/2012 12:23 PM, Zefir Kurtisi wrote:
Add 5% width tolerance for radar patterns defined by ETSI.
Signed-off-by: Zefir Kurtisi zefir.kurt...@neratec.com
---
.../net/wireless/ath/ath9k/dfs_pattern_detector.c |7 ++-
1 files
On 2012-10-30 1:07 PM, Simon Wunderlich wrote:
From: Mathias Kretschmer mathias.kretsch...@fokus.fraunhofer.de
According to 802.11-2007 17.3.8.6 (slot time), the slot time should
be increased by 3 us * coverage class. The code only increased the
ack timeout, which is fixed by this patch.
On 2012-10-30 2:00 PM, Mathias Kretschmer wrote:
On 10/30/2012 01:43 PM, Felix Fietkau wrote:
On 2012-10-30 1:07 PM, Simon Wunderlich wrote:
From: Mathias Kretschmer mathias.kretsch...@fokus.fraunhofer.de
According to 802.11-2007 17.3.8.6 (slot time), the slot time should
be increased by 3
Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de
Nice catch, thanks!
Acked-by: Felix Fietkau n...@openwrt.org
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
On 2012-10-29 1:34 PM, Felix Fietkau wrote:
On 2012-10-29 1:25 PM, Sven Eckelmann wrote:
The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case
only one frame is currently available. The client will then answer using a
normal Ack instead of a BlockAck
1 - 100 of 260 matches
Mail list logo