[ath6kl:master-pending] BUILD SUCCESS ee805609cf23d6e07659f2b589b22738f25ddc4b

2020-12-21 Thread kernel test robot
tinyconfig i386defconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a001-20201221 x86_64

[ath6kl:pending] BUILD SUCCESS ada580f28cfed6ae92b8d92f785b1ffe8226aa9f

2020-12-21 Thread kernel test robot
allmodconfig powerpc allnoconfig x86_64 randconfig-a001-20201221 x86_64 randconfig-a006-20201221 x86_64 randconfig-a002-20201221 x86_64 randconfig-a004-20201221 x86_64 randconfig-a003

[PATCH v2] ath10k: fix wmi mgmt tx queue full due to race condition

2020-12-21 Thread Miaoqing Pan
Failed to transmit wmi management frames: [84977.840894] ath10k_snoc a00.wifi: wmi mgmt tx queue is full [84977.840913] ath10k_snoc a00.wifi: failed to transmit packet, dropping: -28 [84977.840924] ath10k_snoc a00.wifi: failed to submit frame: -28 [84977.840932] ath10k_snoc

Re: [PATCH] ath: add support for special 0x0 regulatory domain

2020-12-21 Thread Wen Gong
On 2020-12-21 05:06, Sustek Goran wrote: Hi, on my ath10k Chipset, QCA9984(https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v5-20-2/) afetr this patch i can not longer to initialize my card. my dmesg log: So i need to revert this patch! Is my card need aditional support? Can you

skb_cb corruption in ath10k

2020-12-21 Thread Ben Greear
Hello, I'm trying to figure out what changed in the last few kernels that is making: struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb); if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT) /* why is code here all of a sudden */ in data frames in ath10k, when, to the best of my

ath10k-firmware: QCA4019 hw1.0: Add Linksys WHW01 v1 specific BDFs

2020-12-21 Thread Peter Adkins
Hello there, In order to properly add support to OpenWrt for the Linksys WHW01 v1 (FCC ID Q87-0333) [1], BDFs were required to be extracted from the vendor's firmware (version 1.1.13.202617 [2]). Without these the radios did not appear to operate correctly; the 5GHz radio was unable to scan,

Re: [PATCH v2] ath10k: Per-chain rssi should sum the secondary channels

2020-12-21 Thread Ben Greear
On 12/21/20 10:30 AM, Kalle Valo wrote: gree...@candelatech.com wrote: From: Ben Greear This makes per-chain RSSI be more consistent between HT20, HT40, HT80. Instead of doing precise log math for adding dbm, I did a rough estimate, it seems to work good enough. Tested on ath10k-ct 9984

Re: [PATCH] ath10k: fix wmi mgmt tx queue full due to race condition

2020-12-21 Thread Kalle Valo
Brian Norris writes: > Hi, > > On Sun, Dec 20, 2020 at 5:53 PM Miaoqing Pan wrote: >> >> Failed to transmit wmi management frames: >> >> [84977.840894] ath10k_snoc a00.wifi: wmi mgmt tx queue is full >> [84977.840913] ath10k_snoc a00.wifi: failed to transmit packet, >> dropping: -28 >>

Re: [PATCH] ath10k: fix wmi mgmt tx queue full due to race condition

2020-12-21 Thread Brian Norris
Hi, On Sun, Dec 20, 2020 at 5:53 PM Miaoqing Pan wrote: > > Failed to transmit wmi management frames: > > [84977.840894] ath10k_snoc a00.wifi: wmi mgmt tx queue is full > [84977.840913] ath10k_snoc a00.wifi: failed to transmit packet, dropping: > -28 > [84977.840924] ath10k_snoc

Re: [PATCH v2 0/2] ath10k: Fixes during subsystem recovery

2020-12-21 Thread Kalle Valo
Rakesh Pillai writes: > This patch series includes some fixes when the device > is in recovery mode, i.e. when the firmware goes down. > > - Pausing TX queues when FW goes down > - Removed unwanted/extra error logging in pkt TX path > - Skipping wait for FW response for delete cmds > - Handling

Re: [PATCH v2] ath10k: Per-chain rssi should sum the secondary channels

2020-12-21 Thread Kalle Valo
gree...@candelatech.com wrote: > From: Ben Greear > > This makes per-chain RSSI be more consistent between HT20, HT40, HT80. > Instead of doing precise log math for adding dbm, I did a rough estimate, > it seems to work good enough. > > Tested on ath10k-ct 9984 firmware. > > Signed-off-by:

Re: [PATCH][master/pending] ath10k: assign new interfaces type to parent type

2020-12-21 Thread Kalle Valo
Isaac Hermida writes: > This is needed to have the AP mode working for SDIO. > Tested with lastest master/pending code on a QCA6564 chip with firmware > firmware-sdio-6.bin_WLAN.RMH.4.4.1-00011-QCARMSWP-2 > > Signed-off-by: Isaac Hermida > --- > drivers/net/wireless/ath/ath10k/mac.c | 3 +++ >

[PATCH] ath10k: remove unused struct ath10k::dev_type

2020-12-21 Thread Kalle Valo
It's unused so let's get rid of it. Compile tested only, no functional changes. Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/core.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index

Re: [PATCH] net: ath10k: santity check for ep connectivity

2020-12-21 Thread Kalle Valo
Zekun Shen writes: > Function ep_rx_complete is being called without NULL checking > in ath10k_htc_rx_completion_handler. Without such check, mal- > formed packet is able to cause jump to NULL. > > ep->service_id seems a good candidate for sanity check as it is > used in usb.c. > >

Re: [PATCH] ath10k:add support for multicast rate control

2020-12-21 Thread Kalle Valo
Pradeep Kumar Chitrapu wrote: > Issues wmi command to firmware when multicast rate change is received > with the new BSS_CHANGED_MCAST_RATE flag. > > Signed-off-by: Pradeep Kumar Chitrapu (Cleaning up my backlog, this is from 2018.) I don't understand the issue from commit log, please clarify

Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

2020-12-21 Thread spark...@gmx.de
Am 30.10.20 um 14:23 schrieb Alvin Sipraga: Hi, On 10/30/20 8:20 AM, Jouni Malinen wrote: So the issue is in not being able to operate an AP on the 5 GHz band? That sounds like the expected behavior for any device that has not been calibrated and provisioned for a specific country where

Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

2020-12-21 Thread spark...@gmx.de
On 10/30/20 8:20 AM, Jouni Malinen wrote: > So the issue is in not being able to operate an AP on the 5 GHz band? > That sounds like the expected behavior for any device that has not > been calibrated and provisioned for a specific country where > regulatory rules allow operation on the 5 GHz