[PATCH v7] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized peer_bw_rxnss_override parameter which is required since VHT160 operation mode

[PATCH v5] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized peer_bw_rxnss_override parameter which is required since VHT160 operation mode

[PATCH v4] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized peer_bw_rxnss_override parameter which is required since VHT160 operation mode

[PATCH v3] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized peer_bw_rxnss_override parameter which is required since VHT160 operation mode

[PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

From: Sebastian Gottschall starting with firmware 10.4.3.4.x series QCA changed the handling of the channel property band_center_freq1 and band_center_freq2 in vht160 operation mode likelly for backward compatiblity with vht80 only capable clients. this patch adjusts

[PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized peer_bw_rxnss_override parameter which is required since VHT160 operation mode

[PATCH v1] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized peer_bw_rxnss_override parameter which is required since VHT160 operation mode

[PATCH v1] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080 capability by rx rate. this is wrong and may lead to a non initialized peer_bw_rxnss_override parameter which is required since VHT160 operation mode

[PATCH v3] ath9k: fix crash in spectral scan

From: Sebastian Gottschall fixes crash seen on arm smp systems (gateworks ventana imx6) Signed-off-by: Sebastian Gottschall v2: fix wrong field and add signed-off-by v3: forgot to include correct latest patch, so just fix that and refresh

[PATCH v2] ath9k: fix crash in spectral scan

From: Sebastian Gottschall fixes crash seen on arm smp systems (gateworks ventana imx6) Signed-off-by: Sebastian Gottschall v2: fix wrong field and add signed-off-by Unable to handle kernel NULL pointer dereference at virtual address 0014

[PATCH v1] ath9k: fix crash in spectral scan

From: Sebastian Gottschall fixes crash seen on arm smp systems (gateworks ventana imx6) Unable to handle kernel NULL pointer dereference at virtual address 0014 pgd = 80004000 [0014] *pgd= Internal error: Oops - BUG: 17 [#1] PREEMPT SMP ARM Modules

[PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH v11] ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH v10] ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH v9] ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH v8] ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH v7] ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH] v6 ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH] v5 ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled with

[PATCH] v3 ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and ipq4019 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled

[PATCH] v2 ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and ipq4019 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled

[PATCH] [PATCH 1/1] ath10k: add LED and GPIO controlling support for various chipsets

From: Sebastian Gottschall Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and ipq4019 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be controlled