[PATCH v2] iwlwifi: allow memory debug TLV to specify the memory type

From: Johannes Berg Due to some new features and changes, the firmware file will now specify what type of memory to dump, in upper 8 bits of the type field of the TLV. Parse it (types we don't understand are errors) and teach the code to dump periphery memory.

[PATCH v2] iwlwifi: mvm: use mvm_disable_queue instead of sharing logic

From: Sara Sharon When removing inactive queue - use the central disable queue function. This is needed due to a000 changes to come, but is a proper cleanup anyway. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho

[PATCH v2] iwlwifi: mvm: change iwl_mvm_tx_csum to return value

From: Sara Sharon Currently the function changes the TX cmd itself. Make it more generic by returning a value, as preperation to the new TX cmd. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho --- In v2: * Fix

Re: [PATCH] NFC: remove TI nfcwilink driver

Hi Rob, > It appears that TI WiLink devices including NFC (WL185x/WL189x) never > shipped. The only information I found were announcements in Feb > 2012 about the parts. There's been no activity on this driver besided > common changes since initially added in Jan 2012. There's also no in > users

[PATCH] nl80211: Fix mesh HT operation check

commit 9757235f451c27deaa88925399f070ff6fcea832 ('nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value') missed to mask a flag when replacing FILL_IN_MESH_PARAM_IF_SET with checking codes. This could drop the received HT operation value when called by nl80211_update_mesh_config().

[PATCH] NFC: remove TI nfcwilink driver

It appears that TI WiLink devices including NFC (WL185x/WL189x) never shipped. The only information I found were announcements in Feb 2012 about the parts. There's been no activity on this driver besided common changes since initially added in Jan 2012. There's also no in users that instantiate

RE: [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

> -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de Vasanthakumar Thiagarajan > Envoyé : mercredi 25 janvier 2017 12:31 > À : johan...@sipsolutions.net > Cc : linux-wireless@vger.kernel.org; Vasanthakumar

[PATCH 4/4] ath9k: fix race condition in enabling/disabling IRQs

The code currently relies on refcounting to disable IRQs from within the IRQ handler and re-enabling them again after the tasklet has run. However, due to race conditions sometimes the IRQ handler might be called twice, or the tasklet may not run at all (if interrupted in the middle of a reset).

[PATCH 1/4] ath9k: rename tx_complete_work to hw_check_work

Also include common MAC alive check. This should make the hang checks more reliable for modes where beacons are not sent and is used as a starting point for further hang check improvements Signed-off-by: Felix Fietkau --- drivers/net/wireless/ath/ath9k/ath9k.h | 6 ++---

[PATCH 2/4] ath9k_hw: check if the chip failed to wake up

In an RFC patch, Sven Eckelmann and Simon Wunderlich reported: "QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a state in which a read of AR_CFG always returns 0xdeadbeef. This should not happen when when the power_mode of the device is ATH9K_PM_AWAKE." Include the check for

[PATCH 3/4] ath9k: check for deaf rx path state

Various chips occasionally run into a state where the tx path still appears to be working normally, but the rx path is deaf. There is no known register signature to check for this state explicitly, so use the lack of rx interrupts as an indicator. This detection is prone to false positives,

[PATCH] wireless: radiotap: rewrite the radiotap header file

From: Johannes Berg The header file has grown a lot of #define's etc, but they are nicer as enums, so rewrite the file from the documentation as such. Signed-off-by: Johannes Berg --- include/net/ieee80211_radiotap.h | 444

[PATCH v2] wireless: radiotap: rewrite the radiotap header file

From: Johannes Berg The header file has grown a lot of #define's etc, but they are nicer as enums, so rewrite the file from the documentation as such. Signed-off-by: Johannes Berg --- include/net/ieee80211_radiotap.h | 455

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

Kalle Valo writes: > Mohammed Shafi Shajakhan writes: > >> From: Mohammed Shafi Shajakhan >> >> This fixes the below crash when ath10k probe firmware fails, >> NAPI polling tries to access a rx ring resource which

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

Mohammed Shafi Shajakhan writes: > From: Mohammed Shafi Shajakhan > > This fixes the below crash when ath10k probe firmware fails, > NAPI polling tries to access a rx ring resource which was never > allocated, fix this by disabling NAPI

[PATCH v4 1/5] mac80211: Pass new RSSI level in CQM RSSI notification

Extend ieee80211_cqm_rssi_notify with a rssi_level parameter so that this information can be passed to netlink clients in the next patch, if available. Most drivers will have this value at hand. wl1251 receives events from the firmware that only tell it whether latest measurement is above or

[PATCH v4 4/5] mac80211: Add set_cqm_rssi_range_config

Support .set_cqm_rssi_range_config if the beacons are available for processing in mac80211. There's no reason that this couldn't be offloaded by mac80211-based drivers but there's no driver method for that added in this patch as I don't have the hardware. Signed-off-by: Andrew Zaborowski

[PATCH v4 5/5] wireless: Set NL80211_EXT_FEATURE_CQM_RSSI_LIST in multiple drivers

Set the NL80211_EXT_FEATURE_CQM_RSSI_LIST wiphy extended feature wholesale in all mac80211-based drivers that do not set the IEEE80211_VIF_BEACON_FILTER flags on their interfaces. mac80211 will be processing supplied RSSI values in ieee80211_rx_mgmt_beacon and will detect when the thresholds set

[PATCH v4 2/5] cfg80211: Pass new RSSI level in CQM RSSI notification

Update the drivers to pass the RSSI level as a cfg80211_cqm_rssi_notify parameter and pass this value to userspace in a new nl80211 attribute. This helps both userspace and also helps in the implementation of the multiple RSSI thresholds CQM mechanism. Note for marvell/mwifiex I pass 0 for the

[RFC 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain

Sharing DFS channel state across multiple wiphys (radios) could be useful with multiple radios on the system. When one radio completes CAC and marks the channel available another radio can use this information and start beaconing without really doing CAC. Whenever there is a state change in DFS

[RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

For non-ETSI regulatory domain, CAC result on DFS channel may not be valid once moving out of that channel (as done during remain-on-channel, scannning and off-channel tx). Running CAC on an operating DFS channel after every off-channel operation will only add complexity and disturb the current

[RFC 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

DFS requirement for ETSI domain (section 4.7.1.4 in ETSI EN 301 893 V1.8.1) is the only one which explicitly states that once DFS channel is marked as available afer the CAC, this channel will remain in available state even moving to a different operating channel. But the same is not explicitly

[RFC 0/3] Pre-CAC and sharing DFS state across multiple radios

Currently irrespective of dfs domain and radar detection activity pre-CAC results for a wiphy are retained till the wiphy is detroyed. This may not be preferred in non-ETSI dfs domain where pre-CAC is not explicitly mentioned in the respective DFS requirement spec. This patch set modifies the

Re: [PATCH 2/2] mac80211: use accessor functions to set sta->_flags

On Wed, 2017-01-25 at 09:55 +0100, Amadeusz Slawinski wrote: > And yes I did. Somehow managed to ignore those warnings though, sorry > about that. :) That was intentional so nobody changing mac80211 in the future will accidentally play with those flags through the normal accessors. > Rechecked

Re: [PATCH 2/2] mac80211: use accessor functions to set sta->_flags

And yes I did. Somehow managed to ignore those warnings though, sorry about that. Rechecked with just first patch and it should still be good. Please ignore this one ;) On 24 January 2017 at 16:44, Johannes Berg wrote: > On Tue, 2017-01-24 at 16:42 +0100, Amadeusz