Peter Oh writes:
>> Sure, every software change can cause regressions. But the thing is that
>> this isn't an optional, ath10k has to have this to be able to continue
>> using DFS channels.
>
> Kalle, you said you don't know which exact FCC requirement this is for
>
Niklas Cassel writes:
> [ .. snip .. ]
>> > Sure, the regular way ath10k_mac_op_wake_tx_queue is called is via
>> > ieee80211_subif_start_xmit => __ieee80211_subif_start_xmit =>
>> > ieee80211_xmit_fast
>> > => ieee80211_queue_skb => drv_wake_tx_queue.
>> >
>> > But I
Hello,
This sounds exactly like the issue I just submitted a patch for.
Can you test https://patchwork.kernel.org/patch/10399613/ if that solves
the issue?
Am 15.05.2018 um 22:31 schrieb Niklas Cassel:
> On Tue, May 15, 2018 at 04:13:48PM +0200, Toke Høiland-Jørgensen wrote:
>> [ Adding Felix
On 5/15/2018 9:56 PM, Kalle Valo wrote:
Jay Foster writes:
I too have been, off and on, looking for an ath10k driver solution for
a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an
eye on this mailing list. I just tried the latest
Hello Niklas
Quick question:
Are you using my patch: "ath10k: add htt_tx num_pending window"?
I assume (from your logs below) that you are not...
See more comments below.
I guess the best way to describe this is to show my ftrace buffer:
ksoftirqd/2-21[002] .ns474.711744:
+ linux-wireless
Jay Foster writes:
> On 5/15/2018 9:56 PM, Kalle Valo wrote:
>> Jay Foster writes:
>>
>>> I too have been, off and on, looking for an ath10k driver solution for
>>> a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been
On 5/16/2018 11:27 AM, Kalle Valo wrote:
+ linux-wireless
Jay Foster writes:
On 5/15/2018 9:56 PM, Kalle Valo wrote:
Jay Foster writes:
I too have been, off and on, looking for an ath10k driver solution for
a SparkLAN WUBQ-159ACN USB