On 17 August 2015 at 19:37, Joseph Salisbury
wrote:
> On 08/13/2015 06:34 AM, Kalle Valo wrote:
>> Michal Kazior writes:
>>
>>> On 12 August 2015 at 21:33, Joseph Salisbury
>>> wrote:
Hello,
There are still new folks reporting this issue in the Launchpad bug
report[0]. Has t
On 08/13/2015 06:34 AM, Kalle Valo wrote:
> Michal Kazior writes:
>
>> On 12 August 2015 at 21:33, Joseph Salisbury
>> wrote:
>>> Hello,
>>>
>>> There are still new folks reporting this issue in the Launchpad bug
>>> report[0]. Has there been any progress on the firmware problem reported
>>> in
On 08/17/2015 06:11 AM, Sven Eckelmann wrote:
> Hi,
>
> On Friday 10 April 2015 16:32:29 Ben Greear wrote:
>> First, thanks to everyone that helped me with questions,
>> QCA/Tieto's upstream patches, etc.
>>
>> This needs more testing, but it appears to at least mostly work.
>>
>> I am using this
Vasanthakumar Thiagarajan writes:
> WMI 10.4 uses the same command interface as QCA988X for addba/delba
> debug wmi commands. Fill wmi_10_4_ops table with the functions used
> for QCA988X for these commands.
>
> With this change, the following debugfs entries can be used to
> configure the aggreg
Raja Mani writes:
> Existing phyerr event handlers directly uses phyerr header format
> (ie, struct wmi_phyerr and struct wmi_phyerr_event) in the code
> exactly on how firmware packs it. This is the problem in 10.4 fw
> specific phyerr event handling where it uses different phyerror
> header for
Michal Kazior writes:
> Apparently it's not safe to install both pairwise
> and groupwise keys on AP vdevs as it can cause
> traffic to stop working in some multi-vif
> (WPA+WEP) cases.
>
> Fixes: ce90b27128c2 ("ath10k: fix multiple key static wep with ibss")
> Signed-off-by: Michal Kazior
Than
Vasanthakumar Thiagarajan writes:
> There are three WMI_CHAN_INFO events reported per channel
> in QCA99X0 firmware. First one is a notification at the begining
> of the channel dwell time with cmd_flag as CHAN_INFO_START(cmd_flag = 0),
> second one is a notification at the end of the dwell time
Michal Kazior writes:
> Vif's vdev_id is used as queue number. However due
> to the tx pausing design in ath10k it was possible
> for a new interface to be created with its tx
> queue stopped (via ieee80211_stop_queues). This
> could in turn leave the interface inoperable until
> ath10k_mac_tx_un
Michal Kazior writes:
> Once HTT Tx queue got full offchannel queue was
> stopped and never woken up again. This broke, e.g.
> P2P. This could be reproduced after running a lot
> of traffic enough to saturate 100% of the driver
> Tx queue and then trying to send offchannel
> traffic.
>
> Fixes: 9
Hi,
On Friday 10 April 2015 16:32:29 Ben Greear wrote:
> First, thanks to everyone that helped me with questions,
> QCA/Tieto's upstream patches, etc.
>
> This needs more testing, but it appears to at least mostly work.
>
> I am using this 4.0 related kernel. I think only the last 3 patches
> a
Hi,
I am trying to set up the latest Kernel (4.2rc6) and firmware
(10.1.467-ct-14) form Candela for a 5Ghz network.
Unfortunately I am not able to set channels above 100, although
regulatory domain is set to DE.
Maybe someone has an advice what is going wrong?
Regards
Hannes
My configuratio
By default, ath10k restricts received frames to those matching BSSID.
When other BSS frames are requested (e.g. in mesh mode), add an internal
monitor device so those frames are not filtered.
Signed-off-by: Bob Copeland
---
drivers/net/wireless/ath/ath10k/mac.c | 1 +
1 file changed, 1 insertion
On 8 August 2015 at 23:06, Martin Blumenstingl
wrote:
> Hi Michal,
Hi,
Sorry for my late reply.
> On Tue, Aug 4, 2015 at 7:19 AM, Michal Kazior wrote:
>> It could be that your devices are not transmitting Probe Requests and
>> scan passively 5GHz channels due to their regulatory restrictions.
13 matches
Mail list logo
