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 station dump' to parse rx-durati
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
---
[v4] rebased over 'pending' branch
[v3]
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 -
3 files changed, 4 insertions(+
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:
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
wrapped
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 release_valid bits have to be left
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: Mohammed Shafi Shajakhan
Thanks, 2 patches applied to ath-ne
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, has_shifted_cc_wraparound, with an
> enum which
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 out of htt rx ring locking sin
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:
>
> ath5k_hw_get_default_sifs() warn: miss
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 patches applied to ath-next branch of ath.git:
9c830a
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
> ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
> CPU: 1 PID: 199 Comm: k
I have two systems with this device:
03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8897
[AVASTAR] 802.11ac Wireless [11ab:2b38]
Flags: bus master, fast devsel, latency 0, IRQ 92
Memory at 9070 (64-bit, prefetchable) [size=1M]
Memory at 9060 (
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 http://lwn.net/Articles/342330,
Bob Copeland writes:
> Smatch warns about a number of cases in ath10k where a pointer is
> null-checked after it has already been dereferenced, in code involving
> ath10k private virtual interface pointers.
>
> Fix these by making the dereference happen later.
>
> Addresses the following smatch w
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 stats support
>
> Signed-off-by: Mohammed Shafi Shajakh
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 you see this:
mwifiex:
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 conclu
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 me know if everyt
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 wireless-drivers-next.git:
9b648d788d78 rsi: elimin
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:
6b3c33e985f2 rtlwifi: rtl8723be: avoid undefined behavior
--
Sent
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 applied to wireless-drivers-next.git:
3fdbda446fbc mwifiex: illeg
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 159
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 by pwcli
https://patchwork.kernel.org/pa
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 coding
--
Sent by pwcli
https://patchwork.kernel.org/patch/9115711
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 brcm80211: simplify assignment
--
Sent by pwcli
https://patchwork.kern
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* channel
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: Arend van Spriel
Thanks, 1 patch applied to wi
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 the warning.
>
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 to place the socket buffe
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: inform disconnection initiator correctly.
--
S
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
> 2) btmrvl check winner
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 about uninitialized usage o
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 available to cfg80211/nl80211
> >
> > This can also act as a
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
sta_priv->b
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 build error seems to be due to
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
requirem
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 level,
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 ++
net/mac80211/cfg.c
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
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-for
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 bluetooth.serv
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-for
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
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.
> Operati
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 _BF_FIELD
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
> >>>dr
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 the
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
1.
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 ++-
drivers/staging/wilc1000/wilc_wlan.c | 8 +---
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.
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
---
drivers/staging/wilc1000/linux_wlan.c | 10 +-
driv
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 +-
drivers/staging/wilc1000/wilc_wlan.
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: Arnd Bergmann
---
driver
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
1.
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 | 3 ++-
drivers/staging/wilc1000/wilc_
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 frame
Hi Andrew,
Thanks for the patch.
Please address the issue [1] raised by test bot and resubmit.
Thanks,
Jacek Anaszewski
[1] https://lkml.org/lkml/2016/6/13/1091
On 06/13/2016 10:02 PM, Andrew F. Davis wrote:
When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory but
58 matches
Mail list logo
