Re: [PATCH] mac80211: Do not use sizeof() on pointer type

On Wed, 2015-08-26 at 12:22 +0200, Thierry Reding wrote: > From: Thierry Reding > > The rate_control_cap_mask() function takes a parameter mcs_mask, > which > GCC will take to be u8 * even though it was declared with a fixed > size. > This causes the following warning: > >

RE: kernel log flooded with GET_CMD_NODE: cmd node not available

Hi Marty, > From: Marty Faltesek [mailto:mfalte...@google.com] > Sent: Friday, September 04, 2015 3:21 AM > To: Belisko Marek > Cc: Amitkumar Karwar; linux-wireless@vger.kernel.org > Subject: Re: kernel log flooded with GET_CMD_NODE: cmd node not > available > > On Mon, Aug 31, 2015 at 7:54 AM,

Re: [PATCH] cfg80211: regulatory: restore proper user alpha2

On Wed, 2015-09-02 at 19:00 +0200, Maciej S. Szmigiero wrote: > restore_regulatory_settings() should restore alpha2 > as computed in restore_alpha2(), not raw user_alpha2 to > behave as described in the comment just above that code. > > This fixes endless loop of calling CRDA for "00" and "97" >

Re: [PATCH 8/9] mac80211: avoid VHT usage with no 80MHz chans allowed

On Sat, 2015-08-15 at 22:39 +0300, Emmanuel Grumbach wrote: > From: Arik Nemtsov > > Currently if 80MHz channels are not allowed for use, the VHT IE is > not > included in the probe request for an AP. This is not good enough if > the > AP is configured with the wrong

Re: [PATCH] ath: use PRI value given by spec for fixed PRI

On 09/03/2015 08:04 PM, Peter Oh wrote: > Hi Zefir, > > I believe the patch below is good to be checked in since you've already made > change in DFS. > Can you confirm it? > > [...] > Hi Peter, yes, after adding the chirp detecting feature to ath9k, I did an internal certification run with all

Re: [PATCH] mac80211: protect non-HT BSS when HT TDLS traffic exists

On Tue, 2015-08-18 at 16:52 +0300, Emmanuel Grumbach wrote: > From: Avri Altman > > HT TDLS traffic should be protected in a non-HT BSS to avoid > collisions. Therefore, when TDLS peers join/leave, check if > protection is (now) needed and set the ht_operation_mode of >

[PATCH] staging: wilc1000: fix freeing of ERR_PTR

If memdup_user() fails then it will return the error code in ERR_PTR. We were checking it with IS_ERR but then again trying to free it on the error path. Signed-off-by: Sudip Mukherjee --- drivers/staging/wilc1000/linux_wlan.c | 6 ++ 1 file changed, 2 insertions(+),

Re: [PATCH] ath: use PRI value given by spec for fixed PRI

Zefir Kurtisi writes: > On 09/03/2015 08:04 PM, Peter Oh wrote: >> Hi Zefir, >> >> I believe the patch below is good to be checked in since you've already made >> change in DFS. >> Can you confirm it? >> >> [...] >> > Hi Peter, > > yes, after adding the chirp

pull-request: mac80211 2015-09-04

Hi, First pull request for this cycle, and the fix for the pointer issue is the first patch in it :) Since nobody really has devices with enough streams where this matters, it was pretty harmless though. Other than that, there are a few fixes all over - let me know if you see any issues.

Re: kernel log flooded with GET_CMD_NODE: cmd node not available

Hi Amit, On Fri, Sep 4, 2015 at 8:10 AM, Amitkumar Karwar wrote: > Hi Marty, > > Could you please enable debug logs using below command and share complete log? > > echo "0x" > /sys/kernel/debug/mwifiex/mlan0/debug_mask > > It should contain normal behavior followed

Re: [PATCH 3/5] staging: wilc1000: use id value as argument

