* Re: [PATCH 0/8] iw: Add common chandef parser and new DFS related commands
From: Johannes Berg @ 2016-11-16 12:41 UTC (permalink / raw)
To: Benjamin Berg; +Cc: linux-wireless, sw, Benjamin Berg
In-Reply-To: <20161107145943.16761-1-benjamin@sipsolutions.net>
On Mon, 2016-11-07 at 15:59 +0100, Benjamin Berg wrote:
> From: Benjamin Berg <benjamin.berg@open-mesh.com>
>
> Hi,
>
> This patchset adds commands for doing a CAC and sending CSA.
>
> Another change is that parsing of command line frequency and channel
> definitions is split out so that it can be shared between the
> different users.
That's nice :)
I've applied all except for patch 7 - I don't see any justification for
adding that - quite clearly iw will not listen to any radar detection
events, so even for testing/certification this doesn't seem useful
since then you'd want to check/prove that you *do* listen to those ...
johannes
^ permalink raw reply
* Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor
From: Stanislaw Gruszka @ 2016-11-16 12:02 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless, Helmut Schaa, Felix Fietkau
In-Reply-To: <e4dfaa30-7dd6-c485-3e30-71bfafbc1502@kresin.me>
On Wed, Nov 16, 2016 at 09:07:00AM +0100, Mathias Kresin wrote:
> Here are the results of the requested tests. Please keep in mind, I'm not in
> a lab environment:
>
> LEDE head
> connect
> action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
> action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
> action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
> action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
No problem here - buf_size corresponds to ampdu_factor.
> ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
> to flush
> ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
> to flush
I think we do not give device enough time to post AMPDU consisted
with bigger amount of frames. If we want to increase ba_size we will
need also some other changes in the driver. Anyway I already request
Kalle to drop this patch. I assume other patches do not cause
regression for you, correct?
Thanks for testing.
Stanislaw
^ permalink raw reply
* [PATCH v2 04/10] rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
From: Stanislaw Gruszka @ 2016-11-16 11:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1478095865-8651-5-git-send-email-sgruszka@redhat.com>
We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on
rt2800_init_registers() for USB devices. For PCI devices we will use
HW default setting, which is 2, so patch does not change behaviour
on PCI devices.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
v1 -> v2 Changelog fixes
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index feceb13..9ecdc4c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -6756,7 +6756,6 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 1);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 1);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_WP_DMA_BURST_SIZE, 2);
rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_WRITEBACK_DONE, 1);
rt2800_register_write(rt2x00dev, WPDMA_GLO_CFG, reg);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Arend Van Spriel @ 2016-11-16 10:38 UTC (permalink / raw)
To: Kalle Valo, Gianfranco Costamagna
Cc: brcm80211-dev-list@broadcom.com, linux-wireless@vger.kernel.org,
nsmaldone@tierratelematics.com, Marco.Arlone@roj.com
In-Reply-To: <87r36dov6u.fsf@purkki.adurom.net>
On 15-11-2016 12:10, Kalle Valo wrote:
> Gianfranco Costamagna <locutusofborg@debian.org> writes:
>
>>> Well, not before you pointed it out ;-). You are welcome to send a patch
>>> fixing it. Otherwise, I will take care of it.
>>
>> attaching a format-patch like version.
>> I don't think we need a Tested-by or whatever, because it is just a typo in a comment.
>> (this is my first contribution, feel free to rebase or change whatever you prefer
>> to make it in line with other styles)
>>
>> (I gave authorship to Marco, the first one who discovered such typo)
>
> [...]
>
>> Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
>> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
>> Signed-off-by: Arlone Marco <marco.arlone@roj.com>
>
> Please note that you cannot add Signed-off-by for other people without
> their explicit approval (see Documentation/SubmittingPatches). I don't
> know if they did it in this case or not, but wanted to point out this
> anyway.
Thanks, Kalle
It was on my list to give a contrib boot camp here. So let's go over
things here albeit it late.
Hi Gianfrance,
A couple of things from which you may benefit for future contributions.
Basic info can be found in Documentation/SubmittingPatches as Kalle
indicated.
Patches should not be submitted as attachments. After doing 'git
format-patch' the easiest way is using 'git send-email' (which requires
you to have sendmail on your system properly setup). I tend to send
patches to Kalle and Cc: linux-wireless, but that is my personal
preference. Sending it to the list should be sufficient as patchwork
will pick it up [1].
When it comes to attribution of others you should have their approval
for Signed-off-by. However, reading your remarks it seems a proper way
is below:
Reported-by: Arlone Marco <marco.arlone@roj.com>
Tested-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
Regards,
Arend
[1] https://patchwork.kernel.org/project/linux-wireless/list/
^ permalink raw reply
* [PATCH] ath9k: fix NULL pointer dereference
From: miaoqing @ 2016-11-16 9:23 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath9k-devel, devin.tuchsen, Miaoqing Pan
From: Miaoqing Pan <miaoqing@codeaurora.org>
relay_open() may return NULL, check the return value to avoid the crash.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
PGD 41cf28067 PUD 41be92067 PMD 0
Oops: 0000 [#1] SMP
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35
Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15 07/04/2011
task: ffffffff81e0c4c0 task.stack: ffffffff81e00000
RIP: 0010:[<ffffffffa01a95c5>] [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98
RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0
Stack:
0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9
000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0
0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60
Call Trace:
<IRQ>
[<ffffffffa01b6441>] ath9k_tasklet+0x1b1/0x220 [ath9k]
[<ffffffff8105d8dd>] tasklet_action+0x4d/0xf0
[<ffffffff8105dde2>] __do_softirq+0x92/0x2a0
Reported-by: Devin Tuchsen <devin.tuchsen@gmail.com>
Tested-by: Devin Tuchsen <devin.tuchsen@gmail.com>
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c b/drivers/net/wireless/ath/ath9k/common-spectral.c
index e2512d5..eedf86b 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -528,6 +528,9 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, struct ieee80211_h
if (!(radar_info->pulse_bw_info & SPECTRAL_SCAN_BITMASK))
return 0;
+ if (!spec_priv->rfs_chan_spec_scan)
+ return 1;
+
/* Output buffers are full, no need to process anything
* since there is no space to put the result anyway
*/
@@ -1072,7 +1075,7 @@ static int remove_buf_file_handler(struct dentry *dentry)
void ath9k_cmn_spectral_deinit_debug(struct ath_spec_scan_priv *spec_priv)
{
- if (IS_ENABLED(CONFIG_ATH9K_DEBUGFS)) {
+ if (IS_ENABLED(CONFIG_ATH9K_DEBUGFS) && spec_priv->rfs_chan_spec_scan) {
relay_close(spec_priv->rfs_chan_spec_scan);
spec_priv->rfs_chan_spec_scan = NULL;
}
@@ -1086,6 +1089,9 @@ void ath9k_cmn_spectral_init_debug(struct ath_spec_scan_priv *spec_priv,
debugfs_phy,
1024, 256, &rfs_spec_scan_cb,
NULL);
+ if (!spec_priv->rfs_chan_spec_scan)
+ return;
+
debugfs_create_file("spectral_scan_ctl",
S_IRUSR | S_IWUSR,
debugfs_phy, spec_priv,
--
1.9.1
^ permalink raw reply related
* RE: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
From: Stam, Michel [FINT] @ 2016-11-16 8:54 UTC (permalink / raw)
To: Adrian Chadd
Cc: Johannes Berg, Sebastian Gottschall, Kalle Valo,
Antonio Quartulli, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Antonio Quartulli
In-Reply-To: <CAJ-VmonW7jR0vnnZmj8CsvY-6-O--L68LpBxcuXQ8Pk46AOQNQ@mail.gmail.com>
SGV5IEFkcmlhbiwNCg0KU291bmRzIGxpa2UgYW4gaWRlYSwgYWx0aG91Z2ggdXAgdG8gdGhpcyBw
b2ludCBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBkZXRlY3Qgd2hldGhlciByZXBsdW1iaW5nIGlz
IG5lY2Vzc2FyeS4gZGVjcnlwdF9lcnJvcnMgZG9lcyBub3QgaW5jcmVtZW50IGV4cG9uZW50aWFs
bHkgb24gdGhlIHJlY2VpdmUgcGF0aCwgYXMgZmFyIGFzIEkgc2F3IG9ubHkgb25lIGRlY3J5cHRf
ZXJyb3IgY29tZXMgdGhyb3VnaCwgd2hpY2ggY291bGQganVzdCBhcyB3ZWxsIGJlIGEgY29ycnVw
dGVkIGZyYW1lLiBJIGhhdmUgbm90IHNlZW4gYW55IG90aGVyIGluZGljYXRvcnMgb2YgdGhpcyBp
c3N1ZSwgb3RoZXIgdGhhbiBhIGNvbXBsZXRlIGxhY2sgb2YgY29ubmVjdGl2aXR5IG9uIHVuaWNh
c3QgZnJhbWVzLg0KDQpTbyB0aGlzIGF0dGVtcHQgd2FzIHRvIHNlZSBpZiBJIGNvdWxkIGdldCB0
aGUgbGluayBzdGFibGUsIGluIGFueSB3YXkgcG9zc2libGUsIGJ5IGJsYW5rbHkgcmVwbHVtYmlu
ZyBvbiBldmVyeSByZWtleS4gVGhpcyBzaG91bGQsIGluIHRoZW9yeSAic29sdmUiIHRoZSBpc3N1
ZSwgYWx0aG91Z2ggYXQgdGhlIGNvc3Qgb2YgaHVnZSBwYWNrZXQgbG9zcy4gU28gZmFyLCBubyBn
by4NCg0KSSBhZ3JlZSB0aGF0IHNvbWUgZm9ybSBvZiBrZXkgY2FjaGluZyBtYXkgYmUgbmVjZXNz
YXJ5LiBJdCBpcyBhIHBpdHksIGJlY2F1c2UgdGhlIG1hYzgwMjExIGxheWVyIGRvZXMgaGF2ZSBh
biBpbnRlcmZhY2UgZm9yIGdyYWJiaW5nIHRoZSBrZXlzLCBhbHRob3VnaCBpdCByZXF1aXJlcyB0
aGUgcnRubF9sb2NrLiBBcyBmYXIgYXMgSSBzYXcsIG9ubHkgdGhlIEludGVsIHdpcmVsZXNzIGRy
aXZlciB1c2VzIGl0IHRvIHdyaXRlIHRoZSBrZXlzIGJhY2sgaW50byB0aGUgY2hpcCB1cG9uIHJl
c3VtaW5nIGZyb20gYSBsb3ctcG93ZXIgc3RhdGUuDQoNCktpbmQgcmVnYXJkcywNCkZ1Z3JvIElu
dGVyc2l0ZSBCLlYuDQoNCk1pY2hlbCBTdGFtDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogYWRyaWFuLmNoYWRkQGdtYWlsLmNvbSBbbWFpbHRvOmFkcmlhbi5jaGFkZEBnbWFpbC5j
b21dIE9uIEJlaGFsZiBPZiBBZHJpYW4gQ2hhZGQNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE1
LCAyMDE2IDA6MjUgQU0NClRvOiBTdGFtLCBNaWNoZWwgW0ZJTlRdDQpDYzogSm9oYW5uZXMgQmVy
ZzsgU2ViYXN0aWFuIEdvdHRzY2hhbGw7IEthbGxlIFZhbG87IEFudG9uaW8gUXVhcnR1bGxpOyBh
dGg5ay1kZXZlbEBsaXN0cy5hdGg5ay5vcmc7IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9y
ZzsgQW50b25pbyBRdWFydHVsbGkNClN1YmplY3Q6IFJlOiBbYXRoOWstZGV2ZWxdIFtOT1QgRk9S
IE1FUkdFXSBhdGg5azogd29yayBhcm91bmQga2V5IGNhY2hlIGNvcnJ1cHRpb24NCg0KSGl5YSwN
Cg0KbWF5YmUgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGlzIHRvIHNldCBhIGZsYWcgdGhhdCBzYXlz
ICJwbGVhc2UNCnJlcGx1bWIiLCB0aGVuIGRvIGEgcmVzZXQsIGFuZCBoYXZlIHRoZSByZXNldCBw
YXRoIHNlZSBpZiB3ZSBuZWVkIHRvDQpyZXBsdW1iIGtleXMgYW5kIGRvIHNvPw0KDQpUbyBtYWtl
IGxvY2tpbmcgbGVzcyB0ZXJyaWJsZSwgbWF5YmUgd2UgbmVlZCB0byBjYWNoZSB0aGUga2V5cyBp
biB0aGUNCmF0aDlrIGRyaXZlciBzb21ld2hlcmUgc28gcmVwbHVtYmluZyBkb2Vzbid0IHJlcXVp
cmUgcmVhY2hpbmcgaW50bw0KbWFjODIwMTEuDQoNCg0KDQotYWRyaWFuDQoNCg==
^ permalink raw reply
* Re: [PATCH 04/10] rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
From: Mathias Kresin @ 2016-11-16 8:10 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa
In-Reply-To: <20161114084238.GA12372@redhat.com>
14.11.2016 09:42, Stanislaw Gruszka:
> On Sat, Nov 05, 2016 at 01:55:14PM +0100, Mathias Kresin wrote:
>> 02.11.2016 15:10, Stanislaw Gruszka:
>>> We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on
>>> rt2800_init_registers().
>>>
>>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>>> ---
>>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1 -
>>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> index feceb13..9ecdc4c 100644
>>> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> @@ -6756,7 +6756,6 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
>>> rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
>>> rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 1);
>>> rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 1);
>>> - rt2x00_set_field32(®, WPDMA_GLO_CFG_WP_DMA_BURST_SIZE, 2);
>>
>> More a notice than a potential issue since I don't have much
>> knowledge about the driver/chip internals.
>>
>> But WPDMA_GLO_CFG_WP_DMA_BURST_SIZE in rt2800_init_registers() is
>> set conditionally for rt2x00_is_usb(rt2x00dev), where this one is
>> set unconditionally. Not sure if this change has side effects.
>
> Default HW setting of WP_DMA_BURTS_SIZE is 2, hence patch does not
> change behaviour on PCI devices. However I looked at RT3290 and
> RT5592 PCI vendor drivers and there this value is initialized to 3.
> So I think we can remove is_usb condition in rt2800_init_registers().
Shouldn't one of the explanations (depending on where you decide to set
WP_DMA_BURTS_SIZE) go into the commit message? As said in my last mail,
without further explanation it looks like introducing a bug.
Mathias
^ permalink raw reply
* Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor
From: Mathias Kresin @ 2016-11-16 8:07 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Felix Fietkau
In-Reply-To: <20161114124323.GA31857@redhat.com>
14.11.2016 13:43, Stanislaw Gruszka:
> On Mon, Nov 14, 2016 at 09:45:36AM +0100, Stanislaw Gruszka wrote:
>> Could you check below patch and see if it helps? If it does not,
>> could you printk sta->ht_cap.ampdu_density and ba_size values
>> and provide them here.
>
> Actually please print parameters from below patch. I think ba_size
> should be based on per TID buf_size instead of ampdu_factor, in case
> STA has buf size different for some TIDs.
>
> Also adding Felix to cc since my orginal patch:
> http://marc.info/?l=linux-wireless&m=147809595316289&w=2
> was shamelessly stolen from mt76 driver. Perhaps Felix could provide
> us some expertise.
>
> Thanks
> Stanislaw
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index 2515702..35bc38c 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -7950,6 +7950,8 @@ int rt2800_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> struct rt2x00_sta *sta_priv = (struct rt2x00_sta *)sta->drv_priv;
> int ret = 0;
>
> + printk("action %d sta %pM tid %u buf_size %u ampdu_factor %u\n", params->action, sta->addr, params->tid, params->buf_size, sta->ht_cap.ampdu_factor);
> +
> /*
> * Don't allow aggregation for stations the hardware isn't aware
> * of because tx status reports for frames to an unknown station
>
Here are the results of the requested tests. Please keep in mind, I'm
not in a lab environment:
LEDE head
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.01 sec 544 MBytes 76.1 Mbits/sec sender
0.00-60.01 sec 544 MBytes 76.1 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bandwidth Retr
0.00-60.00 sec 609 MBytes 85.1 Mbits/sec 96 sender
0.00-60.00 sec 606 MBytes 84.8 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
LEDE + vanilla driver (without LEDE rt2x00 patches)
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.02 sec 522 MBytes 73.0 Mbits/sec sender
0.00-60.02 sec 522 MBytes 73.0 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bandwidth Retr
0.00-60.00 sec 583 MBytes 81.5 Mbits/sec 104 sender
0.00-60.00 sec 581 MBytes 81.2 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
LEDE + vanilla driver + patchset
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.02 sec 377 MBytes 52.7 Mbits/sec sender
0.00-60.02 sec 377 MBytes 52.6 Mbits/sec receive
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
wired (iperf client) to wireless (iperf server)
* not reliable reproducible stalls/reconnects:
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
* one time I've seen this:
ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame
received with unrecognized signal, mode=0x0001,
signal=0x010c, type=4
* sometimes the same rt2x00queue_flush_queue warning on interface
down
Interval Transfer Bandwidth Retr
0.00-60.00 sec 576 MBytes 80.6 Mbits/sec 447 sender
0.00-60.00 sec 574 MBytes 80.2 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
LEDE + vanilla driver + patchset + increased max psdu
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.02 sec 366 MBytes 51.1 Mbits/sec sender
0.00-60.02 sec 365 MBytes 51.1 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bandwidth Retr
0.00-60.00 sec 569 MBytes 79.6 Mbits/sec 471 sender
0.00-60.00 sec 566 MBytes 79.1 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
^ permalink raw reply
* RE: Problems with mwifiex_pcie firmware activation
From: Amitkumar Karwar @ 2016-11-16 6:03 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Nishant Sarmukadam, linux-wireless@vger.kernel.org
In-Reply-To: <20161114101544.GA13943@redhat.com>
Hi Stanislaw,
> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> Sent: Monday, November 14, 2016 3:46 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> Subject: Re: Problems with mwifiex_pcie firmware activation
>
> On Thu, Aug 25, 2016 at 05:06:26PM +0200, Stanislaw Gruszka wrote:
> > On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> > > On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> > > > The problem looks strange. The patch just splits
> mwifiex_check_fw_status() and increases poll count. It should not have
> any side-effects.
> > > > Our code used to check winner status before this patch also.
> > >
> > > Ok, I misread the patch. Anyway checking "winner status" seems does
> > > not work well on some condition and prevent loading firmware into
> > > device.
> >
> > I debug this a bit more on latest wireless-testing-next tree + 3
> > patches I just posted and debug_mask=0x700000ff.
> >
> > On broken system, we do not download FW to device when system is
> > rebooted, due to PCI-E is not the winner. However if system is
> powered
> > OFF and then powered ON, we do FW downloading. Hence download the new
> > FW into device does not make it work as was my theory.
> >
> > In attachments are full dmesgs of good/bad and reboot/power-off-on
> > cases.
> >
> > The difference is that on broken system FW (or HW) do not create new
> > USB Bluetooth device (1286:2046) and do not report
> > FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
> from
> > USB xhci.
>
> It was discovered that not working device require pcie8897_uapsta.bin
> firmware from ubuntu package to work:
What's the difference between working and non-working device?
> https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-
> devices/+sourcepub/5936055/+listing-archive-extra
>
> Device initialize like this then:
>
> [ 15.374630] mwifiex_pcie 0000:02:00.0: info: FW download over, size
> 689624 bytes
> [ 16.101214] mwifiex_pcie 0000:02:00.0: WLAN FW is active
> [ 16.242825] mwifiex_pcie 0000:02:00.0: info: MWIFIEX VERSION:
> mwifiex 1.0 (15.150.13.p21)
> [ 16.251231] mwifiex_pcie 0000:02:00.0: driver_version = mwifiex 1.0
> (15.150.13.p21)
>
> I'm not sure where ubuntu get this 15.150.13.p21 version of firmware as
> it seems it's not present nor in upstream linux-firmware repo not in
> http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
>
> Anyway could you modify firmware to support this device or modify
> driver to load 15.150.13.p21 if required and push this F/W image
> upstream ?
>
Last released firmware is 15.68.7.p77
http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=05e2f3a4acf4174ec507a3464a374ecb1b4ec011
Could you try with it?
If it doesn't work, we need to investigate what is missing in this compared to 15.150.13.p21 and create new 15.68.7.pXX.
Regards,
Amitkumar
^ permalink raw reply
* Re: Bayesian rate control
From: Adrian Chadd @ 2016-11-16 4:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Björn Smedman, linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <1479202467.12007.26.camel@sipsolutions.net>
On 15 November 2016 at 01:34, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> But there is a per-descriptor TX rate table entry in the driver.
>> FreeBSD uses it to implement its rate control for the intel drivers.
>>
>> What am I missing? :)
>
> Not sure. But there isn't a per-descriptor table in the driver. There's
> a per-station table, that *can* be used in similar ways, but at least
> in Linux none of the APIs are hooked up to the general implementation,
> it's all driver/device-specific code, so it'd be very painful to try to
> experiment with.
Ok. well, we do that. :)
I'll let you know how well it works when I'm doing 11ac with the 7260 driver.
-adrian
^ permalink raw reply
* crda not triggering kernel udev event
From: Matthew Stanger @ 2016-11-16 0:11 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm trying to troubleshoot not being able to set the Regulator Domain
on a custom Yocto 3.14 kernel with a Marvell 88W8887/at91_mci driver
on ARM. Running 'udevadm monitor --environment kernel' there are no
kernel udev events being triggered. I've checked the following common
items, crda is installed in '/usr/sbin' (version 3.18), wireless-regdb
is installed at '/usr/lib/crda/regulatory.bin',
'/etc/modeprobe.d/cfg80211.conf' has 'options cfg80211
ieee80211_regdom=US' & I have udev rules pointing to '/usr/sbin/crda'
in both '/etc/udev/rules.d/' & '/lib/udev/rules.d/'. I have
'COUNTRY=US' set and when I run crda I get 'Failed to set regulatory
domain: -7' and with no kernel udev events in the background and no
cfg80211 messages in dmesg. Oddly if I use wpa_supplicant to connect
to an AP and then stop the wpa_sup service then cfg80211 shows up and
kenel udev messages fire and I'm able to set the reg domain via 'iw
reg set'. Any idea's on what may be going on here or what I could
check would be most appreciated.
Thanks,
Matt
^ permalink raw reply
* Re: [RFC 10/12] ath10k: Added QCA65XX hw definition
From: Erik Stromdahl @ 2016-11-15 18:34 UTC (permalink / raw)
To: Valo, Kalle, michal.kazior@tieto.com
Cc: linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <87wpg5qai1.fsf@qca.qualcomm.com>
On 11/15/2016 11:54 AM, Valo, Kalle wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/hw.h | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
>>> index 46142e9..ef45ecf 100644
>>> --- a/drivers/net/wireless/ath/ath10k/hw.h
>>> +++ b/drivers/net/wireless/ath/ath10k/hw.h
>>> @@ -224,6 +224,7 @@ enum ath10k_hw_rev {
>>> ATH10K_HW_QCA9377,
>>> ATH10K_HW_QCA4019,
>>> ATH10K_HW_QCA9887,
>>> + ATH10K_HW_QCA65XX,
>>
>> Are you 100% positive that you're supporting all QCA65XX chips? The
>> rule of thumb is to avoid Xs as much as possible unless totally
>> perfectly completely sure.
>
I admit that I am definitely not totally perfectly completely sure about
this :)
In fact, I don't have a clue what does numbers really mean. All I know
is that the chipset I am using is called QCA6584 which I think is an
automotive version of another chipses called QCA6574. I have tried to
google these numbers up, but it is really hard to find anything useful.
So I thought, hey, why don't I just add a few X'es in there and I have
support for both!
> But the thing is that nobody can't be absolutely sure as we never know
> what marketing comes up within few years again. So I would say that XX
> in chip names should be completely avoided to avoid any confusion. We
> already suffer from this in ath10k with QCA988X and QCA9888 which are
> different designs but the names overlap.
>
> I haven't reviewed Erik's patches yet but I'm surprised why even a new
> enum value is needed here. I was assuming we could use ATH10K_HW_QCA6174
> because AFAIK they share the same design. Any particular reason for
> this?
>
The reason for this was that the switch(hw_rev)-statement in
ath10k_core_create assigns ar->regs and ar->hw_values to structures
containing values that are not applicable for SDIO. I though that I
would potentially need other structures, but after investigating the
qca6174_regs struct, it seems that the values that are applicable for
SDIO are the same.
I will remove this enum and use ATH10K_HW_QCA6174 instead as you
propose. If for some reason I would need other regs and hw_values
structs in the future, we can figure out appropriate names then.
^ permalink raw reply
* Re: [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie
From: Brian Norris @ 2016-11-15 18:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Amitkumar Karwar, linux-wireless, Cathy Luo, Nishant Sarmukadam,
rajatja
In-Reply-To: <20161115173507.GB22897@dtor-ws>
On Tue, Nov 15, 2016 at 09:35:07AM -0800, Dmitry Torokhov wrote:
> On Tue, Nov 15, 2016 at 07:06:04PM +0530, Amitkumar Karwar wrote:
> > --- a/drivers/net/wireless/marvell/mwifiex/main.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> > @@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
> > }
> > EXPORT_SYMBOL_GPL(mwifiex_do_flr);
> >
> > +static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
> > +{
> > + struct mwifiex_adapter *adapter = priv;
> > +
> > + if (adapter->irq_wakeup >= 0) {
> > + dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
> > + adapter->wake_by_wifi = true;
> > + disable_irq_nosync(irq);
> > + }
> > +
> > + /* Notify PM core we are wakeup source */
> > + pm_wakeup_event(adapter->dev, 0);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> > {
> > + int ret;
> > struct device *dev = adapter->dev;
> >
> > if (!dev->of_node)
> > return;
> >
> > adapter->dt_node = dev->of_node;
> > + adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
> > + if (!adapter->irq_wakeup) {
> > + dev_info(dev, "fail to parse irq_wakeup from device tree\n");
> > + return;
> > + }
>
> I'd rather we used of_irq_get() here, because ti allows handling
> deferrals. of_irq_get_byname() would be even better, but I guess we
> already have bindings in the wild...
This function doesn't handle errors very gracefully at all; we just try,
and if we fail, we just skip the rest...
This could be an argument for rewriting the error handling to stop just
returning -1 in mwifiex_add_card() and use real Linux error codes.
Perhaps that can be a later cleanup?
> > +
> > + ret = devm_request_irq(dev, adapter->irq_wakeup,
> > + mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
>
> irq_of_parse_and_map() (and of_irq_get()) will set trigger flags,
> why do we override them?
>
> > + "wifi_wake", adapter);
> > + if (ret) {
> > + dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
> > + adapter->irq_wakeup, ret);
> > + goto err_exit;
> > + }
> > +
> > + disable_irq(adapter->irq_wakeup);
> > + if (device_init_wakeup(dev, true)) {
> > + dev_err(dev, "fail to init wakeup for mwifiex\n");
> > + goto err_exit;
>
> Leaking interrupt (not forever, but if we are not using wakeup irq there
> is no need to have it claimed).
>
> > + }
> > + return;
> > +
> > +err_exit:
> > + adapter->irq_wakeup = 0;
> > }
>
> I also do not see anyone actually calling mwifiex_probe_of() in this
> patch?
It was added to mwifiex_add_card() in the previous patch, so all users
with a proper ->dt_node would call it.
> >
> > /*
Brian
^ permalink raw reply
* RE: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: voncken @ 2016-11-15 14:37 UTC (permalink / raw)
To: 'Ben Greear'
Cc: linux-wireless, 'OpenWrt Development List', ath10k
In-Reply-To: <581DEE2E.3010502@candelatech.com>
Hi Ben,
Do you plan to release a candelatech firmware with this fix?
Regards.
Cedric Voncken.
> -----Message d'origine-----
> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] De la part de Ben Greear
> Envoyé : samedi 5 novembre 2016 15:35
> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
> Development List; ath10k@lists.infradead.org
> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>
> Looks to me like 10.4 defaults to the right value, but possibly there
> are other issues with it. I tested my CT 10.4 and it worked OK with
> vlans for me.
>
> Thanks,
> Ben
>
> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
> > would be good if qca can fix this bug finally in all available
> > firmwares. its a very annoying issue since a long time
> >
> > Sebastian
> >
> >
> > Am 04.11.2016 um 23:23 schrieb Ben Greear:
> >> The bug appears that vlan-tx-stripping is unconditionally enabled in
> >> at least my firmware. I have re-compiled w/out that flag set, and
> it
> >> appears to work for me.
> >>
> >> Please download this firmware, rename it firmware-2.bin, make sure
> >> you remove/rename any firmware-5.bin (etc) so mine will load, and
> see if that fixes your problem.
> >>
> >> Please note that it is very likely you will have to use same MAC
> >> address for the VLAN devices that the underlying station uses in
> order for this to work.
> >>
> >> https://www.candelatech.com/downloads/tmp/firmware-2-full-
> community.b
> >> in
> >>
> >>
> >> Thanks,
> >> Ben
> >>
> >>
> >> On 11/04/2016 02:50 PM, Ben Greear wrote:
> >>> I can reproduce this in my CT firmware. I'll see if I can fix it,
> >>> but for stock firmware, it might be that changing the driver to use
> >>> Ethernet packet type of native-wifi would make .1q vlans work.
> >>>
> >>> Thanks,
> >>> Ben
> >>>
> >>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
> >>>> I met the same problem before,
> >>>> if i modify the 1q header to other value (0xaa00) before go into
> firmware.
> >>>> I can capture the packet in the air I think the vlan packet is
> >>>> dropped in firmware.
> >>>>
> >>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
> >>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
> <openwrt@ezplanet.net> wrote:
> >>>>>> Since the capability is implemented in software you might be
> >>>>>> testing the limit of your router's CPU i/o speed.
> >>>>>
> >>>>> By loading the module in rawmode?
> >>>>>
> >>>>> The AP is an APU and Sta is an APU2.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
> >>>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> Old thread but I think the issue is still present.
> >>>>>>>
> >>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
> >>>>>>>
> >>>>>>> To make it work both cards must be loaded in rawmode, AP and
> >>>>>>> Sta, and with no security.
> >>>>>>>
> >>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
> >>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
> >>>>>>>
> >>>>>>> Although it works the throughput is very bad.
> >>>>>>> Are there any alternatives to improve the throughput.
> >>>>>>>
> >>>>>>> Best Regards,
> >>>>>>> Bruno
> >>>>>>>
> >>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Message d'origine-----
> >>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoyé :
> >>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
> >>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
> >>>>>>>>> VLAN firmware issue
> >>>>>>>>>
> >>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
> >>>>>>>>> for you in other cases as well?
> >>>>>>>>
> >>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> Cedric.
> >>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Ben
> >>>>>>>>>
> >>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
> >>>>>>>>>>
> >>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
> >>>>>>>>>>
> >>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
> with eth0.
> >>>>>>>>>> I have a computer with vlan configuration set connected
> >>>>>>>>>> to the STA eth0.
> >>>>>>>>>>
> >>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
> >>>>>>>>>> are not
> >>>>>>>>
> >>>>>>>> sent.
> >>>>>>>>>>
> >>>>>>>>>> I checked with wireless sniffer, and I don't see the
> >>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
> >>>>>>>>>>
> >>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
> >>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
> >>>>>>>>>> from openwrt, and in all cases I have the same issue.
> >>>>>>>>>>
> >>>>>>>>>> Thanks for your help.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
> >>>>>>>>>> linux-wireless" in the body of a message to
> >>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
> >>>>>>>>>> http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
> >>>>>>>>> http://www.candelatech.com
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless"
> >>>>>>>> in
> >>>>>>>> the body of a message to majordomo@vger.kernel.org More
> >>>>>>>> majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> openwrt-devel mailing list
> >>>>>>> openwrt-devel@lists.openwrt.org
> >>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
> devel
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> openwrt-devel mailing list
> >>>>>> openwrt-devel@lists.openwrt.org
> >>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>>>>
> >>>>> _______________________________________________
> >>>>> ath10k mailing list
> >>>>> ath10k@lists.infradead.org
> >>>>> http://lists.infradead.org/mailman/listinfo/ath10k
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
From: Matthias Schiffer @ 2016-11-15 17:47 UTC (permalink / raw)
To: kvalo; +Cc: ath9k-devel, linux-wireless, ath9k-devel, miaoqing
Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set().
Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.
Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
Cc: <stable@vger.kernel.org> # v4.7+
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 14b13f0..a35f78b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2792,7 +2792,7 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah, u32 gpio)
WARN_ON(1);
}
- return val;
+ return !!val;
}
EXPORT_SYMBOL(ath9k_hw_gpio_get);
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie
From: Dmitry Torokhov @ 2016-11-15 17:35 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris
In-Reply-To: <1479216964-3328-3-git-send-email-akarwar@marvell.com>
On Tue, Nov 15, 2016 at 07:06:04PM +0530, Amitkumar Karwar wrote:
> From: Rajat Jain <rajatja@google.com>
>
> Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
> support") added WoWLAN feature only for sdio. This patch moves that
> code to the common module so that all the interface drivers can use
> it for free. It enables pcie and sdio for its use currently.
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> ---
> v2: v1 doesn't apply smoothly on latest code due to recently merged
> patch "mwifiex: report error to PCIe for suspend failure". Minor
> conflict is resolved in v2
> v4: Same as v2, v3
> ---
> drivers/net/wireless/marvell/mwifiex/main.c | 41 ++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/main.h | 25 ++++++++++
> drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +
> drivers/net/wireless/marvell/mwifiex/sdio.c | 72 ++---------------------------
> drivers/net/wireless/marvell/mwifiex/sdio.h | 8 ----
> 5 files changed, 73 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> index 835d330..948f5c2 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
> }
> EXPORT_SYMBOL_GPL(mwifiex_do_flr);
>
> +static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
> +{
> + struct mwifiex_adapter *adapter = priv;
> +
> + if (adapter->irq_wakeup >= 0) {
> + dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
> + adapter->wake_by_wifi = true;
> + disable_irq_nosync(irq);
> + }
> +
> + /* Notify PM core we are wakeup source */
> + pm_wakeup_event(adapter->dev, 0);
> +
> + return IRQ_HANDLED;
> +}
> +
> static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> {
> + int ret;
> struct device *dev = adapter->dev;
>
> if (!dev->of_node)
> return;
>
> adapter->dt_node = dev->of_node;
> + adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
> + if (!adapter->irq_wakeup) {
> + dev_info(dev, "fail to parse irq_wakeup from device tree\n");
> + return;
> + }
I'd rather we used of_irq_get() here, because ti allows handling
deferrals. of_irq_get_byname() would be even better, but I guess we
already have bindings in the wild...
> +
> + ret = devm_request_irq(dev, adapter->irq_wakeup,
> + mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
irq_of_parse_and_map() (and of_irq_get()) will set trigger flags,
why do we override them?
> + "wifi_wake", adapter);
> + if (ret) {
> + dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
> + adapter->irq_wakeup, ret);
> + goto err_exit;
> + }
> +
> + disable_irq(adapter->irq_wakeup);
> + if (device_init_wakeup(dev, true)) {
> + dev_err(dev, "fail to init wakeup for mwifiex\n");
> + goto err_exit;
Leaking interrupt (not forever, but if we are not using wakeup irq there
is no need to have it claimed).
> + }
> + return;
> +
> +err_exit:
> + adapter->irq_wakeup = 0;
> }
I also do not see anyone actually calling mwifiex_probe_of() in this
patch?
>
> /*
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
> index 549e1ba..ae5afe5 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -1011,6 +1011,10 @@ struct mwifiex_adapter {
> bool usb_mc_setup;
> struct cfg80211_wowlan_nd_info *nd_info;
> struct ieee80211_regdomain *regd;
> +
> + /* Wake-on-WLAN (WoWLAN) */
> + int irq_wakeup;
> + bool wake_by_wifi;
> };
>
> void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
> @@ -1410,6 +1414,27 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
> return false;
> }
>
> +/* Disable platform specific wakeup interrupt */
> +static inline void mwifiex_disable_wake(struct mwifiex_adapter *adapter)
> +{
> + if (adapter->irq_wakeup >= 0) {
> + disable_irq_wake(adapter->irq_wakeup);
> + if (!adapter->wake_by_wifi)
> + disable_irq(adapter->irq_wakeup);
> + }
> +}
> +
> +/* Enable platform specific wakeup interrupt */
> +static inline void mwifiex_enable_wake(struct mwifiex_adapter *adapter)
> +{
> + /* Enable platform specific wakeup interrupt */
> + if (adapter->irq_wakeup >= 0) {
> + adapter->wake_by_wifi = false;
> + enable_irq(adapter->irq_wakeup);
> + enable_irq_wake(adapter->irq_wakeup);
> + }
> +}
> +
> int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
> u32 func_init_shutdown);
> int mwifiex_add_card(void *card, struct semaphore *sem,
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 745ecd6..e8f4f90 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -131,6 +131,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
> }
>
> adapter = card->adapter;
> + mwifiex_enable_wake(adapter);
>
> /* Enable the Host Sleep */
> if (!mwifiex_enable_hs(adapter)) {
> @@ -186,6 +187,7 @@ static int mwifiex_pcie_resume(struct device *dev)
>
> mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
> MWIFIEX_ASYNC_CMD);
> + mwifiex_disable_wake(adapter);
>
> return 0;
> }
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index c95f41f..7055282 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -79,67 +79,18 @@
> { }
> };
>
> -static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
> -{
> - struct mwifiex_plt_wake_cfg *cfg = priv;
> -
> - if (cfg->irq_wifi >= 0) {
> - pr_info("%s: wake by wifi", __func__);
> - cfg->wake_by_wifi = true;
> - disable_irq_nosync(irq);
> - }
> -
> - /* Notify PM core we are wakeup source */
> - pm_wakeup_event(cfg->dev, 0);
> -
> - return IRQ_HANDLED;
> -}
> -
> /* This function parse device tree node using mmc subnode devicetree API.
> * The device node is saved in card->plt_of_node.
> * if the device tree node exist and include interrupts attributes, this
> * function will also request platform specific wakeup interrupt.
> */
> -static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
> +static int mwifiex_sdio_probe_of(struct device *dev)
> {
> - struct mwifiex_plt_wake_cfg *cfg;
> - int ret;
> -
> if (!of_match_node(mwifiex_sdio_of_match_table, dev->of_node)) {
> dev_err(dev, "required compatible string missing\n");
> return -EINVAL;
> }
>
> - card->plt_of_node = dev->of_node;
> - card->plt_wake_cfg = devm_kzalloc(dev, sizeof(*card->plt_wake_cfg),
> - GFP_KERNEL);
> - cfg = card->plt_wake_cfg;
> - if (cfg && card->plt_of_node) {
> - cfg->dev = dev;
> - cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
> - if (!cfg->irq_wifi) {
> - dev_dbg(dev,
> - "fail to parse irq_wifi from device tree\n");
> - } else {
> - ret = devm_request_irq(dev, cfg->irq_wifi,
> - mwifiex_wake_irq_wifi,
> - IRQF_TRIGGER_LOW,
> - "wifi_wake", cfg);
> - if (ret) {
> - dev_dbg(dev,
> - "Failed to request irq_wifi %d (%d)\n",
> - cfg->irq_wifi, ret);
> - card->plt_wake_cfg = NULL;
> - return 0;
> - }
> - disable_irq(cfg->irq_wifi);
> - }
> - }
> -
> - ret = device_init_wakeup(dev, true);
> - if (ret)
> - dev_err(dev, "fail to init wakeup for mwifiex");
> -
> return 0;
> }
>
> @@ -198,11 +149,9 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
>
> /* device tree node parsing and platform specific configuration*/
> if (func->dev.of_node) {
> - ret = mwifiex_sdio_probe_of(&func->dev, card);
> - if (ret) {
> - dev_err(&func->dev, "SDIO dt node parse failed\n");
> + ret = mwifiex_sdio_probe_of(&func->dev);
> + if (ret)
> goto err_disable;
> - }
> }
>
> ret = mwifiex_add_card(card, &add_remove_card_sem, &sdio_ops,
> @@ -267,12 +216,7 @@ static int mwifiex_sdio_resume(struct device *dev)
> mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
> MWIFIEX_SYNC_CMD);
>
> - /* Disable platform specific wakeup interrupt */
> - if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
> - disable_irq_wake(card->plt_wake_cfg->irq_wifi);
> - if (!card->plt_wake_cfg->wake_by_wifi)
> - disable_irq(card->plt_wake_cfg->irq_wifi);
> - }
> + mwifiex_disable_wake(adapter);
>
> return 0;
> }
> @@ -352,13 +296,7 @@ static int mwifiex_sdio_suspend(struct device *dev)
> }
>
> adapter = card->adapter;
> -
> - /* Enable platform specific wakeup interrupt */
> - if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
> - card->plt_wake_cfg->wake_by_wifi = false;
> - enable_irq(card->plt_wake_cfg->irq_wifi);
> - enable_irq_wake(card->plt_wake_cfg->irq_wifi);
> - }
> + mwifiex_enable_wake(adapter);
>
> /* Enable the Host Sleep */
> if (!mwifiex_enable_hs(adapter)) {
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index 07cdd23..b9fbc5c 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -154,12 +154,6 @@
> a->mpa_rx.start_port = 0; \
> } while (0)
>
> -struct mwifiex_plt_wake_cfg {
> - struct device *dev;
> - int irq_wifi;
> - bool wake_by_wifi;
> -};
> -
> /* data structure for SDIO MPA TX */
> struct mwifiex_sdio_mpa_tx {
> /* multiport tx aggregation buffer pointer */
> @@ -243,8 +237,6 @@ struct mwifiex_sdio_card_reg {
> struct sdio_mmc_card {
> struct sdio_func *func;
> struct mwifiex_adapter *adapter;
> - struct device_node *plt_of_node;
> - struct mwifiex_plt_wake_cfg *plt_wake_cfg;
>
> const char *firmware;
> const struct mwifiex_sdio_card_reg *reg;
> --
> 1.9.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC 02/12] ath10k: htc: rx trailer lookahead support
From: Erik Stromdahl @ 2016-11-15 17:31 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQkJqv28=Mg1ncmyznRo-CLh6Y_OW-mJ+YTyqaREaqp39Q@mail.gmail.com>
On 11/15/2016 10:57 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>> The RX trailer parsing is now capable of parsing lookahead reports.
>> This is needed by SDIO/mbox.
>
> It'd be useful to know what exactly lookahead will be used for. What
> payload does it carry.
>
It carries the 4 first bytes of the next RX message, i.e. the first 4
bytes of an HTC header.
It is used by the sdio interrupt handler to know if the next packet is a
part of an RX bundle, which endpoint it belongs to and how long it is
(so we know how many bytes to allocate).
>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath10k/htc.c | 91 ++++++++++++++++++++++++++++++++-
>> drivers/net/wireless/ath/ath10k/htc.h | 30 +++++++++--
>> 2 files changed, 116 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
>> index 26b1e15..e3f7bf4 100644
>> --- a/drivers/net/wireless/ath/ath10k/htc.c
>> +++ b/drivers/net/wireless/ath/ath10k/htc.c
>> @@ -228,10 +228,74 @@ void ath10k_htc_tx_completion_handler(struct ath10k *ar, struct sk_buff *skb)
>> spin_unlock_bh(&htc->tx_lock);
>> }
>>
>> +static int
>> +ath10k_htc_process_lookahead(struct ath10k_htc *htc,
>> + const struct ath10k_htc_lookahead_report *report,
>> + int len,
>> + enum ath10k_htc_ep_id eid,
>> + u32 *next_lk_ahds,
>
> next_lk_ahds should be u8 or void. From what I understand by glancing
> through the code it is an agnostic buffer that carries payload which
> is later interpreted either as eid or htc header, right? void is
> probably most suitable in this case for passing around and u8 for
> inline-based storage.
>
Sounds reasonable, I'll change to void pointer.
> I'd also avoid silly abbreviations. Probably "lookahead" alone is enough.
>
Ok, this abbreviation was actually taken from the ath6kl code. I think
the intention was to reduce line lengths.
>> + int *next_lk_ahds_len)
>> +{
>> + struct ath10k *ar = htc->ar;
>> +
>> + if (report->pre_valid != ((~report->post_valid) & 0xFF))
>> + /* Invalid lookahead flags are actually transmitted by
>> + * the target in the HTC control message.
>> + * Since this will happen at every boot we silently ignore
>> + * the lookahead in this case
>> + */
>
> I'd put this comment before the if().
Ok
>
>
>> + return 0;
>> +
>> + if (next_lk_ahds && next_lk_ahds_len) {
>> + ath10k_dbg(ar, ATH10K_DBG_HTC,
>> + "htc rx lk_ahd found pre_valid 0x%x post_valid 0x%x\n",
>> + report->pre_valid, report->post_valid);
>> +
>> + /* look ahead bytes are valid, copy them over */
>> + memcpy((u8 *)&next_lk_ahds[0], report->lk_ahd, 4);
>> +
>> + *next_lk_ahds_len = 1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int
>> +ath10k_htc_process_lookahead_bundle(struct ath10k_htc *htc,
>> + const struct ath10k_htc_lookahead_report_bundle *report,
>> + int len,
>> + enum ath10k_htc_ep_id eid,
>> + u32 *next_lk_ahds,
>
> Ditto. void.
>
>
>> + int *next_lk_ahds_len)
>> +{
>> + int bundle_cnt = len / sizeof(*report);
>> +
>> + if (!bundle_cnt || (bundle_cnt > HTC_HOST_MAX_MSG_PER_BUNDLE)) {
>> + WARN_ON(1);
>
> This should be ath10k_warn() instead. This isn't internal driver flow
> assertion. It is possible firmware bug or revision misalignment
> instead.
>
Ok
>
>> + return -EINVAL;
>> + }
>> +
>> + if (next_lk_ahds && next_lk_ahds_len) {
>> + int i;
>> +
>> + for (i = 0; i < bundle_cnt; i++) {
>> + memcpy((u8 *)&next_lk_ahds[i], report->lk_ahd,
>> + sizeof(u32));
>
> You'll need to re-adjust the &x[i] to maintain proper offset with void pointer.
>
>
> Michał
>
^ permalink raw reply
* Re: [RFC 06/12] ath10k: bmi: Added SOC reg read/write functions
From: Erik Stromdahl @ 2016-11-15 17:11 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQ=jSun0Je6sVsZz-SaiDA6+nZxSTJF_5OH0unPkjm1gvw@mail.gmail.com>
On 11/15/2016 11:28 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>> Added functions implementing the following BMI commands:
>>
>> BMI_READ_SOC_REGISTER
>> BMI_WRITE_SOC_REGISTER
>>
>> Reading and writing BMI registers is sometimes needed for
>> SDIO chipsets.
>
> I didn't see ath10k_bmi_write_soc_reg nor ath10k_bmi_read_soc_reg
> being used in your Patch 12. Is this patch really necessary?
>
>
You are right, these functions are not used in patch 12. They are used
in some other patches that was not included in this series (needs more
cleanup before I can publish). I will remove them from the series.
> [...]
>> diff --git a/drivers/net/wireless/ath/ath10k/bmi.c b/drivers/net/wireless/ath/ath10k/bmi.c
>> index 2872d34..1c378a2 100644
>> --- a/drivers/net/wireless/ath/ath10k/bmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/bmi.c
>> @@ -97,7 +97,8 @@ int ath10k_bmi_read_memory(struct ath10k *ar,
>> u32 rxlen;
>> int ret;
>>
>> - ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi read address 0x%x length %d\n",
>> + ath10k_dbg(ar, ATH10K_DBG_BMI,
>> + "bmi read memory address 0x%x length %d\n",
>> address, length);
>>
>> if (ar->bmi.done_sent) {
>> @@ -137,7 +138,8 @@ int ath10k_bmi_write_memory(struct ath10k *ar,
>> u32 txlen;
>> int ret;
>>
>> - ath10k_dbg(ar, ATH10K_DBG_BMI, "bmi write address 0x%x length %d\n",
>> + ath10k_dbg(ar, ATH10K_DBG_BMI,
>> + "bmi write memory address 0x%x length %d\n",
>> address, length);
>>
>
> These 2 hunks shouldn't be modified in this patch. If you want to do a
> clean up this warrants a separate patch :)
>
>
> Michał
>
Ok
/Erik
^ permalink raw reply
* Re: [RFC 03/12] ath10k: htc: Changed order of wait target and ep connect
From: Erik Stromdahl @ 2016-11-15 17:07 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQmA0E+N46E3XkpqVPXSVkQNyZj2Qzrizk8iLdYzVthNQg@mail.gmail.com>
On 11/15/2016 11:13 AM, Michal Kazior wrote:
> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>> This patch changes the order in which the driver waits for the
>> target to become ready and the service connect of the HTC
>> control service.
>>
>> The HTC control service is connected before the driver starts
>> waiting for the HTC ready control message.
>>
>> The reason for this is that the HTC ready control message is
>> transmitted on EP 0 and that sdio/mbox based systems will ignore
>> messages received on unconnected endpoints.
>>
>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath10k/htc.c | 32 ++++++++++++++++----------------
>> 1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
>> index e3f7bf4..7257366 100644
>> --- a/drivers/net/wireless/ath/ath10k/htc.c
>> +++ b/drivers/net/wireless/ath/ath10k/htc.c
>> @@ -606,6 +606,22 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
>> u16 credit_count;
>> u16 credit_size;
>>
>> + /* setup our pseudo HTC control endpoint connection */
>> + memset(&conn_req, 0, sizeof(conn_req));
>> + memset(&conn_resp, 0, sizeof(conn_resp));
>> + conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
>> + conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
>> + conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
>> + conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;
>> +
>> + /* connect fake service */
>> + status = ath10k_htc_connect_service(htc, &conn_req, &conn_resp);
>> + if (status) {
>> + ath10k_err(ar, "could not connect to htc service (%d)\n",
>> + status);
>> + return status;
>> + }
>> +
>
> How is this supposed to work? ath10k_htc_connect_service() requires
> htc->target_credit_size to compute tx_credits_per_max_message. Or am I
> missing something? Applying this patch alone results in:
>
> [ 6.680101] divide error: 0000 [#1] SMP
> [ 6.681342] Modules linked in: ath10k_pci(O) ath10k_core(O) ath
> mac80211 cfg80211
> [ 6.684876] CPU: 3 PID: 823 Comm: kworker/u8:2 Tainted: G W
> O 4.9.0-rc4-wt-ath+ #79
> [ 6.688051] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [ 6.691644] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
> [ 6.694309] task: ffff88000a190000 task.stack: ffffc900006d4000
> [ 6.695458] RIP: 0010:[<ffffffffa01ae46b>] [<ffffffffa01ae46b>]
> ath10k_htc_connect_service+0x21b/0x420 [ath10k_core]
>
>
> Michał
>
You're right. I have totally missed this. What is strange is that my
compiler (ARM linaro) seems to optimize the code in a way that removes
the tx_credits_per_max_message value.
If I add a printk in ath10k_htc_connect_service (printing the value) I
get a similar oops.
I think it has to do with the fact the this value isn't really used at
all. grepping the code reveals that tx_credits_per_max_message is only
used inside ath10k_htc_connect_service (only written, never read).
Removing it doesn't seem to break anything, so perhaps it should be removed?
Or is there something I have missed?
/Erik
^ permalink raw reply
* [PATCHv3 2/2] ath10k: add support for per sta tx bitrate
From: akolli @ 2016-11-15 16:38 UTC (permalink / raw)
To: ath10k; +Cc: akolli, linux-wireless, Anilkumar Kolli
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per STA tx bitrate info is filled from peer stats.
Export per sta txrate info to cfg80211/nl80211
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* address Kalle's comments
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 9955fea0802a..fce6f8137d33 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -77,6 +77,19 @@ void ath10k_sta_statistics(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sinfo->rx_duration = arsta->rx_duration;
sinfo->filled |= 1ULL << NL80211_STA_INFO_RX_DURATION;
+
+ if (!arsta->txrate.legacy && !arsta->txrate.nss)
+ return;
+
+ if (arsta->txrate.legacy) {
+ sinfo->txrate.legacy = arsta->txrate.legacy;
+ } else {
+ sinfo->txrate.mcs = arsta->txrate.mcs;
+ sinfo->txrate.nss = arsta->txrate.nss;
+ sinfo->txrate.bw = arsta->txrate.bw;
+ }
+ sinfo->txrate.flags = arsta->txrate.flags;
+ sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
}
static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4
From: akolli @ 2016-11-15 16:37 UTC (permalink / raw)
To: ath10k; +Cc: akolli, linux-wireless, Anilkumar Kolli
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.
Parse peer stats and update the tx rate information per STA.
tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* address Kalle's comments
* fix compilation warnings
v3:
* fix compilation warnings (kvalo)
drivers/net/wireless/ath/ath10k/core.h | 17 ++++
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h | 25 ++++++
drivers/net/wireless/ath/ath10k/htt_rx.c | 125 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 10 ++-
5 files changed, 178 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index e8decfaba5b6..2f324a115b18 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -337,6 +337,7 @@ struct ath10k_sta {
u32 nss;
u32 smps;
u16 peer_id;
+ struct rate_info txrate;
struct work_struct update_wk;
@@ -693,6 +694,21 @@ struct ath10k_fw_components {
struct ath10k_fw_file fw_file;
};
+struct ath10k_per_peer_tx_stats {
+ u32 succ_bytes;
+ u32 retry_bytes;
+ u32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ u16 peer_id;
+ u16 succ_pkts;
+ u16 retry_pkts;
+ u16 failed_pkts;
+ u16 duration;
+ u32 reserved1;
+ u32 reserved2;
+};
+
struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
@@ -906,6 +922,7 @@ struct ath10k {
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+ struct ath10k_per_peer_tx_stats peer_tx_stats;
/* NAPI */
struct net_device napi_dev;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c b/drivers/net/wireless/ath/ath10k/htt.c
index 130cd9502021..cd160b16db1e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -137,6 +137,8 @@
HTT_T2H_MSG_TYPE_STATS_NOUPLOAD,
[HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND] =
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ [HTT_10_4_T2H_MSG_TYPE_PEER_STATS] =
+ HTT_T2H_MSG_TYPE_PEER_STATS,
};
int ath10k_htt_connect(struct ath10k_htt *htt)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09f202b..164eb3a10566 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -419,6 +419,7 @@ enum htt_10_4_t2h_msg_type {
HTT_10_4_T2H_MSG_TYPE_STATS_NOUPLOAD = 0x18,
/* 0x19 to 0x2f are reserved */
HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND = 0x30,
+ HTT_10_4_T2H_MSG_TYPE_PEER_STATS = 0x31,
/* keep this last */
HTT_10_4_T2H_NUM_MSGS
};
@@ -453,6 +454,7 @@ enum htt_t2h_msg_type {
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM,
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+ HTT_T2H_MSG_TYPE_PEER_STATS,
/* keep this last */
HTT_T2H_NUM_MSGS
};
@@ -1470,6 +1472,28 @@ struct htt_channel_change {
__le32 phymode;
} __packed;
+struct htt_per_peer_tx_stats_ind {
+ __le32 succ_bytes;
+ __le32 retry_bytes;
+ __le32 failed_bytes;
+ u8 ratecode;
+ u8 flags;
+ __le16 peer_id;
+ __le16 succ_pkts;
+ __le16 retry_pkts;
+ __le16 failed_pkts;
+ __le16 tx_duration;
+ __le32 reserved1;
+ __le32 reserved2;
+} __packed;
+
+struct htt_peer_tx_stats {
+ u8 num_ppdu;
+ u8 ppdu_len;
+ u8 version;
+ u8 payload[0];
+} __packed;
+
union htt_rx_pn_t {
/* WEP: 24-bit PN */
u32 pn24;
@@ -1521,6 +1545,7 @@ struct htt_resp {
struct htt_tx_fetch_confirm tx_fetch_confirm;
struct htt_tx_mode_switch_ind tx_mode_switch_ind;
struct htt_channel_change chan_change;
+ struct htt_peer_tx_stats peer_tx_stats;
};
} __packed;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 285b235268d7..86d082cf4eef 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2194,6 +2194,128 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
dev_kfree_skb_any(skb);
}
+static inline bool is_valid_legacy_rate(u8 rate)
+{
+ static const u8 legacy_rates[] = {1, 2, 5, 11, 6, 9, 12,
+ 18, 24, 36, 48, 54};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(legacy_rates); i++) {
+ if (rate == legacy_rates[i])
+ return true;
+ }
+
+ return false;
+}
+
+static void
+ath10k_update_per_peer_tx_stats(struct ath10k *ar,
+ struct ieee80211_sta *sta,
+ struct ath10k_per_peer_tx_stats *peer_stats)
+{
+ struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ u8 rate = 0, sgi;
+ struct rate_info txrate;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ txrate.flags = ATH10K_HW_PREAMBLE(peer_stats->ratecode);
+ txrate.bw = ATH10K_HW_BW(peer_stats->flags);
+ txrate.nss = ATH10K_HW_NSS(peer_stats->ratecode);
+ txrate.mcs = ATH10K_HW_MCS_RATE(peer_stats->ratecode);
+ sgi = ATH10K_HW_GI(peer_stats->flags);
+
+ if (((txrate.flags == WMI_RATE_PREAMBLE_HT) ||
+ (txrate.flags == WMI_RATE_PREAMBLE_VHT)) && txrate.mcs > 9) {
+ ath10k_warn(ar, "Invalid mcs %hhd peer stats", txrate.mcs);
+ return;
+ }
+
+ if (txrate.flags == WMI_RATE_PREAMBLE_CCK ||
+ txrate.flags == WMI_RATE_PREAMBLE_OFDM) {
+ rate = ATH10K_HW_LEGACY_RATE(peer_stats->ratecode);
+
+ if (!is_valid_legacy_rate(rate)) {
+ ath10k_warn(ar, "Invalid legacy rate %hhd peer stats",
+ rate);
+ return;
+ }
+
+ /* This is hacky, FW sends CCK rate 5.5Mbps as 6 */
+ rate *= 10;
+ if (rate == 60 && txrate.flags == WMI_RATE_PREAMBLE_CCK)
+ rate = rate - 5;
+ arsta->txrate.legacy = rate * 10;
+ } else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
+ arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ } else {
+ arsta->txrate.flags = RATE_INFO_FLAGS_VHT_MCS;
+ arsta->txrate.mcs = txrate.mcs;
+ }
+
+ if (sgi)
+ arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
+
+ arsta->txrate.nss = txrate.nss;
+ arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+}
+
+static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
+ struct sk_buff *skb)
+{
+ struct htt_resp *resp = (struct htt_resp *)skb->data;
+ struct ath10k_per_peer_tx_stats *p_tx_stats = &ar->peer_tx_stats;
+ struct htt_per_peer_tx_stats_ind *tx_stats;
+ struct ieee80211_sta *sta;
+ struct ath10k_peer *peer;
+ int peer_id, i;
+ u8 ppdu_len, num_ppdu;
+
+ num_ppdu = resp->peer_tx_stats.num_ppdu;
+ ppdu_len = resp->peer_tx_stats.ppdu_len * sizeof(__le32);
+
+ if (skb->len < sizeof(struct htt_resp_hdr) + num_ppdu * ppdu_len) {
+ ath10k_warn(ar, "Invalid peer stats buf length %d\n", skb->len);
+ return;
+ }
+
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload);
+ peer_id = __le16_to_cpu(tx_stats->peer_id);
+
+ rcu_read_lock();
+ spin_lock_bh(&ar->data_lock);
+ peer = ath10k_peer_find_by_id(ar, peer_id);
+ if (!peer) {
+ ath10k_warn(ar, "Invalid peer id %d peer stats buffer\n",
+ peer_id);
+ goto out;
+ }
+
+ sta = peer->sta;
+ for (i = 0; i < num_ppdu; i++) {
+ tx_stats = (struct htt_per_peer_tx_stats_ind *)
+ (resp->peer_tx_stats.payload + i * ppdu_len);
+
+ p_tx_stats->succ_bytes = __le32_to_cpu(tx_stats->succ_bytes);
+ p_tx_stats->retry_bytes = __le32_to_cpu(tx_stats->retry_bytes);
+ p_tx_stats->failed_bytes =
+ __le32_to_cpu(tx_stats->failed_bytes);
+ p_tx_stats->ratecode = tx_stats->ratecode;
+ p_tx_stats->flags = tx_stats->flags;
+ p_tx_stats->succ_pkts = __le16_to_cpu(tx_stats->succ_pkts);
+ p_tx_stats->retry_pkts = __le16_to_cpu(tx_stats->retry_pkts);
+ p_tx_stats->failed_pkts = __le16_to_cpu(tx_stats->failed_pkts);
+
+ ath10k_update_per_peer_tx_stats(ar, sta, p_tx_stats);
+ }
+
+out:
+ spin_unlock_bh(&ar->data_lock);
+ rcu_read_unlock();
+}
+
bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
{
struct ath10k_htt *htt = &ar->htt;
@@ -2354,6 +2476,9 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
case HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND:
ath10k_htt_rx_tx_mode_switch_ind(ar, skb);
break;
+ case HTT_T2H_MSG_TYPE_PEER_STATS:
+ ath10k_htt_fetch_peer_stats(ar, skb);
+ break;
case HTT_T2H_MSG_TYPE_EN_STATS:
default:
ath10k_warn(ar, "htt event (%d) not handled\n",
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b243c899bef..e108d49998c3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4603,9 +4603,17 @@ enum wmi_rate_preamble {
#define ATH10K_HW_NSS(rate) (1 + (((rate) >> 4) & 0x3))
#define ATH10K_HW_PREAMBLE(rate) (((rate) >> 6) & 0x3)
-#define ATH10K_HW_RATECODE(rate, nss, preamble) \
+#define ATH10K_HW_MCS_RATE(rate) ((rate) & 0xf)
+#define ATH10K_HW_LEGACY_RATE(rate) ((rate) & 0x3f)
+#define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)
+#define ATH10K_HW_GI(flags) (((flags) >> 5) & 0x1)
+#define ATH10K_HW_RATECODE(rate, nss, preamble) \
(((preamble) << 6) | ((nss) << 4) | (rate))
+#define VHT_MCS_NUM 10
+#define VHT_BW_NUM 4
+#define VHT_NSS_NUM 4
+
/* Value to disable fixed rate setting */
#define WMI_FIXED_RATE_NONE (0xff)
--
1.7.9.5
^ permalink raw reply related
* Re: Avery's notes from LPC2016 wireless track (Santa Fe)
From: Jes Sorensen @ 2016-11-15 15:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Barry Day, linux-wireless
In-Reply-To: <CAHqTa-3TnBdAhtuoVkU5nSCQM4f1pE=d=K0F7xMCZUSAdk6wvA@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Thu, Nov 3, 2016 at 5:55 PM, Barry Day <briselec@gmail.com> wrote:
>> Thanks for that. Can I take this as meaning there won't be any videos?
>> I would like to have seen Jes Sorensen's talk on rtl8xxxu
>
> As far as I know, no talks at this LPC were recorded.
They weren't but my slides should be available from the Plumbers site.
https://www.linuxplumbersconf.org/2016/ocw/proposals/4089
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Jes Sorensen @ 2016-11-15 15:13 UTC (permalink / raw)
To: Barry Day; +Cc: John Heenan, Kalle Valo, linux-wireless
In-Reply-To: <20161031234706.GA15054@testbox>
Barry Day <briselec@gmail.com> writes:
> On Mon, Oct 31, 2016 at 06:41:30PM -0400, Jes Sorensen wrote:
>> Barry Day <briselec@gmail.com> writes:
>> > On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
>> >> As mentioned previously, if this is to be changed here, it has to be
>> >> matched in the _stop section too. It also has to be investigated exactly
>> >> why this matters for 8723bu. It is possible this matters for other
>> >> devices, but we need to find out exactly what causes this not moving a
>> >> major block of init code around like this.
>> >
>> > I've tested this on the 8192e and 8192c. The same problems occurs with the
>> > 8192e but not the 8192c. Stopping and restarting wpa_supplicant had
>> > no affect on the 8192c ability to connect to an AP.
>>
>> Which version of the driver? I did push in some changes for 8192eu
>> recently that fixed the issue with 8192eu driver reloading, and I would
>> be interested in knowing if this didn't fix the problem for you?
>>
>> Second, could we please keep this on the linux-wireless list where it
>> belongs. Everybody else doesn't necessarily want to receive a copy via
>> netdev and linux-kernel
>
> The tests were done with the latest version of rtl8xxxu-devel. I haven't
> noticed any occurence of the previous issue with the 8192eu.
OK, I am back from my trip, but still burried alive catching up on
things. This is very much on the list of things I want to investigate.
Jes
^ permalink raw reply
* Re: [1/1] ath10k: use the right length of "background"
From: Kalle Valo @ 2016-11-15 15:07 UTC (permalink / raw)
To: Nicolas Iooss; +Cc: ath10k, netdev, linux-wireless, linux-kernel, Nicolas Iooss
In-Reply-To: <20161029111737.19034-1-nicolas.iooss_linux@m4x.org>
Nicolas Iooss <nicolas.iooss_linux@m4x.org> wrote:
> The word "background" contains 10 characters so the third argument of
> strncmp() need to be 10 in order to match this prefix correctly.
>
> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
> Fixes: 855aed1220d2 ("ath10k: add spectral scan feature")
Patch applied to ath-next branch of ath.git, thanks.
31b239824ece ath10k: use the right length of "background"
--
https://patchwork.kernel.org/patch/9403561/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Ben Greear @ 2016-11-15 15:06 UTC (permalink / raw)
To: Bruno Antunes
Cc: voncken, OpenWrt Development List, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <CABUTiXWRkzyV_ic02pUTHG8TbzQUOOYj0L35wMYFcBRgssG0eA@mail.gmail.com>
On 11/15/2016 07:00 AM, Bruno Antunes wrote:
> On 15 November 2016 at 14:55, Ben Greear <greearb@candelatech.com> wrote:
>> The beta-18 release on my web page has the fix and should work fine.
>>
>> Probably soon I will promote the beta-18 to final release
>> status. Any help in testing and verifying the beta works well
>> is welcome.
>
> I will also do testing with that version.
>
> For clarity can I refer you and your firmware releases in the bug report?
It is fine by me. It is a one-line patch to fix the firmware...QCA
can ask me as well if they don't figure it out on their own.
Thanks,
Ben
>
> Thanks,
> Bruno
>>
>> Thanks,
>> Ben
>>
>> On 11/15/2016 06:37 AM, voncken wrote:
>>>
>>> Hi Ben,
>>>
>>> Do you plan to release a candelatech firmware with this fix?
>>>
>>> Regards.
>>>
>>> Cedric Voncken.
>>>>
>>>> -----Message d'origine-----
>>>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>>>> owner@vger.kernel.org] De la part de Ben Greear
>>>> Envoyé : samedi 5 novembre 2016 15:35
>>>> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>>>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>>>> Development List; ath10k@lists.infradead.org
>>>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>>>
>>>>
>>>> Looks to me like 10.4 defaults to the right value, but possibly there
>>>> are other issues with it. I tested my CT 10.4 and it worked OK with
>>>> vlans for me.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
>>>>>
>>>>> would be good if qca can fix this bug finally in all available
>>>>> firmwares. its a very annoying issue since a long time
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>> Am 04.11.2016 um 23:23 schrieb Ben Greear:
>>>>>>
>>>>>> The bug appears that vlan-tx-stripping is unconditionally enabled in
>>>>>> at least my firmware. I have re-compiled w/out that flag set, and
>>>>
>>>> it
>>>>>>
>>>>>> appears to work for me.
>>>>>>
>>>>>> Please download this firmware, rename it firmware-2.bin, make sure
>>>>>> you remove/rename any firmware-5.bin (etc) so mine will load, and
>>>>
>>>> see if that fixes your problem.
>>>>>>
>>>>>>
>>>>>> Please note that it is very likely you will have to use same MAC
>>>>>> address for the VLAN devices that the underlying station uses in
>>>>
>>>> order for this to work.
>>>>>>
>>>>>>
>>>>>> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>>>>
>>>> community.b
>>>>>>
>>>>>> in
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Ben
>>>>>>
>>>>>>
>>>>>> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>>>>>>
>>>>>>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>>>>>>> but for stock firmware, it might be that changing the driver to use
>>>>>>> Ethernet packet type of native-wifi would make .1q vlans work.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ben
>>>>>>>
>>>>>>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>>>>>>
>>>>>>>> I met the same problem before,
>>>>>>>> if i modify the 1q header to other value (0xaa00) before go into
>>>>
>>>> firmware.
>>>>>>>>
>>>>>>>> I can capture the packet in the air I think the vlan packet is
>>>>>>>> dropped in firmware.
>>>>>>>>
>>>>>>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>>>>>>>>
>>>>>>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
>>>>
>>>> <openwrt@ezplanet.net> wrote:
>>>>>>>>>>
>>>>>>>>>> Since the capability is implemented in software you might be
>>>>>>>>>> testing the limit of your router's CPU i/o speed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By loading the module in rawmode?
>>>>>>>>>
>>>>>>>>> The AP is an APU and Sta is an APU2.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Old thread but I think the issue is still present.
>>>>>>>>>>>
>>>>>>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>>>>>>>
>>>>>>>>>>> To make it work both cards must be loaded in rawmode, AP and
>>>>>>>>>>> Sta, and with no security.
>>>>>>>>>>>
>>>>>>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>>>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>>>>>>>
>>>>>>>>>>> Although it works the throughput is very bad.
>>>>>>>>>>> Are there any alternatives to improve the throughput.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Bruno
>>>>>>>>>>>
>>>>>>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
>>>>
>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoyé :
>>>>>>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
>>>>>>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
>>>>>>>>>>>>> VLAN firmware issue
>>>>>>>>>>>>>
>>>>>>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
>>>>>>>>>>>>> for you in other cases as well?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Cedric.
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Ben
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
>>>>
>>>> with eth0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have a computer with vlan configuration set connected
>>>>>>>>>>>>>> to the STA eth0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
>>>>>>>>>>>>>> are not
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> sent.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I checked with wireless sniffer, and I don't see the
>>>>>>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
>>>>>>>>>>>>>> from openwrt, and in all cases I have the same issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your help.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>>>>>>> linux-wireless" in the body of a message to
>>>>>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
>>>>>>>>>>>>> http://www.candelatech.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>
>>>> linux-wireless"
>>>>>>>>>>>>
>>>>>>>>>>>> in
>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org More
>>>>>>>>>>>> majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
>>>>
>>>> devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ath10k mailing list
>>>>>>>>> ath10k@lists.infradead.org
>>>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ben Greear <greearb@candelatech.com>
>>>> Candela Technologies Inc http://www.candelatech.com
>>>
>>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox