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

Am 26.04.2018 um 15:44 schrieb Ben Greear: On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote: 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

[PATCH] ath10k: sdio: jump to correct label in error handling path

Jump to the correct label in error handling path. At this point of execution create_singlethread_workqueue() has succeeded, so it should be properly destroyed. Jump label was renamed in commit ec2c64e20257 ("ath10k: sdio: fix memory leak for probe allocations"). However, the bug was originally

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

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote: 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

[PATCHv2] cfg80211: Call reg_notifier for self managed hints conditionally

From: Amar Singhal Currently the regulatory core does not call the regulatory callback reg_notifier for self managed wiphys, but regulatory_hint_user() call is independent of wiphy and is meant for all wiphys in the system. Even a self managed wiphy may be interested in

Re: [PATCH v2 00/21] staging: wilc1000: remove unused code and reorder functions

Hi Greg, This series is actually V1 and not V2. Sorry, it's mistake from my side. If you want me to resend this series, please let me know. On Wed, 25 Apr 2018 22:48:05 +0530 Ajay Singh wrote: > This patch series contains fixes to remove the unused code. It also

Re: [PATCH 09/12] iwlwifi: pcie: remove non-responsive device

On Wed, 2018-04-25 at 11:01 +0300, Kalle Valo wrote: > Luca Coelho writes: > > > On Tue, 2018-04-24 at 12:44 +0300, Kalle Valo wrote: > > > Luca Coelho writes: > > > > > > > From: Luca Coelho > > > > > > > > If we fail to to grab NIC

[PATCH v2 12/12] iwlwifi: mvm: set wakeup filters for wowlan "any" configuration

From: Eliad Peller In case of "any" wowlan trigger is configured, no valid wakeup filter was configured. Moreover, the fw assumes there's no connection when there are no configured wakeup filters. This leads to the station info not being updated on D3 command, causing

Re: [PATCH v2 12/12] iwlwifi: pcie: remove non-responsive device

Ooops, I obviously meant "PATCH v2 09/12" in the subject. -- Luca. On Thu, 2018-04-26 at 10:53 +0300, Luca Coelho wrote: > From: Luca Coelho > > If we fail to to grab NIC access because the device is not responding > (i.e. CSR_GP_CNTRL returns 0x), remove the

Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

Eyal Reizer writes: > pm_runtime handles sdio power on and power off transitions. > An old workaround for trying to control the power explicitly from the > driver was in fact causing failures on suspend/resume as the mmc layer > already power the module on resume. > > In

Re: [PATCH v2 01/21] staging: wilc1000: replace crc7_byte() with inline macro CRC7_BYTE

On Wed, Apr 25, 2018 at 10:48:06PM +0530, Ajay Singh wrote: > Replace the function call for crc7_byte() with macro CRC7_BYTE. > crc7_byte() was called in close while(), so replaced it with macro to > avoid extra functional call depth. > > Signed-off-by: Ajay Singh >

[PATCH v2 12/12] iwlwifi: pcie: remove non-responsive device

From: Luca Coelho If we fail to to grab NIC access because the device is not responding (i.e. CSR_GP_CNTRL returns 0x), remove the device from the PCI bus, to avoid any further damage, and to let the user space rescan. In order to inform the userspace that a

[PATCH] net: rfkill: gpio: fix memory leak in probe error path

Make sure to free the rfkill device in case registration fails during probe. Fixes: 5e7ca3937fbe ("net: rfkill: gpio: convert to resource managed allocation") Cc: stable # 3.13 Cc: Heikki Krogerus Signed-off-by: Johan Hovold

Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

On Thu, 2018-04-26 at 11:09 +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the wireless-drivers-next tree got a > conflict in: > > drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c > > between commit: > > 77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if

Re: [PATCH] net: rfkill: gpio: fix memory leak in probe error path

On Thu, Apr 26, 2018 at 09:31:52AM +0200, Johan Hovold wrote: > Make sure to free the rfkill device in case registration fails during > probe. > > Fixes: 5e7ca3937fbe ("net: rfkill: gpio: convert to resource managed > allocation") > Cc: stable # 3.13 > Cc: Heikki

RE: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

> > > pm_runtime handles sdio power on and power off transitions. > > An old workaround for trying to control the power explicitly from the > > driver was in fact causing failures on suspend/resume as the mmc layer > > already power the module on resume. > > > > In case of resume pm_runtime_get

