Re: pull-request: mac80211 2016-09-13

From: Johannes Berg Date: Tue, 13 Sep 2016 22:03:23 +0200 > We found a few more issues, I'm sending you small fixes here. The diffstat > would be even shorter, but one of Felix's patches has to move about 30 lines > of code, which makes it seem much bigger than it

Re: pull-request: iwlwifi-next 2016-09-15

Huomenta Kalle, The kbuild bot scripts reported a compilation error, because DMA_ERROR_CODE is not defined in some platforms (e.g. alpha). So please drop this pull request.  I'll fix the problem and send a new version. --8<-- All errors (new ones prefixed by >>):    In file

Re: [PATCH] mwifiex: fix null pointer deference when adapter is null

kbuild test robot <l...@intel.com> writes: > url: > https://github.com/0day-ci/linux/commits/Colin-King/mwifiex-fix-null-pointer-deference-when-adapter-is-null/20160915-231625 > base: > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git

Re: brcmfmac43430-sdio.bin in linux-firmware

Hi Arend, On Wed, Aug 24, 2016 at 4:22 PM, Arend Van Spriel wrote: > I could, but this is handled by Cypress now. I have asked for firmware > release tag so I can release it. I see brcmfmac43430-sdio.bin in linux-firmware git tree now. Thanks a lot for your help!

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

On Thu, 2016-09-15 at 10:59 -0700, Ben Greear wrote: > On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote: > > On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote: > > > On 09/15/2016 07:06 AM, Valo, Kalle wrote: > > > > Ben Greear writes: > > > > > > > > > On 09/14/2016

[PATCH 20/25] iwlwifi: mvm: bump max API to 26

From: Emmanuel Grumbach The driver now support version 26 of the firmware APIs. Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 ++--

[PATCH 12/25] iwlwifi: pcie: Configure shared interrupt vector in MSIX mode

From: Haim Dreyfuss In case the OS provides fewer interrupts than requested, different causes will share the same interrupt vector as follow: 1.One interrupt less: non rx causes shared with FBQ. 2.Two interrupts less: non rx causes shared with FBQ and RSS. 3.More than

[PATCH 11/25] iwlwifi: mvm: support new BA notification response

From: Sara Sharon Support new format. TX response will not be sent anymore, so all needed data is in the BA response. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho ---

[PATCH 13/25] iwlwifi: mvm: fix pending frames tracking on tx resp

From: Liad Kaufman In iwl_mvm_rx_tx_cmd_single(), when checking if a given TID is aggregated, the driver doesn't check whether or not the queue itself can be aggregated. For example, a management queue might be marked as aggregated if TID 0 is aggregated on a (different)

[PATCH 21/25] iwlwifi: pcie: replace possible_cpus() with online_cpus() in MSIX mode

From: Haim Dreyfuss In MSIX mode the number of irq depends on the number of possible cpus existing on the host. This cause to bug in case there are offline cores. Take into account only the online CPUs instead. Also save it in temporary variable. Fixes: commit

[PATCH 22/25] iwlwifi: unify iwl_get_ucode_image() implementations

From: Sharon Dvir Avoid multiple implementations. Signed-off-by: Sharon Dvir Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/dvm/ucode.c | 11 +-- drivers/net/wireless/intel/iwlwifi/iwl-fw.h

[PATCH 18/25] iwlwifi: mvm: use setup_timer instead of init_timer and data fields

From: Wei Yongjun Use setup_timer function instead of initializing timer with the function and data fields Signed-off-by: Wei Yongjun Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho

[PATCH 17/25] iwlwifi: add the new 8275 series

From: Oren Givon Add a new config struct for the new 8275 series and add the first PCI ID for it. Signed-off-by: Oren Givon Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 11 +++

[PATCH 25/25] iwlwifi: mvm: tighten BAID range check

From: Johannes Berg As pointed out by smatch, checking the BAID for just >= INVALID is a bad idea since only 32 (IWL_MAX_BAID) actually exist. Check the range for that and print invalid ones in the warning. Signed-off-by: Johannes Berg

[PATCH 23/25] iwlwifi: mvm: make RSS RX more robust

