Re: [PATCH] mac80211: prevent skb/txq mismatch

> > What I don't understand - and you haven't really described - is how > > the changes fix it? Could you resend with a paragraph added that > > explains that? > > "Since downgrading unicast traffic to vif->txq must not be done > there's no txq to put a frame on if sta->uploaded is false.

[PATCH] mac80211: fix documentation warnings

From: Johannes Berg For a few restructured text warnings in mac80211, making the documentation warning-free (for now). Again, this required adding trailing whitespace to keep multiple paragraphs in a parameter description together. Signed-off-by: Johannes Berg

Re: [PATCH] mac80211: initialize SMPS field in HT capabilities

On Fri, 2017-01-13 at 09:54 +0100, Felix Fietkau wrote: > > Additionally, ath10k appears to be setting this to > > WLAN_HT_CAP_SM_PS_DYNAMIC already, so apparently it's expecting > > something to happen with that value? Is it really correct then to > > be overwriting it? > > Actually, that code

Re: [PATCH v2] mac80211: initialize SMPS field in HT capabilities

On Fri, 2017-01-13 at 11:28 +0100, Felix Fietkau wrote: > ibss and mesh modes copy the ht capabilites from the band without > overriding the SMPS state. Unfortunately the default value 0 for the > SMPS field means static SMPS instead of disabled. > > This results in HT ibss and mesh setups using

[PATCH 4.10 fix V2] Revert "bcma: init serial console directly from ChipCommon code"

From: Rafał Miłecki This reverts commit 4c81acab3816 ("bcma: init serial console directly from ChipCommon code") as it broke IRQ assignment. Getting IRQ with bcma_core_irq helper on SoC requires MIPS core to be set. It happens *after* ChipCommon initialization so we can't do

[RFC 4/5] cfg80211: add request id to cfg80211_sched_scan_results() api

Have proper request id filled in the SCHED_SCAN_RESULTS notification toward user-space by having the driver provide it through the api. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin

[RFC 1/5] nl80211: allow multiple active scheduled scan requests

This patch implements the idea to have multiple scheduled scan requests running concurrently. It mainly illustrates how to deal with the incoming request from user-space in terms of backward compatibility. In order to use multiple scheduled scans user-space needs to provide a flag attribute

Re: [1/2] ath10k: add accounting for the extended peer statistics

Christian Lamparter wrote: > The 10.4 firmware adds extended peer information to the > firmware's statistics payload. This additional info is > stored as a separate data field and the elements are > stored in their own "peers_extd" list. > > These elements can pile up in

Re: ath10k: Fix wifi connectivity and warning in Rx with channel 169

Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > In countries where basic operation of channel 169 is allowed, > this fixes the below WARN_ON_ONCE in Rx and fixes the station > connectivity failure in channel 169 as the

[PATCH 5/6] iwlwifi: mvm: fix PS-Poll enablement

From: Emmanuel Grumbach We added the uAPSD enabled ACs and that made the firmware choose to pull frames with uAPSD trigger frames instead of PS-Poll. Fix that. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho

[RFC 5/5] cfg80211: add request id in cfg80211_sched_scan_stopped{,_rtnl}() api

Allow driver to indicate which scheduled scan request is being aborted by providing the request id. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by:

[RFC 3/5] cfg80211: add request id parameter to .sched_scan_stop() signature

For multiple scheduled scan support the driver needs to know which scheduled scan request is being stopped. Pass the request id in the .sched_scan_stop() callback. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts

[RFC 0/5] cfg80211: support multiple scheduled scans

After sending out the initial RFC for multiple scheduled scan support [1] here a series that deal with it all (I hope) so including events and the driver function call apis. It is applies to the master branch of the mac80211-next repository. Arend van Spriel (5): nl80211: allow multiple active

[RFC 2/5] nl80211: include request id in scheduled scan event messages

Include the request id in the event messages so user-space knows which scan the event relates to. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by:

Re: [RFC 4/5] cfg80211: add request id to cfg80211_sched_scan_results() api

On 13-1-2017 13:47, Arend van Spriel wrote: > Have proper request id filled in the SCHED_SCAN_RESULTS notification > toward user-space by having the driver provide it through the api. > > Reviewed-by: Hante Meuleman > Reviewed-by: Pieter-Paul Giesberts

Re: ath10k: Fix Tx legacy rate reporting

Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > Tx legacy rate is reported 10 fold, as below > > iw dev wlan#N station dump | grep "tx bitrate" > tx bitrate: 240.0 MBit/s > > This is because by mistake we

Re: linux-next: build warning after merge of the wireless-drivers-next tree

Stephen Rothwell writes: > Hi all, > > After merging the wireless-drivers-next tree, today's linux-next build > (x86_64 allmodconfig) produced this warning: > > drivers/net/wireless/marvell/mwifiex/pcie.c: In function > 'mwifiex_pcie_remove': >

Re: [PATCH] mac80211: fix documentation warnings

Am 13.01.2017 um 11:12 schrieb Johannes Berg : > From: Johannes Berg > > For a few restructured text warnings in mac80211, making the > documentation warning-free (for now). Again, this required > adding trailing whitespace to keep multiple

Re: ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS

Christian Lamparter wrote: > Currently, the common ath9k_common module needs to have a > dependency on RELAY and DEBUG_FS in order to built. This > is usually not a problem. But for RAM and FLASH starved > AR71XX devices, every little bit counts. > > This patch adds a

pull-request: mac80211 2017-01-13

Hi Dave, Here's another update for the current cycle. Some of those patches have been sitting in our tree and I haven't been pulling them out quickly enough - will try to do better... Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit

