Re: [PATCH] ath10k: retrieve MAC address from firmware if provided

On Tue, Aug 28, 2018 at 05:33:01PM +0300, Kalle Valo wrote: > Arend van Spriel writes: > > > On 8/13/2018 7:14 PM, Brian Norris wrote: > >> On Sat, Aug 11, 2018 at 11:26 AM Arend van Spriel > >> wrote: > >>> > >>> On 8/11/2018 1:39 AM, Brian Norris wrote: > Devices may provide their own

ath10k: adding wlan to bridge causes WPA2-PSK to fail

Hi, I am trying to connect ath10k interface to Linux bridge after enabling of 4addr mode in WPA2-PSK mode, but EAPOL handshake fails, M1 is not received by the wpa_supplicant. ath10k_pci: QCA6174 = pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 qca6174 hw3.2 target

[RFC PATCH] ath10k: ath10k_htc_pktlog_svc_supported() can be static

Fixes: c4ce46304e1f ("ath10k: Enable pktlog for WCN3990 target") Signed-off-by: kbuild test robot --- htc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c index 1727823..4e70ff2 100644 ---

Re: [PATCH 2/2] ath10k: Enable pktlog for WCN3990 target

Hi Govind, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on ath6kl/ath-next] [also build test WARNING on v4.19-rc1 next-20180828] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [PATCH] ath10k: retrieve MAC address from firmware if provided

Arend van Spriel writes: > On 8/13/2018 7:14 PM, Brian Norris wrote: >> On Sat, Aug 11, 2018 at 11:26 AM Arend van Spriel >> wrote: >>> >>> On 8/11/2018 1:39 AM, Brian Norris wrote: Devices may provide their own MAC address via system firmware (e.g., >>> >>> You got me confused by using

Re: [PATCH 1/2] ath10k: Support extended board data download for dual-band QCA9984

Sathishkumar Muruganandam wrote: > Just moving functions down in the file, no functional changes. > > Signed-off-by: Sathishkumar Muruganandam > Signed-off-by: Kalle Valo Try to make the patch titles always unique, I changed this in pending branch to: ath10k: refactoring needed for

Re: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit

Sven Eckelmann wrote: > Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in > the RX and TX path. These filtered channel can in theory still be used by > the hardware but the signal strength is reduced so much that it makes no > sense. > > There is already a DT property

Re: [PATCH] ath10k: use struct_size() in kzalloc()

"Gustavo A. R. Silva" wrote: > One of the more common cases of allocation size calculations is finding > the size of a structure that has a zero-sized array at the end, along > with memory for some number of elements for that array. For example: > > struct foo { > int stuff; >

Re: [PATCH] ath10k: schedule hardware restart if WMI command times out

Martin Willi wrote: > When running in AP mode, ath10k sometimes suffers from TX credit > starvation. The issue is hard to reproduce and shows up once in a > few days, but has been repeatedly seen with QCA9882 and a large > range of firmwares, including 10.2.4.70.67. > > Once the module is in

Re: [PATCH] ath10k: Skip resetting rx filter for WCN3990

Rakesh Pillai wrote: > WCN3990 has the MAC_PCU_ADDR1 configured properly > and hence it will not send spurious ack frames > during boot up. > > Hence the reset_rx_filter workaround is not needed > for WCN3990. Add a hw_param to indicate if hardware rx > filter reset is needed and skip the

Re: [PATCH 4/4] ath10k: add debugfs support to dump per sta tx stats

Anilkumar Kolli wrote: > This patch adds 'tx_stats' in per station debugfs entry. > > Use this command to dump tx_stats: > cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/ > stations//tx_stats > > Signed-off-by: Anilkumar Kolli > Signed-off-by: Kalle Valo kbuild bot found new

Re: [PATCH 3/4] ath10k: add extended per sta tx statistics support

Anilkumar Kolli wrote: > This patch adds per station tx statistics support. > > Per station tx stats include > - pkts/bytes transmitted at all possible rates(mcs/nss/bw/gi). > - ACK fails count > - ampdu bytes/pkts transmitted at all possible rates(mcs/nss/bw/gi). > - BA fails count > >

Re: [PATCH] ath10k: Add waiting htt tx complete before wow enable

Wen Gong writes: > If there have some tx packets pending in firmware, and then system s/have/are/ but I can fix that. > enter suspend, firmware will fail for wow enable. This will trigger > mac80211 to stop ath10k and download firmware again, then it is > non-wow suspend. > > After add the

Re: [PATCH 0/3] Add support for ftm responder configuration

On Wed, 2018-08-22 at 11:22 -0700, Pradeep Kumar Chitrapu wrote: > > Should we just ignore that? Or perhaps add a separate capability for > > it? > > Yes, even we behave the same. In that case, we can go ahead now with the > capability to only enable FTM responder. If the driver wants to

[PATCH] ath10k: Add waiting htt tx complete before wow enable

If there have some tx packets pending in firmware, and then system enter suspend, firmware will fail for wow enable. This will trigger mac80211 to stop ath10k and download firmware again, then it is non-wow suspend. After add the waiting htt tx complete, then firmware will have some time window