From: Johannes Berg If the firmware ever decides to send any new/more notifications to the RSS queues, the driver would currently try to interpret those as REPLY_RX_MPDU_CMD and, if the notification was small, access invalid memory. Prevent that by checking for

[PATCH 15/25] iwlwifi: pcie: Set affinity mask for rx interrupt vectors per cpu

From: Haim Dreyfuss In order to utilize the host's CPUs in the most efficient way we bind each rx interrupt vector to each CPU on the host. Each rx interrupt is prioritized to execute only on the designated CPU rather than any CPU. Processor affinity takes advantage of

[PATCH 19/25] iwlwifi: pcie: change indentation of iwl_pcie_set_interrupt_capa()

From: Sara Sharon Function is very indented. Go to msi section if needed to avoid it and by that make the code more readable. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho ---

[PATCH 14/25] iwlwifi: mvm: free reserved queue on STA removal

From: Liad Kaufman When a STA is removed in DQA mode, if no traffic went through its reserved queue, the txq continues to be marked as reserved and no STA can use it. Make sure that in such a case the reserved queue is marked as free when the STA is removed. Fixes:

[PATCH 16/25] iwlwifi: add the new 9560 series

From: Oren Givon Add a new config struct for the new 9560 series and add the 4 new PCI IDs for it. Signed-off-by: Oren Givon Signed-off-by: Luca Coelho --- drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 11 +++

[PATCH 10/25] iwlwifi: pcie: merge iwl_queue and iwl_txq

From: Sara Sharon The original intent was to have the general iwl_queue shared between RX and TX queues, but it is not the actual status. Since it is not shared with any struct but iwl_txq, it adds unnecessary complexity. Merge those structs. Signed-off-by: Sara Sharon

[PATCH 08/25] iwlwifi: pcie: assign and access a000 TFD & TBs

From: Sara Sharon Previous patch introduced the new formats. This patch allocates the new structures and adjusts code accordingly. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho ---

[PATCH 07/25] iwlwifi: introduce trans API to get byte count table

From: Sara Sharon In future HW the byte count table address will be configured by ucode per queue. Add API to expose the byte count table to the opmode Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho ---

[PATCH 05/25] iwlwifi: mvm: remove dump of locked registers

From: Sara Sharon Firmware may lock those registers for access. This results in 9000 devices with a bus stall and an endless loop of 0x5a5a5a. Don't dump those registers. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho

[PATCH 03/25] iwlwifi: fix semicolon.cocci warnings

From: kbuild test robot drivers/net/wireless/intel/iwlwifi/iwl-io.c:243:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Sara Sharon Signed-off-by: Fengguang Wu

[PATCH 06/25] iwlwifi: mvm: support new shared memory config API

From: Sara Sharon In a000 devices we have 15 fifos, so in the shared memory config the number of tx fifos in the array was changed accordingly. As it is in the middle of the struct, the parsing code needs to be duplicated. To minimize the duplication, do not save variables

[PATCH 04/25] iwlwifi: pcie: introduce new tfd and tb formats

From: Sara Sharon New hardware supports bigger TFDs and TBs. Introduce the new formats and adjust defines and code relying on old format. Changing the actual TFD allocation is trickier and deferred to the next patch. Signed-off-by: Sara Sharon

[PATCH 01/25] iwlwifi: mvm: call a different txq_enable function

From: Sara Sharon Since the SCD_QUEUE_CFG command was introduced the driver calls iwl_trans_txq_enable_cfg() with a NULL for scd_cfg parameter. This makes the transport avoid writing to the SCD pointers, since it can cause races with firmware, which is also accessing the

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

On 09/15/2016 10:59 AM, Ben Greear wrote: On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote: I have other patches that remember the last 100 or so firmware log messages from the kernel and provide that in a binary dump image when firmware crashes. This is indeed very useful. But, when

pull-request: iwlwifi-next 2016-09-15