[PATCH v2] mac80211: prevent skb/txq mismatch

Station structure is considered as not uploaded (to driver) until drv_sta_state() finishes. This call is however done after the structure is attached to mac80211 internal lists and hashes. This means mac80211 can lookup (and use) station structure before it is uploaded to a driver. If this

[PATCH 3/6] iwlwifi: fix double hyphen in MODULE_FIRMWARE for 8000

From: Jürg Billeter There is only a single hyphen between iwlwifi-8000C and the API version in the firmware filename. Fixes: e1ba684f762b ("iwlwifi: 8000: fix MODULE_FIRMWARE input") Signed-off-by: Jürg Billeter Signed-off-by: Luca Coelho

[PATCH 1/6] iwlwifi: mvm: don't restart HW if suspend fails with unified image

From: Luca Coelho For unified images, we shouldn't restart the HW if suspend fails. The only reason for restarting the HW with non-unified images is to go back to the D0 image. Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend")

[PATCH 6/6] iwlwifi: mvm: Use aux queue for offchannel frames in dqa

From: Beni Lev Since offchannel activity doesn't always require a BSS, e.g. ANQP sessions, offchannel frames should not use the BSS queue, because it might not be initialized. Use the auxilary queue instead. Fixes: e3118ad74d7e ("iwlwifi: mvm: support tdls in dqa mode")

[PATCH 2/6] iwlwifi: mvm: properly check for transport data in dump

From: Johannes Berg When copying from vmalloc'ed memory to the SG list, don't crash if the transport didn't provide any data. Fixes: 7e62a699aafb ("iwlwifi: mvm: use dev_coredumpsg()") Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho

[PATCH 0/6] iwlwifi: updates intended for v4.10 2017-01-13

From: Luca Coelho Hi, Here are a few fixes that I intend to send for v4.10: * fix suspend failure with unified firmware images * fix a potential crash when dumping debug data * fix a couple of mistakes in FW names exported by the modules * small fix for PS-Poll

[PATCH 4/6] iwlwifi: fix MODULE_FIRMWARE for 6030

From: Jürg Billeter IWL6000G2B_UCODE_API_MAX is not defined. ucode_api_max of IWL_DEVICE_6030 uses IWL6000G2_UCODE_API_MAX. Use this also for MODULE_FIRMWARE. Fixes: 9d9b21d1b616 ("iwlwifi: remove IWL_*_UCODE_API_OK") Signed-off-by: Jürg Billeter Signed-off-by:

Re: [PATCH] mac80211: fix documentation warnings

On Fri, 2017-01-13 at 13:43 +0100, Markus Heiser wrote: > does it make live easier when we use in-line member comments: > >  https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#in- > line-member-documentation-comments > > and place the entire list in a literalblock?  Ah yes, I

Re: [v2,1/2] ath10k: refactor ath10k_peer_assoc_h_phymode()

Kalle Valo wrote: > When adding VHT160 support to ath10k_peer_assoc_h_phymode() the VHT mode > selection code becomes too complex. Simplify it by refactoring the vht part to > a separate function. > > Signed-off-by: Kalle Valo 2 patches applied

Re: [PATCH v2] mac80211: prevent skb/txq mismatch

On Fri, 2017-01-13 at 13:32 +0100, Michal Kazior wrote: > Station structure is considered as not uploaded > (to driver) until drv_sta_state() finishes. This > call is however done after the structure is > attached to mac80211 internal lists and hashes. > This means mac80211 can lookup (and use)

Re: [PATCH] rtlwifi: rtl8192ee: New firmware from Realtek

On Sat, Dec 17, 2016 at 12:50:54PM -0600, Larry Finger wrote: > -Info: Taken from Realtek version > rtl_92ce_92se_92de_8723ae_88ee_8723be_92ee_linux_mac80211_0017.1224.2013 > +Info: Initial version taken from Realtek version > + >

Re: [PATCH] linux-firmware: mwlwifi: update 88W8864 firmware.

On Wed, Dec 21, 2016 at 06:53:19AM +, David Lin wrote: > Release Version: 7.2.9.26. > > Signed-off-by: David Lin > --- > mwlwifi/88W8864.bin | Bin 116356 -> 118776 bytes > 1 file changed, 0 insertions(+), 0 deletions(-) > Please include an update for WHENCE. regards,

[PATCH] mwifiex: fix uninitialized variable access in pcie_remove

Checking the firmware status from PCIe register only works if the register is available, otherwise we end up with random behavior: drivers/net/wireless/marvell/mwifiex/pcie.c: In function 'mwifiex_pcie_remove': drivers/net/wireless/marvell/mwifiex/pcie.c:585:5: error: 'fw_status' may be used

Re: [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

Hi Kalle, On Fri, Jan 13, 2017 at 12:46:56PM +0200, Kalle Valo wrote: > Daniel Golle writes: > > ... > > Please review and comment, so we can get those patches merged! > > No pull requests, please. Instead send these as patches, easier to > review and actually also easier

Re: [PATCH] rtlwifi: rtl8192ee: New firmware from Realtek

On 01/13/2017 09:03 AM, Kyle McMartin wrote: On Sat, Dec 17, 2016 at 12:50:54PM -0600, Larry Finger wrote: -Info: Taken from Realtek version rtl_92ce_92se_92de_8723ae_88ee_8723be_92ee_linux_mac80211_0017.1224.2013 +Info: Initial version taken from Realtek version +

Re: [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

> The advantage of pull requests is that author information can be > preserved more easily. Running git format-patch results in most > patches > having wrong SMTP sender information due to the assumption that the > patch author is the same person also submitting the patch. > So in practise, this

<    1   2