[PATCH] mac80211: Encrypt "Group addressed privacy" action frames

Previously, the action frames to group address was not encrypted. But [1] "Table 8-38 Category values" indicates "Mesh" and "Multihop" category action frames should be encrypted (Group addressed privacy == yes). And the encyption key should be MGTK ([1] 10.13 Group addressed robust management

[PATCH v3 1/5] staging: wilc1000: Replace semaphore txq_event with completion

The semaphore 'txq_event' is used as completion, so convert it to a struct completion type. Signed-off-by: Binoy Jayan Reviewed-by: Arnd Bergmann --- drivers/staging/wilc1000/linux_wlan.c | 8 drivers/staging/wilc1000/wilc_wfi_netdevice.h

[PATCH v3 0/5] *** staging: wilc1000: Replace semaphores with mutexes or completions ***

These are a set of patches [v3] which removes semaphores from: drivers/staging/wilc1000 These are part of a bigger effort to eliminate all semaphores from the linux kernel. They build correctly (individually and as a whole). NB: The changes are untested Changes w.r.t. review comments on v1

[PATCH v3 2/5] staging: wilc1000: Replace semaphore txq_add_to_head_cs with mutex

The semaphore 'txq_add_to_head_cs' is a simple mutex, so it should be written as one. Semaphores are going away in the future. Also, removing the timeout scenario as the error handling code does not propagate the timeout properly. Signed-off-by: Binoy Jayan Reviewed-by:

[PATCH v3 4/5] staging: wilc1000: Replace semaphore sync_event with completion

The semaphore 'sync_event' is used as completion, so convert it to a struct completion type. Also, return -ETIME if the return value of wait_for_completion_timeout is 0. Signed-off-by: Binoy Jayan Reviewed-by: Arnd Bergmann ---

[PATCH v3 3/5] staging: wilc1000: Replace semaphore cfg_event with completion

The semaphore 'cfg_event' is used as completion, so convert it to a struct completion type. Signed-off-by: Binoy Jayan Reviewed-by: Arnd Bergmann --- drivers/staging/wilc1000/linux_wlan.c | 2 +- drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2

[PATCH v3 5/5] staging: wilc1000: Remove semaphore close_exit_sync

The semaphore 'close_exit_sync' does not serve any purpose other than delaying the deregistration of the device which it is trying to protect from shared access. 'up' is called only when a subdevice is closed and not when it is opened. So, the semaphore count only goes up when the device is used.

[PATCH v2 1/5] staging: wilc1000: Replace semaphore txq_event with completion

The semaphore 'txq_event' is used as completion, so convert it to a struct completion type. Signed-off-by: Binoy Jayan --- drivers/staging/wilc1000/linux_wlan.c | 8 drivers/staging/wilc1000/wilc_wfi_netdevice.h | 3 ++-

[PATCH v2 0/5] *** staging: wilc1000: Replace semaphores with mutexes or completions ***

These are a set of patches [v2] which removes semaphores from: drivers/staging/wilc1000 These are part of a bigger effort to eliminate all semaphores from the linux kernel. They build correctly (individually and as a whole). NB: The changes are untested Changes w.r.t. review comments on v1

RE: rt2800usb firmware rt2870.bin 0.36 not scanning

Craig McQueen wrote: > Xose Vazquez Perez wrote: > > Craig McQueen wrote: > > > > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 > > > chipset). I'm trying to use it on a BeagleBone Black based system > > > with 3.14.x kernel built with Yocto. We're using ConnMan 1.30 at

Re: [ldv-project] [net] libertas: potential race condition

On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote: > 08.06.2016 02:51, James Cameron пишет: > >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > >>>Hi! > >>> > >>>There is a potential race condition in >

Re: [PATCHv2 1/2] add basic register-field manipulation macros

On Tue, 14 Jun 2016 20:53:28 +0200, Arend van Spriel wrote: > On 14-06-16 13:44, Jakub Kicinski wrote: > > +#ifndef _LINUX_BITFIELD_H > > +#define _LINUX_BITFIELD_H > > + > > +#include > > +#include > > +#include > > + > > +#define _bf_shf(x) (__builtin_ffsll(x) - 1) > > + > > +#define

Re: [PATCHv2 1/2] add basic register-field manipulation macros

On 14-06-16 13:44, Jakub Kicinski wrote: > C bitfields are problematic and best avoided. Developers > interacting with hardware registers find themselves searching > for easy-to-use alternatives. Common approach is to define > structures or sets of macros containing mask and shift pair. >