Hi Kalle, One more pull request intended for 4.9.  There are changes all over, mostly new hardware support, DQA, multiqueue MSIx work, and a bunch of cleanups and improvements.  More details in the tag description. Let me know if everything's fine (or not). :) Luca. The following changes

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote: On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote: On 09/15/2016 07:06 AM, Valo, Kalle wrote: Ben Greear writes: On 09/14/2016 07:18 AM, Valo, Kalle wrote: gree...@candelatech.com writes: From: Ben Greear

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote: > On 09/15/2016 07:06 AM, Valo, Kalle wrote: > > Ben Greear writes: > > > > > On 09/14/2016 07:18 AM, Valo, Kalle wrote: > > > > gree...@candelatech.com writes: > > > > > > > > > From: Ben Greear

Re: [PATCH] mwifiex: fix memory leak on regd when chan is zero

On 15/09/16 18:10, Kalle Valo wrote: > Colin King writes: > >> From: Colin Ian King >> >> When chan is zero mwifiex_create_custom_regdomain does not kfree >> regd and we have a memory leak. Fix this by freeing regd before >> the return. >> >>

Re: [PATCH] mwifiex: fix memory leak on regd when chan is zero

Colin King writes: > From: Colin Ian King > > When chan is zero mwifiex_create_custom_regdomain does not kfree > regd and we have a memory leak. Fix this by freeing regd before > the return. > > Signed-off-by: Colin Ian King

Re: [PATCH] mwifiex: fix null pointer deference when adapter is null

Hi Colin, [auto build test WARNING on wireless-drivers-next/master] [also build test WARNING on next-20160915] [cannot apply to v4.8-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --b

[PATCH] mwifiex: fix memory leak on regd when chan is zero

From: Colin Ian King When chan is zero mwifiex_create_custom_regdomain does not kfree regd and we have a memory leak. Fix this by freeing regd before the return. Signed-off-by: Colin Ian King ---

[PATCH] iwlwifi: mvm: update TX queue before making a copy of the skb

From: Beni Lev Off-channel action frames (such as ANQP frames) must be sent either on the AUX queue or on the offchannel queue, otherwise the firmware will cause a SYSASSERT. In the current implementation, the queue to be used is correctly set in the original skb, but this

pull-request: iwlwifi 2016-09-15

Hi Kalle, Here is one more patch intended for 4.8.  It's small and low risk, just moving some lines of code around, to prevent a firmware crash in certain situations. Let me know if everything's fine (or not). :) Luca. The following changes since commit

Re: Using ath5k/ath9k radio for constant-tx noise source.

On 09/15/2016 06:26 AM, Bob Copeland wrote: On Wed, Sep 14, 2016 at 05:22:46PM -0700, Ben Greear wrote: On 08/20/2015 08:11 AM, Zefir Kurtisi wrote: On 08/19/2015 09:07 PM, Ben Greear wrote: I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be wrong) and it has the

Re: Using ath5k/ath9k radio for constant-tx noise source.

On 09/15/2016 08:28 AM, Zefir Kurtisi wrote: Hi Ben, On 09/15/2016 02:22 AM, Ben Greear wrote: On 08/20/2015 08:11 AM, Zefir Kurtisi wrote: On 08/19/2015 09:07 PM, Ben Greear wrote: I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be wrong) and it has the ability to

Re: Using ath5k/ath9k radio for constant-tx noise source.

Hi Ben, On 09/15/2016 02:22 AM, Ben Greear wrote: > On 08/20/2015 08:11 AM, Zefir Kurtisi wrote: >> On 08/19/2015 09:07 PM, Ben Greear wrote: >>> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could >>> be >>> wrong) >>> and it has the ability to do a constant transmit of

wireless.wiki.kernel.org: lingering status of http://linuxwireless.org/en/users/Drivers/wl12xx/calibrator/

Dear Mr. Berg, since we are working with TI WL12xx hardware, I keep a reference on http://linuxwireless.org/en/users/Drivers/wl12xx/calibrator/ , where it now says: "NOTE: this page is for archival only, see the note at the end of the page." "This is a static dump of the old wiki, taken after

Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors

On 09/15/2016 06:59 AM, Valo, Kalle wrote: Ben Greear writes: On 09/14/2016 07:07 AM, Valo, Kalle wrote: gree...@candelatech.com writes: From: Ben Greear When firmware crashes, stack can continue to send packets for a bit, and existing

Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.