[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

Re: [PATCH v2 01/21] staging: wilc1000: replace crc7_byte() with inline macro CRC7_BYTE

Hi Greg, On Thu, 26 Apr 2018 09:40:20 +0200 Greg KH wrote: > On Wed, Apr 25, 2018 at 10:48:06PM +0530, Ajay Singh wrote: > > Replace the function call for crc7_byte() with macro CRC7_BYTE. > > crc7_byte() was called in close while(), so replaced it with > > macro to

[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][next] ath10k: fix spelling mistake: "servive" -> "service"

From: Colin Ian King Trivial fix to spelling mistake in ath10k_warn warning message text Signed-off-by: Colin Ian King --- drivers/net/wireless/ath/ath10k/wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[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

Re: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

"Reizer, Eyal" writes: >> >> > pm_runtime handles sdio power on and power off transitions. >> > An old workaround for trying to control the power explicitly from the >> > driver was in fact causing failures on suspend/resume as the mmc layer >> > already power the module on

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

Am 26.04.2018 um 22:35 schrieb Ben Greear: On 04/26/2018 01:21 PM, Sebastian Gottschall wrote: Am 26.04.2018 um 17:30 schrieb Ben Greear: On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall current handling of peer_bw_rxnss_override

[RFCv2 0/6] cfg80211/mac80211: Add support to configure and monitor rssi/txrate threshold

This patchsets introduced new NL command and api to support configuring rssi and txrate for the connected stations. And implemented new api to notify the threshold cross event. This will be useful/requires for the user application like steering to monitor station's activity change. Tamizh chelvam

[RFCv2 4/6] cfg80211: Add support to configure station specific txrate threshold for AP mode

This patch add support to configure station specific txrate threshold to monitor change in txrate for stations. This will be useful for the user application like steering to configure and monitor the change event of txrate for the station. NL80211_ATTR_STA_MON_LOW_TXRATE_THOLD and

[RFCv2 1/6] cfg80211: Add support to configure station specific rssi threshold for AP mode

This patch add support to configure station specific rssi threshold to monitor station's signal strength modification. This will be useful for the user application like steering to configure and monitor the station's signal strength change event. New NL80211_CMD_STA_MON command introduced to

[RFCv2 5/6] mac80211: Add support to configure txrate threshold for station

This patch add support to configure station specific low and high txrate thresholds using ieee80211_set_sta_mon_txrate_config API. This configuration is used for tracking the txrate for connected stations. Signed-off-by: Tamizh chelvam --- net/mac80211/cfg.c | 35

[RFCv2 6/6] mac80211: Implement functionality to monitor txrate cross event for station

Trigger cfg80211_sta_mon_txrate_notify with the corresponding txrate event when the txrate for a station goes out of configured range. This event will be useful for the application like steering to take decision on any station depends on its current capability. Signed-off-by: Tamizh chelvam

[RFCv2 3/6] mac80211: Implement functionality to monitor station's rssi threshold cross

Triggers cfg80211_sta_mon_rssi_notify with the corresponding event when station signal goes out of configured threshold. It uses rx data signal to check against rssi threshold configured by the user. This event will be useful for the application like steering to take decision on any station

[RFCv2 2/6] mac80211: Add support to configure rssi threshold for AP mode

This patch add support to configure station specific single or multi rssi thresholds using ieee80211_set_sta_mon_rssi_config and ieee80211_set_sta_mon_rssi_range_confg APIs. This configuration is used for tracking the connected station's signal strength. Signed-off-by: Tamizh chelvam

[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

RE: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac

> -Original Message- > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: Wednesday, April 25, 2018 3:36 PM > To: Pkshih > Cc: larry.fin...@lwfinger.net; linux-wireless@vger.kernel.org > Subject: Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac > >

[PATCH v2] staging/wilc1000: fix wilc_mac_xmit()'s return type

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, but the implementation in this driver returns an 'int'. Fix this by returning 'netdev_tx_t' in this driver too and accordingly change 'return 0;' by 'return NETDEV_TX_OK;' Signed-off-by:

[PATCH] mac80211: fix kernel-doc "bad line" warning

> --- include/net/mac80211.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20180426.orig/include/net/mac80211.h +++ linux-next-20180426/include/net/mac80211.h @@ -2080,7 +2080,7 @@ struct ieee80211_txq { * virtual interface might not be given air time

[PATCH 4/6] brcmfmac: constify firmware mapping tables

The information in the firmware mapping does not need to be modified so it can be static const. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend

[PATCH 6/6] brcmfmac: coarse support for PCIe shared structure rev7

From: Franky Lin Revision 7 of PCIe dongle interface increases the item size of tx and rx complete rings to accommodate extra payload for new feature. This patch simply bump up the size of these two rings without adding the support for utilizing the new space. This makes

[PATCH 5/6] brcmfmac: add hostready indication

From: Franky Lin A hostready signal is introduced to inform firmware through mailbox doorbell1 when common ring initialized or D3 exited. Reviewed-by: Arend van Spriel Signed-off-by: Franky Lin Signed-off-by:

[PATCH 1/6] brcmfmac: check p2pdev mac address uniqueness

The mac address for p2pdev must be different from the primary interface due to firmware requirement. Add an explicit check for this requirement if user-space provides a mac address. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts

[PATCH 3/6] brcmfmac: use nl80211_band directly to get ieee80211 channel

From: Franky Lin The enum nl80211_band used to retrieve wiphy->bands is the same as wiphy->bands->band which is checked by wiphy_register(). So it can be used directly as parameter of ieee80211_channel_to_frequency(). Reviewed-by: Arend van Spriel

[PATCH 0/6] brcmfmac: new pcie fw-api support and cleanup

This series contains following: * support for PCIe rev7 firmware api. * include boottime stamp for bss. * check user-space provided P2P DEVICE mac address. The series applies to the master branch of wireless-drivers-next repository. Arend van Spriel (2): brcmfmac: check p2pdev mac

RE: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

> > >> > >> > pm_runtime handles sdio power on and power off transitions. > >> > An old workaround for trying to control the power explicitly from the > >> > driver was in fact causing failures on suspend/resume as the mmc layer > >> > already power the module on resume. > >> > > >> > In case of

pull-request: wireless-drivers 2018-04-26

Hi Dave, here's a pull request to net tree, more info below. Please let me know if you have any problems. Kalle The following changes since commit 4608f064532c28c0ea3c03fe26a3a5909852811a: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next (2018-04-03 14:08:58 -0700) are

[PATCH 2/6] brcmfmac: reports boottime_ns while informing bss

From: Franky Lin Provides a timestamp in bss information so user space can see when the bss info was updated. Since tsf is not available from the dongle events boottime is reported instead. Reported-by: Dmitry Shmidt Reviewed-by: Arend van Spriel

Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

Luciano Coelho writes: > On Thu, 2018-04-26 at 11:09 +1000, Stephen Rothwell wrote: >> Hi all, >> >> Today's linux-next merge of the wireless-drivers-next tree got a >> conflict in: >> >> drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c >> >> between commit: >>

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

On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote: 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

[PATCH] rsi: Uninitialized return value in rsi_reset_card()

If rsi_usb_master_reg_write() fails then "ret" hasn't been initialized. Fixes: 16d3bb7b2f37 ("rsi: disable fw watchdog timer during reset") Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c b/drivers/net/wireless/rsi/rsi_91x_usb.c index

[PATCH] rsi_91x_usb: fix uninitialized variable

There is a potential execution path in which variable ret is returned without being properly initialized previously. Fix this by storing the value returned by function rsi_usb_master_reg_write into _ret_. Addresses-Coverity-ID: 1468407 ("Uninitialized scalar variable") Fixes: 16d3bb7b2f37 ("rsi:

[PATCH] rsi_91x_mac80211: fix structurally dead code

Function rsi_hal_key_config returns before reaching code at line 922 if (status), hence this code is structurally dead. Fix this by storing the value returned by rsi_hal_load_key into _status_ for its further evaluation and use. Addresses-Coverity-ID: 1468409 ("Structurally dead code") Fixes:

Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

On Thu, 2018-04-26 at 13:33 +0300, Kalle Valo wrote: > Luciano Coelho writes: > > > On Thu, 2018-04-26 at 11:09 +1000, Stephen Rothwell wrote: > > > Hi all, > > > > > > Today's linux-next merge of the wireless-drivers-next tree got a > > > conflict in: > > > > > >

pull-request: iwlwifi-next 2018-04-26

Hi Kalle, This is the second batch of patches intended for v4.18. Nothing major here, just the usual continued development, bugfixes, new FW APIs and some new features. More details about the contents in the tag description. I have sent this out before and kbuildbot reported success. Please

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

Am 26.04.2018 um 17:30 schrieb Ben Greear: On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote: 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

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

On 04/26/2018 01:21 PM, Sebastian Gottschall wrote: Am 26.04.2018 um 17:30 schrieb Ben Greear: On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall current handling of peer_bw_rxnss_override parameter is based on guessing the VHT160/8080