Re: [PATCH 2/2] mac80211: store tx power value from user to station

Hi, [auto build test WARNING on mac80211/master] [also build test WARNING on v4.7-rc3] [cannot apply to mac80211-next/master next-20160614] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ashok

Re: [PATCH] ath10k: add support for controlling tx power to a station

Hi, [auto build test WARNING on ath6kl/ath-next] [also build test WARNING on v4.7-rc3 next-20160614] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support

Failed to set mode: Blocked through rfkill (0x12)

I'm trying to get bluetooth working and it sometimes does and sometimes not;) I've got two chips: BCM4360 (on motherboard, which never works) BCM20702A0 (Targus BT USB Adapter, which works mostly) I'm only interested in the BCM20702A0, right now. When I do sudo systemctl status

Re: [PATCH] ath10k: add support for controlling tx power to a station

Hi, [auto build test ERROR on ath6kl/ath-next] [also build test ERROR on v4.7-rc3 next-20160614] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support

[PATCH] iw: Add support for controlling tx power for per station

This patch allows userspace to set transmit power, in mBm units, to a station associated to the AP. To set a limit tx power of 2000 mBm: iw wlan0 station set txpwr limit 2000 To revert the user defined tx power for a station: iw wlan0 station set txpwr auto Signed-off-by: Ashok Raj Nagarajan

[PATCH 2/2] mac80211: store tx power value from user to station

This patch introduce a new driver callback drv_sta_set_txpwr. This API will copy the transmit power value passed from user space and call the driver callback to set the tx power for the station. Signed-off-by: Ashok Raj Nagarajan --- include/net/mac80211.h| 6

[PATCH 1/2] cfg80211: Add support to set tx power for a station associated

This patch adds support to set transmit power setting type and transmit power level attributes to NL80211_CMD_SET_STATION in order to facilitate adjusting the transmit power level of a station associated to the AP. The added attributes allow selection of automatic and limited transmit power

[PATCH] ath10k: add support for controlling tx power to a station

This patch will add the support to control the transmit power for traffic to a station associated with the AP. Userspace provide the transmit power value in mBm units and the allowed range is from 0 to 70. Underlying FW will enforce that the maximum tx power will be based on the regulatory

[PATCH] hsi: Build hsi_boardinfo.c into hsi core if enabled

If the HSI core is built as a module hsi_boardinfo may still be built-in as its Kconfig type is bool, which can cause build issues. Fix this by building this code into the HSI core when enabled. Reported-by: kbuild test robot Signed-off-by: Andrew F. Davis --- This

[ldv-project] [net] wcn36xx: potential race condition

Hi! There is a potential race condition in drivers/net/wireless/ath/wcn36xx/wcn36xx.ko. In wcn36xx_tx -> wcn36xx_start_tx -> wcn36xx_set_tx_data (http://lxr.free-electrons.com/source/drivers/net/wireless/ath/wcn36xx/txrx.c#L176) there is a read of sta_priv->bss_dpu_desc_index and

Re: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics support

Hi Kalle, On Tue, Jun 14, 2016 at 01:58:25PM +, Valo, Kalle wrote: > Mohammed Shafi Shajakhan writes: > > > From: Mohammed Shafi Shajakhan > > > > Enable support for 'drv_sta_statistics' callback. > > Export rx_duration support if

Re: [PATCH] ath10k: fix potential null dereference bugs

Bob Copeland writes: >> > However, with all this, I think I'd simply not take any chances - the >> > patch isn't exactly invasive and in some cases (for example the first >> > hunk of the patch) will even improve the code to the point where the >> > compiler could warn

Re: mwifiex: fix racing condition when downloading firmware

Wei-Ning Huang wrote: > The action 'check for winner' and 'download firmware' should be an > atomic action. This is true for btmrvl driver but not mwmfiex, which > cause firmware download to fail when the following senerio happens: > > 1) mwifiex check winner status: true >

Re: mwifiex: remove misleading GFP_DMA flag in buffer allocations

Mathias Krause wrote: > The GFP_DMA flag is obviously misunderstood in the mwifiex driver. It's > meant for legacy ISA DMA memory mappings only -- the lower 16MB on x86. > That doesn't apply to PCIe or SDIO devices, I guess. > > Remove the GFP_DMA flag to reduce the need

Re: mwifiex: inform disconnection initiator correctly.

Amitkumar Karwar wrote: > This patch ensures that 'locally_generated' parameter is correctly > passed to cfg80211_disconnected() API. > > Signed-off-by: Amitkumar Karwar Thanks, 1 patch applied to wireless-drivers-next.git: c62d50a4062e mwifiex:

Re: iwlegacy: avoid warning about missing braces

Arnd Bergmann wrote: > gcc-6 warns about code in il3945_hw_txq_ctx_free() being > somewhat ambiguous: > > drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit > braces to avoid ambiguous 'else' [-Wparentheses] > > This adds a set of curly braces to avoid

Re: brcmfmac: use kmemdup

Muhammad Falak R Wani wrote: > Use kmemdup when some other buffer is immediately copied into allocated > region. It replaces call to allocation followed by memcpy, by a single > call to kmemdup. > > Signed-off-by: Muhammad Falak R Wani > Acked-by:

Re: [V2, 4.8, 1/2] brcmutil: add field storing control channel to the struct brcmu_chan

Rafał Miłecki wrote: > Our d11 code supports encoding/decoding channel info into/from chanspec > format used by firmware. Current implementation is quite misleading > because of the way "chnum" field is used. > When encoding channel info, "chnum" has to be filled by a caller with > *center*

Re: [1/1] brcm80211: simplify assignment

Heinrich Schuchardt wrote: > Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Arend van Spriel Thanks, 1 patch applied to wireless-drivers-next.git: 6b128a01c673

Re: [1/1] mwiflex: avoid possible null pointer dereference

Heinrich Schuchardt wrote: > Do not dereference card before checking against NULL value. > > Signed-off-by: Heinrich Schuchardt Thanks, 1 patch applied to wireless-drivers-next.git: 141bcf099076 mwiflex: avoid possible null pointer dereference -- Sent

Re: [1/1] rtlwifi: rtl8192ee: simplify coding

Heinrich Schuchardt wrote: > Simplify _rtl92ee_phy_path_adda_on. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Larry Finger Thanks, 1 patch applied to wireless-drivers-next.git: a81605b14942 rtlwifi: rtl8192ee: simplify

Re: [ldv-project] [net] libertas: potential race condition

08.06.2016 02:51, James Cameron пишет: On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: Hi! There is a potential race condition in drivers/net/wireless/libertas/libertas.ko. In the function lbs_hard_start_xmit(..), line

Re: [1/1] mwifiex: illegal assignment

Heinrich Schuchardt wrote: > Variable adapter is incorrectly initialized. > > Fixes: bf00dc22bc7a ("mwifiex: AMSDU Rx frame handling in AP mode") > Signed-off-by: Heinrich Schuchardt > Acked-by: Amitkumar Karwar Thanks, 1 patch

Re: [1/1] rtlwifi: rtl8723be: avoid undefined behavior

Heinrich Schuchardt wrote: > Do not return undefined value for transmission power > if the rate is invalid. > > Signed-off-by: Heinrich Schuchardt > Acked-by: Larry Finger Thanks, 1 patch applied to wireless-drivers-next.git:

Re: [1/1] rsi: eliminate superfluous NULL check

Heinrich Schuchardt wrote: > msg is dereferenced before checking against NULL, e.g. > when assigning pad_bytes. > Remove the superfluous check in function rsi_mgmt_pkt_to_core. > > Signed-off-by: Heinrich Schuchardt Thanks, 1 patch applied to

Re: pull-request: iwlwifi 2016-06-10

Luca Coelho writes: > Here are some fixes intended for 4.7. Nothing really big, just some > fixes for bugs introduced in recent patches and a long-standing bug > with IGTK keys, which apparently had never worked properly before.  A > few more details in the tag message. > > Let

Re: [PATCH] ath10k: fix potential null dereference bugs

On Tue, Jun 14, 2016 at 01:51:24PM +, Kalle Valo wrote: > > It's not clear that's the same situation, since tun->sk is very likely > > to have been an actual pointer, not an embedded thing like drv_priv. Just to follow up on that thread, I did research it a bit yesterday and came to the

Re: Problems with mwifiex_pcie firmware activation

Stanislaw Gruszka writes: > Hence looks like forcing firmware upload somehow changed device, now it > is capable to initialize. On my second system device is on pristine state > and original problem is still reproducible. Do you have good solution > for this problem ? Did

Re: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics support

Mohammed Shafi Shajakhan writes: > From: Mohammed Shafi Shajakhan > > Enable support for 'drv_sta_statistics' callback. > Export rx_duration support if available to cfg80211/nl80211 > > This can also act as a placeholder for any new per STA

Re: [PATCH] ath10k: fix potential null dereference bugs

