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:
>
>
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,
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"
>
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
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
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
>
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(+),
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
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.
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
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
> 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
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
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
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
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
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,
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
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
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
>
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:
>>
21 matches
Mail list logo