Re: VHT 160Mhz and nss related config.

On 10 February 2017 at 20:22, Sebastian Gottschall wrote: > i really can't believe this. if this is true the 160 mhz mode would not > make any sense. > the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so > vht160 would not increase performance in any

Re: VHT 160Mhz and nss related config.

i really can't believe this. if this is true the 160 mhz mode would not make any sense. the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so vht160 would not increase performance in any way Am 10.02.2017 um 23:58 schrieb Ben Greear: So, it appears that the ath10k QCA9984 4x4

[PATCH] ath10k: Configure rxnss_override for 10.4 firmware.

From: Ben Greear QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz. First, report this to user-space by setting the max-tx-speed and max-rx-speed vht capabilities. Second, if the peer rx-speed is configured, and if we are in 160 or 80+80 mode, and the peer

Re: VHT 160Mhz and nss related config.

On 02/10/2017 03:23 PM, Adrian Chadd wrote: Is it limited on both tx and rx or only one? Both, as I understand it. I think maybe we could use the max-tx-rate and max-rx-rate fields in the vht mcs info field to give user-space a clue. Thanks, Ben Adrian On Feb 10, 2017 2:58 PM, "Ben

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

On 02/09/2017 11:03 PM, Valo, Kalle wrote: Ben Greear writes: On 02/07/2017 01:14 AM, Valo, Kalle wrote: Adrian Chadd writes: Removing this method makes the diff to FreeBSD larger, as "vif" in FreeBSD is a different pointer. (Yes, I have

Re: QCA9880 3x3 80Mhz low performance

I don't know. I would first suggest that you try an x86 platform with powerful CPU in your own test environment. Possibly we are just using a better isolation chamber or have some other advantage in our environment or test setup. If you can reproduce our good results with x86 in your setup,

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

On 9 February 2017 at 23:37, Joe Perches wrote: > On Thu, 2017-02-09 at 23:14 -0800, Adrian Chadd wrote: > >> If there >> were accessors for the skb data / len fields (like we do for mbufs) >> then porting the code would've involved about 5,000 less changed >> lines. > > What

Re: [v4] ath10k: fix napi crash during rmmod when probe firmware fails

Kalle Valo wrote: > This fixes the below crash when ath10k probe firmware fails, NAPI polling > tries > to access a rx ring resource which was never allocated. An easy way to > reproduce this is easy to remove all the firmware files, load ath10k modules > and ath10k will

Re: [RFC,04/10] ath10k: new fw fetch functionality

Erik Stromdahl wrote: > A new function for creating the fw file name dynamically. > > Since both SDIO and USB based chipsets will use different > firmware from the PCIe and AHB chipsets, the fw file name > is created dynamically. > > The new firmware names are: > >

[PATCH v2 0/4] ath10k: silence firmware file probing warnings

Hi, here are patches to make ath10k less spammy during initialisation. v2: * RFC -> PATCH * add new patches: ath10k: fetch firmware images in a loop ath10k: add directory to board data error message ath10k: convert warning about non-existent OTP board id to debug message --- Erik

[PATCH v2 3/4] ath10k: silence firmware file probing warnings

From: Michal Kazior Firmware files are versioned to prevent older driver instances to load unsupported firmware blobs. This is reflected with a fallback logic which attempts to load several firmware files. This however produced a lot of unnecessary warnings sometimes

[PATCH v2 4/4] ath10k: convert warning about non-existent OTP board id to debug message

Currently ath10k unncessarily warns about board id not available from OTP: ath10k_pci :02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci :02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub : ath10k_pci :02:00.0: kconfig debug 1 debugfs 1

[PATCH v2 2/4] ath10k: add directory to board data error message

This way user has a better idea what file exactly is missing. This is needed when we switch to using request_firmware_direct() which doesn't print any errors anymore. Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/core.c |3 ++- 1 file changed, 2

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

Kalle Valo writes: > BTW, just curious but why do you have "during rmmod" in the title? I > think I was able to reproduce this crash by removing all firmware files > and didn't use rmmod at all. Nevermind, I was blind again. It was my script which calls rmmod and I

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

Mohammed Shafi Shajakhan writes: > the change suggested by you helps, and the device probe, scan > is successful as well. Still good to have this change part of your > basic sanity and regression testing ! Sure. I was sort of expecting that you would send v4 but I