Re: [RESEND] ath10k: add tx hw 802.11 encapusaltion offloading support

2019-12-18 Thread Sebastian Gottschall
Am 18.12.2019 um 23:45 schrieb Tom Psyborg: ccing Johannes Berg since upstream change (mac80211-next) breaks build: In the commit log its written: remove SUPPORTS_80211_ENCAP HW flag Any sane reasons for doing that? mac80211 fails to build because of removed flags, this is on

Re: [RESEND] ath10k: add tx hw 802.11 encapusaltion offloading support

2019-12-18 Thread John Crispin
On 18/12/2019 23:45, Tom Psyborg wrote: ccing Johannes Berg since upstream change (mac80211-next) breaks build: In the commit log its written: remove SUPPORTS_80211_ENCAP HW flag Any sane reasons for doing that? mac80211 fails to build because of removed flags, this is on backports-5.3-rc4

Re: [RESEND] ath10k: add tx hw 802.11 encapusaltion offloading support

2019-12-18 Thread Tom Psyborg
ccing Johannes Berg since upstream change (mac80211-next) breaks build: In the commit log its written: remove SUPPORTS_80211_ENCAP HW flag Any sane reasons for doing that? mac80211 fails to build because of removed flags, this is on backports-5.3-rc4 Other than that the feature delivers the

Re: [RESEND] ath10k: add tx hw 802.11 encapusaltion offloading support

2019-12-18 Thread Tom Psyborg
On 17/12/2019, Kalle Valo wrote: > John Crispin wrote: > >> This patch adds support for ethernet rxtx mode to the driver. The feature >> is enabled via a new module parameter. If enabled to driver will enable >> the feature on a per vif basis if all other requirements were met. >> >> Testing on

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

2019-12-18 Thread Sebastian Gottschall
I don't think it is correct to say periodic calibration does not happen with ath10k.  Maybe very old wave-1 firmware has some issues, but recent stuff appears to work.  I do see reported noise floor changing on 9984. like on qca998x i expect it to change at least every 300 seconds. thats the

[PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits

2019-12-18 Thread Kalle Valo
From: Wen Gong The vendor commands is to add API for user to configure dynamic SAR power limits, it will not replace the existing power control functionality, it is to make more convenient to configure power. An example of usage(wlan0 is the wireless interface dev name): iw dev wlan0 vendor

[PATCH 2/2] ath10k: allow dynamic SAR power limits to be configured

2019-12-18 Thread Kalle Valo
From: Wen Gong Add support for a vendor command for STATION, the command QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS which is already defined in git://w1.fi/hostap.git (src/command/qca-vendor.h). This allows user space to configure power limits for 2.4 GHz and 5 GHz bands. ath10k set pdev

[PATCH 0/2] ath10k: SAR power limit vendor command

2019-12-18 Thread Kalle Valo
Hi, here's a patchset adding dynamic SAR power limit vendor command to ath10k. This follows the new process documented in the wiki: https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api Please review. Kalle Wen Gong (2): nl80211: vendor-cmd: qca: add

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

2019-12-18 Thread Ben Greear
On 12/18/2019 12:05 AM, Justin Capella wrote: Don't mean to steal your thread here, but since it's being discussed-- is there something that can be done to provide more accurate/precise data? Use of the default is widespread so not a reason to hold back the patch imo, but with a proposed

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

2019-12-18 Thread Tom Psyborg
On 18/12/2019, Sebastian Gottschall wrote: > > Am 18.12.2019 um 03:37 schrieb Ben Greear: >> >> >> On 12/17/2019 06:12 PM, Sebastian Gottschall wrote: >>> i dont know what you want to compare here. >>> >>> 1. you compare 2 different wifi chipsets. both have different >>> sensititivy and overall

Re: [PATCH 2/4] mac80211: fix issue in loop scenario

2019-12-18 Thread Toke Høiland-Jørgensen
Johannes Berg writes: > On Wed, 2019-12-18 at 18:12 +0800, yi...@codeaurora.org wrote: >> >> Yes, this is a fix to the first patch. Actually, the rest of two patches >> are also serve the same. So, are you suggesting to merge them to the >> first patch? > > Yes. > >> Previouly, I had added

Re: [PATCH 2/4] mac80211: fix issue in loop scenario

2019-12-18 Thread Johannes Berg
On Wed, 2019-12-18 at 18:12 +0800, yi...@codeaurora.org wrote: > > Yes, this is a fix to the first patch. Actually, the rest of two patches > are also serve the same. So, are you suggesting to merge them to the > first patch? Yes. > Previouly, I had added Toke's signature in this patch but

Re: [PATCH 2/4] mac80211: fix issue in loop scenario

2019-12-18 Thread yiboz
在 2019-12-13 17:56,Johannes Berg 写道: On Fri, 2019-12-13 at 15:19 +0800, Yibo Zhao wrote: In a loop txqs dequeue scenario, if the first txq in the rbtree gets removed from rbtree immediately in the ieee80211_return_txq(), the loop will break soon in the ieee80211_next_txq() due to schedule_pos

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

2019-12-18 Thread Sebastian Gottschall
Am 18.12.2019 um 09:05 schrieb Justin Capella: Don't mean to steal your thread here, but since it's being discussed-- is there something that can be done to provide more accurate/precise data? Use of the default is widespread so not a reason to hold back the patch imo, but with a proposed

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

2019-12-18 Thread Justin Capella
Don't mean to steal your thread here, but since it's being discussed-- is there something that can be done to provide more accurate/precise data? Use of the default is widespread so not a reason to hold back the patch imo, but with a proposed pcap-ng capture information block they would become