Johannes Berg writes: > On Mon, 2016-06-13 at 09:05 -0400, Bob Copeland wrote: >>  >> So I did just go and check the generated code for each of these cases >> and gcc didn't elide the subsequent if-test, at least on x86-64 and >> my compiler / build config.  Given

Re: ath9k: fix GPIO mask for AR9462 and AR9565

miaoqing pan wrote: > From: Miaoqing Pan > > The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11. > Also fix the mask for AR9565. > > WARNING: CPU: 1 PID: 199 at ../drivers/net/wireless/ath/ath9k/hw.c:2778 >

Re: [1/2] wil6210: fix chan check in wil_p2p_listen

Maya Erez wrote: > In wil_p2p_listen chan is checked to protect against NULL > pointer access only before setting channel = chan->hw_value. > Add a global parameter check to cover all accesses to chan. > > Signed-off-by: Maya Erez Thanks, 2

Re: ath5k: fix misplaced default label in sifs switch

Bob Copeland wrote: > In this switch statement, the default case does not always assign > sifs. In practice, ah->ah_bwmode cannot take values besides the > other labels, so this is not an actual problem, but it looks odd > and smatch complains thus: > >

Re: ath10k: fix deadlock while processing rx_in_ord_ind

Rajkumar Manoharan wrote: > commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task") > introduced deadlock while processing rx in order indication message > for qca6174 based devices. While merging replenish and txrx tasklets, > replenish task should be called

Re: [1/2] ath10k: Define an enum to enable cycle counter wraparound logic

Vasanthakumar Thiagarajan wrote: > QCA988X hw implements a different cycle counter wraparound > behaviour when compared to QCA4019. To properly handle different > wraparound logic for these chipsets replace already available > bool hw_params member,

Re: [v3,1/2] ath10k: remove duplicate and unused rx rate flags

Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > All these flags are not used and their use is completely > covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck', > and RX_PPDU_START_RATE_FLAG > > Signed-off-by:

Re: [PATCH] ath10k: Fix some of the macro definitions of HTT_RX_IND message

Vasanthakumar Thiagarajan writes: > Only five bits are defined to pass tid information in HTT_RX_IND > message, so the mask which can be used to extract tid should be 0x1f > instead of the current 0x3f. Also, macros which can be used to extract > flush_valid and

[PATCHv2 0/2] register-field manipulation macros

Hi! This set moves to a global header file macros which I find very useful and worth popularising. The basic problem is that since C bitfields are not very dependable accessing subfields of registers becomes slightly inconvenient. It is nice to have the necessary mask and shift operations

[PATCHv2 1/2] add basic register-field manipulation macros

C bitfields are problematic and best avoided. Developers interacting with hardware registers find themselves searching for easy-to-use alternatives. Common approach is to define structures or sets of macros containing mask and shift pair. Operations on the register are then performed as follows:

[PATCHv2 2/2] mt7601u: use linux/bitfield.h

Use the newly added linux/bitfield.h. Signed-off-by: Jakub Kicinski --- drivers/net/wireless/mediatek/mt7601u/dma.h | 2 - drivers/net/wireless/mediatek/mt7601u/mt7601u.h | 5 +- drivers/net/wireless/mediatek/mt7601u/util.h| 77 -

[PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics support

From: Mohammed Shafi Shajakhan Enable support for 'drv_sta_statistics' callback. Export rx_duration support if available to cfg80211/nl80211 This can also act as a placeholder for any new per STA stats support Signed-off-by: Mohammed Shafi Shajakhan

[PATCH v4 2/2] ath10k: Remove debugfs support for Per STA total rx duration

From: Mohammed Shafi Shajakhan cfg80211/nl80211 interface changes for per STA total rx-duration and very basic 'ath10k_sta_statistics' mac80211 callback is implemented to extend support for per station statistics from the driver. Also provision in 'iw dev wlan#N

Re: [PATCH 01/12] gpio: Only descend into gpio directory when CONFIG_GPIOLIB is set

On Mon, Jun 13, 2016 at 10:02 PM, Andrew F. Davis wrote: > When CONFIG_GPIOLIB is not set make will still descend into the gpio > directory but nothing will be built. This produces unneeded build > artifacts and messages in addition to slowing the build. Fix this here. > >

[PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

commit b057886524be ("ath10k: do not use coherent memory for allocated device memory chunks") replaced coherent memory allocation for memory chunks to fix low memory platforms. Unfortunately this is causing system freeze on x86 platform while bringing up qca99x0 device. The system hangs while DMA