On 09/15/2016 07:02 AM, Valo, Kalle wrote: Ben Greear writes: On 09/14/2016 07:12 AM, Valo, Kalle wrote: gree...@candelatech.com writes: From: Ben Greear There are not many of these messages producted by the firmware, but they are

[PATCH] cfg80211: add helper to find an IE that matches a byte-array

From: Luca Coelho There are a few places where an IE that matches not only the EID, but also other bytes inside the element, needs to be found. To simplify that and reduce the amount of similar code, implement a new helper function to match the EID and an extra array

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

On 09/15/2016 07:06 AM, Valo, Kalle wrote: Ben Greear writes: On 09/14/2016 07:18 AM, Valo, Kalle wrote: gree...@candelatech.com writes: From: Ben Greear This allows user-space tools to decode debug-log messages by parsing dmesg or

Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.

On 09/15/2016 07:19 AM, Valo, Kalle wrote: Ben Greear writes: On 09/14/2016 07:06 AM, Valo, Kalle wrote: gree...@candelatech.com writes: From: Ben Greear Using debugfs. More convenient than module options in some cases. Signed-off-by:

Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG

On 09/15/2016 07:12 AM, Valo, Kalle wrote: Ben Greear writes: On 09/14/2016 07:19 AM, Valo, Kalle wrote: gree...@candelatech.com writes: From: Ben Greear Helps keep messages off of (serial) console when that is desired. Signed-off-by:

pull-request: wireless-drivers-next 2016-09-15

Hi Dave, here's the first pull request for 4.9. The ones I want to point out are the FIELD_PREP() and FIELD_GET() macros added to bitfield.h, which are reviewed by Linus, and make it possible to remove util.h from mt7601u. Also we have new HW support to various drivers and other smaller

Re: [PATCH v2 15/21] ath10k: support CT firmware flag.

On 09/15/2016 07:15 AM, Valo, Kalle wrote: Ben Greear writes: On 09/14/2016 07:30 AM, Valo, Kalle wrote: gree...@candelatech.com writes: From: Ben Greear Add placeholder so CT firmware can more easily co-exist with upstream kernel. CT

brcmfmac MAC address change delay and 500ms down delay

Hi, While refining NetworkManager's MAC address randomization behavior we came across two issues with brcmfmac: 1) when changing the MAC address, the driver schedules work for the new change and returns success, but doesn't actually change the MAC until the work is scheduled.  Because it returns

[PATCH] ath10k: Provide provision to get Transmit Power Control stats for 10.4

From: Maharaja Kennadyrajan This patch helps to get the TPC stats for 10.4 fw variants. Signed-off-by: Maharaja Kennadyrajan --- drivers/net/wireless/ath/ath10k/wmi.c |4 1 file changed, 4 insertions(+) diff --git

Re: AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs

On 09/15/2016 01:48 PM, Rafał Miłecki wrote: On 09/14/2016 08:28 PM, Arend Van Spriel wrote: It would be great to have a timestamp for these skb when they arrive in brcmfmac or transferred to firmware (or both). You ask and you have it :) I saved kernel's local time and printed it the same

Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.

Ben Greear writes: > On 09/14/2016 07:06 AM, Valo, Kalle wrote: >> gree...@candelatech.com writes: >> >>> From: Ben Greear >>> >>> Using debugfs. More convenient than module options >>> in some cases. >>> >>> Signed-off-by: Ben Greear

Re: [PATCH v2 15/21] ath10k: support CT firmware flag.

Ben Greear writes: > On 09/14/2016 07:30 AM, Valo, Kalle wrote: >> gree...@candelatech.com writes: >> >>> From: Ben Greear >>> >>> Add placeholder so CT firmware can more easily co-exist with upstream >>> kernel. CT firmware should be backwards

Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG

Ben Greear writes: > On 09/14/2016 07:19 AM, Valo, Kalle wrote: >> gree...@candelatech.com writes: >> >>> From: Ben Greear >>> >>> Helps keep messages off of (serial) console when >>> that is desired. >>> >>> Signed-off-by: Ben Greear

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

