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 ]
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
> ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910
> tag), sin
On 5/14/2018 1:09 PM, Gangadharan Vemula wrote:
On Mon, May 14, 2018 at 12:50 PM, Patrick Doyle wrote:
On Mon, May 14, 2018 at 3:28 PM, Gangadharan Vemula
wrote:
Hi,
Silex patch-set was applied to master-pending branch of ath.git. Now,
it is in the process of getting into mainline, Mr. Kvalo
On Tue, May 15, 2018 at 04:13:48PM +0200, Toke Høiland-Jørgensen wrote:
> [ Adding Felix ]
>
>
> Niklas Cassel writes:
>
> > Hello mac80211 and ath10k people
> >
> > Using ath10k, TX stops working when running iperf
> >
> > [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
> > [ 3] 1.0- 2.0 se
+ /* Even in case of radar detection failure we follow the same
+* behaviour as if radar is detected i.e to switch to a different
+* channel.
+*/
+ if (status_arg.status == WMI_HW_RADAR_DETECTED ||
+ status_arg.status == WMI_RADAR_DETECTION_FAIL)
+
+ /* Even in case of radar detection failure we follow the same
+* behaviour as if radar is detected i.e to switch to a different
+* channel.
+*/
+ if (status_arg.status == WMI_HW_RADAR_DETECTED ||
+ status_arg.status == WMI_RADAR_DETECTION_FAIL)
+
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
in another email thread.
Then how come you're sure this is
[ Adding Felix ]
Niklas Cassel writes:
> Hello mac80211 and ath10k people
>
> Using ath10k, TX stops working when running iperf
>
> [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
> [ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec
> [ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec
> [ 3] 3.0
On 05/15/2018 06:45 AM, Niklas Cassel wrote:
Hello mac80211 and ath10k people
Using ath10k, TX stops working when running iperf
What kernel and firmware and ath10k hardware are you using?
Does the same thing happen on older kernels? I had some issues
with ath9k having some sort of tx-hang,
Hello mac80211 and ath10k people
Using ath10k, TX stops working when running iperf
[ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
[ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec
[ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec
[ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec
[ 3] 4.0- 5.0 se
Sriram R writes:
> On 2018-05-15 14:37, Sriram R wrote:
>> This feature adds support for the ath10k host to send information
>> about the specifications of the detected radar to the firmware for
>> validation.
>> A New WMI interface is added for enabling this communication
>> of this information
On 2018-05-15 14:37, Sriram R wrote:
This feature adds support for the ath10k host to send information
about the specifications of the detected radar to the firmware for
validation.
A New WMI interface is added for enabling this communication
of this information between the host and the firmwar
This feature adds support for the ath10k host to send information
about the specifications of the detected radar to the firmware for validation.
A New WMI interface is added for enabling this communication
of this information between the host and the firmware.
v2:
* Modified firmware confirmatio
This enables ath10k/ath9k drivers to collect the specifications of the
radar type once it is detected by the dfs pattern detector unit.
Usage of the collected info is specific to driver implementation.
For example, collected radar info could be used by the host driver
to send to co-processors for a
In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.
This new features enables the ath10k host to send information to the
firmware on the specifications of detected radar type. This allows the
firmware to val
In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.
This new features enables the ath10k host to send information to the
firmware on the specifications of detected radar type. This allows the
firmware to val
This enables ath10k/ath9k drivers to collect the specifications of the
radar type once it is detected by the dfs pattern detector unit.
Usage of the collected info is specific to driver implementation.
For example, collected radar info could be used by the host driver
to send to co-processors for a
This feature adds support for the ath10k host to send information
about the specifications of the detected radar to the firmware for validation.
A New WMI interface is added for enabling this communication
of this information between the host and the firmware.
v2:
* Modified firmware confirmatio
18 matches
Mail list logo