On Fri, Sep 04, 2015 at 03:01:55PM +0900, johnny.kim wrote: > > > On 2015년 09월 04일 12:51, Greg KH wrote: > >On Fri, Sep 04, 2015 at 12:24:29PM +0900, johnny.kim wrote: > >> > >>On 2015년 09월 04일 00:47, Greg KH wrote: > >>>On Thu, Sep 03, 2015 at 04:00:08PM +0900, johnny.kim wrote: > Hello

Re: [PATCH 1/1] New driver: rtl8xxxu (mac80211)

> I'll add a comment to the code explaining why it is done this way. I > had > a peak at the rate_control code earlier, but it wasn't obvious to me > whether I should be using that API at all. Is there an explanation of > the API and it's usage somewhere? > Sadly no, it's one of the oldest and

Re: [PATCH 1/1] New driver: rtl8xxxu (mac80211)

On Fri, 2015-09-04 at 13:48 -0400, Jes Sorensen wrote: > > Gotcha, now you mention it, that rings a bell! I'll put that on my todo > list. One of the biggest things puzzling me is how much the firmware > does with AMPDU - there is a break bit I can set in the TX descriptor to > say 'don't AMPDU

[PATCH] cfg80211: handle fragmented IEs in splitting

From: Johannes Berg The IEs "output" can sometimes combine IEs coming from userspace with IEs generated in the kernel - in particular mac80211 does this for association frames. Add support in this code for the 802.11 IE fragmentation. Signed-off-by: Johannes Berg

Re: [PATCH 1/1] New driver: rtl8xxxu (mac80211)

Johannes Berg writes: > On Wed, 2015-09-02 at 22:39 -0400, Jes Sorensen wrote: >> >> I went back and looked at this, and now I remember why I wrote the code >> the way I did. The Realtek firmware handles rate control, so once I set >> IEEE80211_HW_HAS_RATE_CONTROL, I

Re: [PATCH 1/1] New driver: rtl8xxxu (mac80211)

Jes Sorensen wrote: > > Ah, this makes sense. There's an rc_update call or something like that, > > that might have the requisite information. Not really sure off the top > > of my head. ieee80211_sta doesn't contain the preamble information, though ? The bss information holds the short preamble

Re: [PATCH 1/1] New driver: rtl8xxxu (mac80211)

Johannes Berg writes: > On Wed, 2015-09-02 at 21:59 -0400, Jes Sorensen wrote: >> >> The code mimics what the vendor driver does - part of the bringup of the >> chip sets a bunch of parameters from an register value array. Rather >> than guessing what their default is,

[RFC] staging: rtl8188eu: Introduce monitor interface for IEEE 802.11 frames

This adds support for monitoring IEEE 802.11 Data and Management frames received or transmitted by a RTL8188EU-based device handled by this driver. The monitor interface is not enabled by default and will be registered only if monitor_enable module parameter is set to 1. When enabled it will

[RFC] Monitor interface for rtl8188eu

Hi, This patch is intended as a debugging aid for people working on the rtl8188eu driver. I'm posting it as an RFC in case it turns out useful for others. (Although I hope it won't be useful for long, if the recently proposed rtl8xxxu driver stands up to its name. ;-) The latest version of the

Re: FCC's new regulations on 5Ghz Wifi

On 08/14/2015 at 11:47 PM, Xose Vazquez Perez wrote: > Hi, > > The FCC wants to require manufacturers to lock down devices > with radio (wifi, bluetooth, etc) with DRM. > > More info: > http://wiki.prplfoundation.org/wiki/Complying_with_FCC_rules_on_Wifi > http://libreplanet.org/wiki/Save_WiFi >

Re: FCC's new regulations on 5Ghz Wifi

On 09/04/2015 at 08:07 AM, Andreas Hartmann wrote: > On 08/14/2015 at 11:47 PM, Xose Vazquez Perez wrote: >> Hi, >> >> The FCC wants to require manufacturers to lock down devices >> with radio (wifi, bluetooth, etc) with DRM. >> >> More info: >>