Ben Greear writes: > On 09/14/2016 07:18 AM, Valo, Kalle wrote: >> gree...@candelatech.com writes: >> >>> From: Ben Greear >>> >>> This allows user-space tools to decode debug-log >>> messages by parsing dmesg or /var/log/messages. >>> >>>

Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.

Ben Greear writes: > On 09/14/2016 07:12 AM, Valo, Kalle wrote: >> gree...@candelatech.com writes: >> >>> From: Ben Greear >>> >>> There are not many of these messages producted by the >>> firmware, but they are generally fairly useful, so print

Re: [PATCH] brcm: add firmware for BCM43430 802.11n chipset

On Wed, Sep 14, 2016 at 11:30:33AM +0200, Arend Van Spriel wrote: > On 14-9-2016 11:04, Arend van Spriel wrote: > > This patch releases firmware for the BCM43430 and BCM43438 chipset. The > > latter is found on the Raspberry Pi 3. > > > > Signed-off-by: Arend van Spriel

Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors

Ben Greear writes: > On 09/14/2016 07:07 AM, Valo, Kalle wrote: >> gree...@candelatech.com writes: >> >>> From: Ben Greear >>> >>> When firmware crashes, stack can continue to send packets >>> for a bit, and existing code was spamming logs. >>>

Re: [PATCH] mwifiex: fix null pointer deference when adapter is null

Hi All, On Thu, Sep 15, 2016 at 11:42 PM, Colin King wrote: > From: Colin Ian King > > If adapter is null the error exit path in mwifiex_shutdown_sw is > to down the semaphore sem and print some debug via mwifiex_dbg. > However, passing a NULL

[PATCH] mwifiex: fix null pointer deference when adapter is null

From: Colin Ian King If adapter is null the error exit path in mwifiex_shutdown_sw is to down the semaphore sem and print some debug via mwifiex_dbg. However, passing a NULL adapter to mwifiex_dbg causes a null pointer deference when accessing adapter->dev. This fix

[PATCH 2/2] mac80211_hwsim: statically initialize hwsim_radios list

From: Johannes Berg There's no need to initialize at runtime, when the static declaration macro can just be used instead, so do that. Signed-off-by: Johannes Berg --- drivers/net/wireless/mac80211_hwsim.c | 3 +-- 1 file changed, 1

[PATCH 1/2] mac80211: allow to support AP_LINK_PS when the set_tim is still needed

From: Emmanuel Grumbach In 46fa38e84b656f80edf83d21144221b0cad18d61, Johannes allowed to use mac80211's code for handling stations that go to PS or send PS-Poll / uAPSD trigger frames for devices that enable RSS. This means that mac80211 doesn't look at frames

Re: Using ath5k/ath9k radio for constant-tx noise source.

On Wed, Sep 14, 2016 at 05:22:46PM -0700, Ben Greear wrote: > On 08/20/2015 08:11 AM, Zefir Kurtisi wrote: > >On 08/19/2015 09:07 PM, Ben Greear wrote: > >>I have a commercial AP that is using a CM9 ath5k radio (evidently, I could > >>be wrong) > >>and it has the ability to do a constant transmit

[PATCH] brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

commit ded89912156b1a47d940a0c954c43afbabd0c42c upstream User-space can choose to omit NL80211_ATTR_SSID and only provide raw IE TLV data. When doing so it can provide SSID IE with length exceeding the allowed size. The driver further processes this IE copying it into a local variable without

[PATCH] brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

commit ded89912156b1a47d940a0c954c43afbabd0c42c upstream User-space can choose to omit NL80211_ATTR_SSID and only provide raw IE TLV data. When doing so it can provide SSID IE with length exceeding the allowed size. The driver further processes this IE copying it into a local variable without

Re: brcmf_txfinalize misses 802.1x packet leading to infinite WARNINGs

On 15 September 2016 at 11:20, Hante Meuleman wrote: > Thank you for the extensive debugging. We are looking into this. Arend wrote > yesterday to ask for detailed timing on wen eapol is inserted. We want this > so we can increase the timeout. This is not a "nice"

Re: [PATCH v5] cfg80211: Add support to configure a beacon data rate

On Thu, 2016-09-15 at 09:18 +, Undekari, Sunil Dutt wrote: > > > > I'm even willing to add it myself - should we just have three > > feature flags? > I guess , Yes. > ok, I'll add those. johannes

RE: brcmf_txfinalize misses 802.1x packet leading to infinite WARNINGs

Hi Rafal, Thank you for the extensive debugging. We are looking into this. Arend wrote yesterday to ask for detailed timing on wen eapol is inserted. We want this so we can increase the timeout. This is not a "nice" way to solve the problem, and it should be solved in firmware, but in the

RE: [PATCH v5] cfg80211: Add support to configure a beacon data rate

> I'm even willing to add it myself - should we just have three feature flags? I guess , Yes. Regards, Sunil -Original Message- From: Johannes Berg [mailto:johan...@sipsolutions.net] Sent: Thursday, September 15, 2016 2:34 PM To: Undekari, Sunil Dutt ; Kushwaha,

Re: [PATCH v5] cfg80211: Add support to configure a beacon data rate

On Thu, 2016-09-15 at 09:00 +, Undekari, Sunil Dutt wrote: > > > > shouldn't we have some feature flags here to indicate that the > > driver actually supports this? > Yes. Can you please accept this with a new commit.  > I'm even willing to add it myself - should we just have three feature

RE: [PATCH v5] cfg80211: Add support to configure a beacon data rate

> shouldn't we have some feature flags here to indicate that the driver > actually supports this? Yes. Can you please accept this with a new commit. Regards, Sunil -Original Message- From: Johannes Berg [mailto:johan...@sipsolutions.net] Sent: Thursday, September 15, 2016 2:19 PM To:

Re: [PATCH v5] cfg80211: Add support to configure a beacon data rate

On Thu, 2016-09-15 at 10:17 +0200, Johannes Berg wrote: > On Wed, 2016-09-14 at 17:38 +0530, Purushottam Kushwaha wrote: > > > > This allows an option to configure a single beacon tx rate (u8) for > > an AP. > > > Applied. > Actually. Moved to the pending branch - shouldn't we have some

Re: [PATCH v5] cfg80211: Add support to configure a beacon data rate

On Wed, 2016-09-14 at 17:38 +0530, Purushottam Kushwaha wrote: > This allows an option to configure a single beacon tx rate (u8) for > an AP. > Applied. I removed that "(u8)" there, and also removed the pointless hweight8/hweight16 - only the first one with >1 is needed. I'd like to see a driver

Re: [PATCH v2] mac80211: allow driver to handle packet-loss mechanism

On Wed, 2016-09-14 at 12:48 +0530, Rajkumar Manoharan wrote: > Based on consecutive msdu failures, mac80211 triggers CQM packet-loss > mechanism. Drivers like ath10k that have its own connection > monitoring > algorithm, offloaded to firmware for triggering station kickout. In > case > of station

brcmf_txfinalize misses 802.1x packet leading to infinite WARNINGs

Hi, Yesterday I explained on OpenWrt forum [0] that there are 2 problems leading to WARNINGs triggered by brcmf_netdev_wait_pend8021x. The first one is firmware problem with A-MPDU implementation. I already reported this in "AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs" e-mail

[PATCH] mac80211: reject TSPEC TIDs (TSIDs) for aggregation

From: Johannes Berg Since mac80211 doesn't currently support TSIDs 8-15 which can only be used after QoS TSPEC negotiation (and not even after WMM negotiation), reject attempts to set up aggregation sessions for them, which might confuse drivers. In mac80211 we do

Re: [PATCH] drivers: wilc1000: remove references to semaphores

On Tuesday 02 August 2016 12:04 AM, Joshua Houghton wrote: > * Update the comments that refer to semaphores > * Remove redundant includes to semphore.h > > Signed-off-by: Joshua Houghton > --- > drivers/staging/wilc1000/TODO | 1 - >

Re: [PATCH] nl80211: validate number of probe response CSA counters

On Tue, 2016-09-13 at 15:56 +0200, Johannes Berg wrote: > From: Johannes Berg > > Due to an apparent copy/paste bug, the number of counters for the > beacon configuration were checked twice, instead of checking the > number of probe response counters. Fix this to check