On Tue, 2015-06-02 at 23:35 -0700, Joe Perches wrote:
+ IEEE80211_HW_HAS_RATE_CONTROL,
+ IEEE80211_HW_RX_INCLUDES_FCS,
It may be nicer to use specified bit numbers here.
It may make compatibility easier and maybe it should be
written down that new entries are only to be added at
On Wed, 2015-06-03 at 10:57 +1000, Julian Calaby wrote:
Why not add a ieee80211_hw_clear() function? Yes, it'd only be used in
3 places, but it'd look neater.
Well, this was actually intentional.
Drivers are not *supposed* to be doing this, the hardware flags are
supposed to be constant
+patch author
- if (retry-disabled ||
+ if (retry-disabled || retry-value 1 || retry-value 255 ||
(retry-flags IW_RETRY_TYPE) != IW_RETRY_LIMIT)
return -EINVAL;
I'm wondering, is the 'retry-value 1' is necessary? I would write
'retry-value 0' instead, to make possible to disable
On Wed, 2015-06-03 at 13:14 +, Hodaszi, Robert wrote:
The problem is if I change the rt2800 driver to set 0 if it gets 1,
etc., that will break all existing user-space programs.
Well, I guess it's a question of which userspace even uses it, and how
it'll break.
Perhaps we should modify the
From: Johannes Berg johannes.b...@intel.com
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.
This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code
From: Johannes Berg johannes.b...@intel.com
The naming convention is to always have the flags prefixed with
IEEE80211_HW_ so they're 'namespaced', make this flag follow it.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +-
include/net
On Wed, 2015-06-03 at 14:46 +0200, Robert Hodaszi wrote:
From: Robert Hodaszi robert.hoda...@digi.com
To disable the transmit retries on RT28xx driver, the retry limit should
be set to 0. The current lower limit (1) prevents it.
So actually - we have the same limit in nl80211... we should
From: Johannes Berg johannes.b...@intel.com
The conversion to the fast-xmit path lost proper aggregation session
timeout handling - the last_tx wasn't set on that path and the timer
would therefore incorrectly tear down the session periodically (with
those drivers/rate control algorithms
Chun-Yeow Yeoh (1):
mac80211: fix the beacon csa counter for mesh and ibss
Jakub Kicinski (1):
mac80211: remove obsolete sentence from documentation
Johannes Berg (9):
mac80211: act upon and report deauth while associating
mac80211: move TX PN to public part of key struct
On Wed, 2015-06-10 at 14:26 +0200, Matthias May wrote:
I'm not sure what exactly you mean that the handle_channel_custom needs
to loop through 5/10/20.
The freq_reg_info_regd sets the disabled flag on the channel at init.
That's kinda my point - this isn't true. freg_req_info_regd()
On Wed, 2015-06-03 at 23:52 +0530, Chaitanya T K wrote:
In case of Dynamic SMPS enable RTS/CTS for all rates.
+ /* Enable RTS/CTS for below cases.
+ * 1) Handle STA's SMPS State, if Nss 1.
+ *a. Use RTS_CTS, if STA is in Dynamic SMPS Mode
+ *b. Mark Nss 1 as
On Mon, 2015-06-01 at 16:51 +0200, Wojciech Dubowik wrote:
We call rcu locked ieee80211_csa_update_counter from already locked
section. Fix it by splitting ieee80211_csa_update_counter into
locked and unlocked variants and use the latter in rcu locked section.
The subject of this patch implies
On Wed, 2015-06-03 at 10:44 +0300, Emmanuel Grumbach wrote:
From: Sara Sharon sara.sha...@intel.com
Channels in 2.4GHz band overlap, this means that if we
send a probe request on channel 1 and then move to channel
2, we will hear the probe response on channel 2. In this
case, the RSSI will
On Tue, 2015-06-09 at 13:00 -0700, Alexis Green wrote:
In mesh mode there is a race between establishing links and processing
rates and capabilities in beacons. This is very noticeable with slow
beacons (e.g. beacon intervals of 1s) and manifested for us as stations
using minstrel when
On Wed, 2015-06-03 at 08:36 +0200, Michal Kazior wrote:
There were a few rare cases when upon
authentication failure channel wasn't released.
This could cause stale pointers to remain in
chanctx assigned_vifs after interface removal and
trigger general protection fault later.
Applied. I've
On Tue, 2015-06-09 at 13:35 +0800, Chun-Yeow Yeoh wrote:
The csa counter has moved from sdata to beacon/presp but
it is not updated accordingly for mesh and ibss. Fix this.
This regression is introduced by the following patch:
mac80211: move csa counters from sdata to beacon/presp
Applied.
On Fri, 2015-06-05 at 12:43 -0700, Alexis Green wrote:
The last hop metric should refer to link cost (this is how
hwmp_route_info_get uses it for example). But in mesh_rx_path_sel_frame
we are not dealing with link cost but with the total cost to the origin
of a PREQ or PREP.
Signed-off-by:
On Fri, 2015-05-29 at 15:24 -0700, Alexis Green wrote:
In mesh mode there is a race between establishing links and processing rates
and capabilities in beacons. This is very noticeable with slow beacons (e.g.
beacon intervals of 1s) and manifested for us as stations using minstrel when
On Tue, 2015-06-09 at 16:20 -0700, Alexis Green wrote:
This patch fixes a bug in hwmp_preq_frame_process where the wrong metric
can be used when forwarding a PREQ. This happens because the code uses
the same metric variable to record the value of the metric to the source
of the PREQ and the
On Wed, 2015-06-10 at 15:09 +0200, Johannes Berg wrote:
The following changes since commit c3eee1fb1d308564ada5f7ea57bc51efc6130b37:
Merge tag 'batman-adv-for-davem' of git://git.open-mesh.org/linux-merge
(2015-06-09 20:23:52 -0700)
are available in the git repository at:
git
From: Johannes Berg johannes.b...@intel.com
Until recently, mac80211 overwrote all the statistics it could
provide when getting called, but it now relies on the struct
having been zeroed by the caller. This was always the case in
nl80211, but wext used a static struct which could even cause
From: Johannes Berg johannes.b...@intel.com
Until recently, mac80211 overwrote all the statistics it could
provide when getting called, but it now relies on the struct
having been zeroed by the caller. This was always the case in
nl80211, but wext used a static struct which could even cause
On Tue, 2015-06-02 at 21:10 +0200, Jakub Kicinski wrote:
From: Jakub Kicinski kubak...@wp.pl
FIF_PROMISC_IN_BSS was removed in commit df1404650ccb
(mac80211: remove support for IFF_PROMISC).
Applied, thanks.
johannes
--
To unsubscribe from this list: send the line unsubscribe
On Tue, 2015-06-02 at 03:02 +0530, Krishna Chaitanya wrote:
This isn't what your patch is actually doing though. You need to mention
WoWLAN at the very least in your commit log;
Yes, WoWLAN is enabled in our testing. Without wowlan the connection
will not be intact. So i assumed the check
On Tue, 2015-06-09 at 20:25 -0600, Gerrit Renker wrote:
Many thanks for providing the patch. I just tried it and it fixed both
problems
(access point signal level/quality and signal level reported for BSSes in scan
result). Not sure if trace results are still needed, but I can do that if
From: Johannes Berg johannes.b...@intel.com
This callback is currently not allowed to sleep, which makes it more
difficult to implement proper driver methods in mac80211 than it has
to be. Instead of doing asynchronous work here in mac80211, make it
possible for the callback to sleep by doing
From: Johannes Berg johannes.b...@intel.com
This callback is currently not allowed to sleep, which makes it more
difficult to implement proper driver methods in mac80211 than it has
to be. Instead of doing asynchronous work here in mac80211, make it
possible for the callback to sleep by doing
From: Johannes Berg johannes.b...@intel.com
On 32-bit architectures, the various (new) 64-bit statistics
aren't protected against reading while they're being changed
(which isn't atomic unlike on 64-bit architectures.)
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/rx.c
From: Johannes Berg johannes.b...@intel.com
This value is only used in mesh, so move it into the new mesh
sub-struct of the station info.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/mesh_hwmp.c | 9 +
net/mac80211/sta_info.h | 7 ---
2 files changed, 9
On Mon, 2015-06-22 at 13:58 +0200, Johannes Berg wrote:
On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
mac80211 configure rxfilter per HW,
so we don't need this per channel.
As I said before, I think there's value in mac80211 doing it per chanctx
or even per vif, and it should
On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
mac80211 configure rxfilter per HW,
so we don't need this per channel.
As I said before, I think there's value in mac80211 doing it per chanctx
or even per vif, and it should be more efficient to do so.
It's tempting to do it per vif
On Mon, 2015-06-22 at 10:20 +0200, Arend van Spriel wrote:
# iw phy phy0 interface add wlan0 type __ap
Indeed there is an issue with error handling here, but as this was a
user fault I was looking for early detection. If as you say that will
not be easy from cfg80211 we will need to
On Mon, 2015-06-22 at 09:47 +0200, Arend van Spriel wrote:
# iw phy phy0 interface add wlan0 type __ap
Now this is a pretty silly scenario as there already is a wlan0
interface. Admittedly, this should be rejected as such. This clearly is
a user mistake (not sure why you quoted that :-p
On Thu, 2015-06-25 at 16:12 +, Joerg wrote:
Hello all,
is there a way to submit a non-ASCII SSID with iw? One that contains
0 as in an octet with value zero?
No, that doesn't seem to be possible in the code.
But it's certainly possible in wp_supplicant config file, which you
should
On Thu, 2015-06-25 at 20:50 +, Joerg wrote:
Johannes Berg johannes@... writes:
On Thu, 2015-06-25 at 16:12 +, Joerg wrote:
Hello all,
is there a way to submit a non-ASCII SSID with iw? One that
contains
0 as in an octet with value zero?
No, that doesn't seem
From: Johannes Berg johannes.b...@intel.com
Most of the fields in this struct use too wide types, change
that to shrink the struct from 64 to 48 bytes (on 64-bit.)
This results in a total saving of 64 bytes for each sta_info.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net
From: Johannes Berg johannes.b...@intel.com
Most of the fields in this struct use too wide types, change
that to shrink the struct from 64 to 48 bytes (on 64-bit.)
This results in a total saving of 64 bytes for each interface.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net
From: Johannes Berg johannes.b...@intel.com
If an SKB will be segmented by the driver, count it for multiple
MSDUs that are being transmitted rather than just a single.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/tx.c | 6 +-
1 file changed, 5 insertions(+), 1
On Thu, 2015-06-11 at 13:06 +0200, Matthias May wrote:
const struct ieee80211_reg_rule *freq_reg_info(struct wiphy *wiphy,
-u32 center_freq)
+u32 center_freq, u32 min_bw)
{
const struct
On Thu, 2015-06-11 at 11:35 +0200, Rafał Miłecki wrote:
iw also wasn't helpful:
Frequencies:
* 5180 MHz [36] (30.0 dBm)
* 5200 MHz [40] (30.0 dBm)
* 5220 MHz [44] (30.0 dBm)
* 5240 MHz [48] (30.0 dBm)
After some in-kernel debugging (nl80211_set_wiphy,
On Thu, 2015-06-11 at 08:30 +, Daniel Lublin wrote:
The fix just went into net.git.
Aha! There you go. Where do I find it? Beginner kernel git diver...
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=9c5a18a31b321f120efda412281bb9f610f84aa0
johannes
--
To
On Thu, 2015-06-11 at 12:00 +0200, Rafał Miłecki wrote:
Upon rereading, I think my preference would be to remove much of the
channel list information and add a separate iw command.
Do you mean removing channel list from iw phy X info?
I'm not sure I'd remove it completely - but perhaps
On Thu, 2015-06-11 at 11:45 +0200, Johannes Berg wrote:
On Thu, 2015-06-11 at 11:35 +0200, Rafał Miłecki wrote:
iw also wasn't helpful:
Frequencies:
* 5180 MHz [36] (30.0 dBm)
* 5200 MHz [40] (30.0 dBm)
* 5220 MHz [44] (30.0 dBm)
* 5240 MHz [48] (30.0
On Thu, 2015-06-11 at 13:06 +0200, Matthias May wrote:
This patch changes the API of freq_freq_info() to take as additional argument
the minimum bandwidth the caller can handle.
If multiple rules match, the match with the widest bandwidth is returned.
You can't make a patch like this that
On Thu, 2015-06-11 at 06:16 -0700, Ben Greear wrote:
Maybe also allow the full dump with an optional --verbose flag: 'iw
--verbose phy X info' ?
Well, as I said, it's not so simple to do this in the info handler
since you need to collect all the info first and then print it.
johannes
--
To
On Wed, 2015-06-10 at 12:58 -0700, Ben Greear wrote:
Ok, thanks for that..one less piece of work for me to do :)
From what I can tell, it *IS* ok to have an AP do VHT on 40Mhz though?
It may even be compelled to do so by the spec, since there could be
overlapping networks (see 10.39.2.)
On Wed, 2015-06-10 at 12:29 -0700, Ben Greear wrote:
First, is this even a valid thing to do, or does VHT imply
that stations are always available to do 80Mhz?
According to the spec, a VHT STA must support 80 MHz:
802.11ac-2013, 22.1.1:
A VHT STA shall support the following features:
On Wed, 2015-06-10 at 14:43 -0700, Ben Greear wrote:
I was thinking netdevice might go away before user-space can decode the
message ( I was assuming that on delete you would stop and very shortly
after that delete the netdev).
Yeah, but in that case ... does it matter? :)
It's a small
On Wed, 2015-06-10 at 14:20 -0700, Ben Greear wrote:
While trying to make 'iw' able to print out something useful for
the 'stop_ap' event, I notice there is not really any human friendly
info in the message (just phy id (which may not match phy name), ifindex, and
some other
wiphy related
On Fri, 2015-06-12 at 10:31 +0200, Johannes Berg wrote:
* It would only support (non-null) data frames, management frames must
not be
passed to the new API, but must be passed to the regular
ieee80211_rx()
function.
Sorry about the line breaking - not sure how that happened.
Let me
Hi,
We're currently investigating how to best add RSS hashing to the
wireless stack.
Let's say, for the sake of discussion, that we'll add a function to
mac80211 called
ieee80211_rx_napi_mq(struct hw *, struct napi_struct *, struct sk_buff
*);
and (depending on the outcome of the design) the
From: Johannes Berg johannes.b...@intel.com
When introducing multiple RX queues, a single NAPI struct will not
be sufficient. Instead of trying to store multiple, simply change
the API to have the NAPI struct passed to the RX function. This of
course means that drivers using rx_irqsafe() cannot
On Fri, 2015-06-12 at 11:01 -0700, Jesse Jones wrote:
I had trouble reproing the reboot caused by ath9k de-referencing NULL
pointers but after a fair amount of work I was able to consistently get
reboots. Your patch *does* fix the problem so I am going to switch our repo
over to your patch
On Wed, 2015-06-17 at 20:38 +0200, Arend van Spriel wrote:
Hi Dan,
When I create an AP interface using iw, it is followed by a change
interface back to managed mode. I added a WARN_ON to see where it came
from and it turns out to be the NetworkManager. However, I had disabled
wifi as you
On Wed, 2015-06-17 at 22:32 +0200, Rafał Miłecki wrote:
When I create an AP interface using iw, it is followed by a change
interface back to managed mode. I added a WARN_ON to see where it came
I'm pretty sure it was for debugging purposes.
Oops, clearly. Sorry about that.
johannes
--
From: Johannes Berg johannes.b...@intel.com
Unfortunately, Michal's change to fix AP_VLAN crypto tailroom
caused a locking issue that was reported by lockdep, but only
in a few cases - the issue was a classic ABBA deadlock caused
by taking the mtx after the key_mtx, where normally they're
taken
On Wed, 2015-06-17 at 17:05 +0530, Krishna Chaitanya wrote:
Then again, you're talking about WoWLAN, but then ...
In wowlan, we simply call drv_resume and only if it fails
then we will go through full resume. And without wowlan
connection will not be there so this code will not be hit.
On Wed, 2015-06-17 at 06:06 +, David Lin wrote:
(not really reading all of this right now, just two small comments)
+struct mwl_tx_desc {
+ u8 data_rate;
+ u8 tx_priority;
+ __le16 qos_ctrl;
+ __le32 pkt_ptr;
+ __le16 pkt_len;
+ u8 dest_addr[ETH_ALEN];
+
On Wed, 2015-06-10 at 20:19 +0300, Emmanuel Grumbach wrote:
From: Eliad Peller el...@wizery.com
If reconfiguration fails, local-in_reconfig is never
cleaned, resulting in rx frames being dropped next
time the device is started.
Applied.
johannes
--
To unsubscribe from this list: send the
On Wed, 2015-06-10 at 20:42 +0300, Emmanuel Grumbach wrote:
From: Arik Nemtsov a...@wizery.com
Allow a device to specify support for the TDLS wider-bandwidth feature.
Indicate this support during TDLS setup in the ext-capab IE and set an
appropriate station flag when our TDLS peer supports
On Wed, 2015-06-10 at 13:06 +0200, Wojciech Dubowik wrote:
v2: Use splitted functions instead of direct counter decrement.
v3: Changed subject and commit message
I've applied this, but I really think you should've had a commit
message ...
johannes
--
To unsubscribe from this list: send the
On Fri, 2015-06-12 at 14:13 -0700, Alexis Green wrote:
From: Jesse Jones jjo...@cococorp.com
The 2012 spec mentions that path SNs can be invalid when created (see
section 13.10.8.4 table 13-9) but AFAICT never talks about invalidating
SNs. Which makes sense: if we have figured out the path
On Wed, 2015-06-10 at 15:17 -0700, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
In case user-space wants to know the name of the
device, this will save a name lookup by index, and
in case where kernel manages to fully delete the
interface before user-space can
On Wed, 2015-06-17 at 11:42 +0200, Felix Fietkau wrote:
On 2015-06-17 11:39, Sujith Manoharan wrote:
Janusz Dziedzic wrote:
This is what I have with use_chanctx=1
Jun 17 06:57:54 dell6430 kernel: [53297.753256] xxx ath_calcrxfilter
filter: 0x207
0x00080 is for probe_req
Ok,
On Wed, 2015-06-10 at 19:12 +0530, Chaitanya T K wrote:
From: Chaitanya T K chaitanya.m...@gmail.com
Background: When wowlan is enabled, the chipset stays in low
power state maintaining the connection as per the
mac80211 power save state.
If suspended during TX in progress, there can be
From: Johannes Berg johannes.b...@intel.com
There's a long-standing TODO item to use this flag in the cooked
monitor RX, but clearly it was never needed and now this hasn't
been used by userspace for a long time, so no userspace changes
could require it now.
Remove the unused flag.
Signed-off
On Thu, 2015-06-11 at 15:54 -0400, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
This is nicer than messages about unknown events.
Applied.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to
In preparation for my multi-queue RX work, I went through some code
to make this easier to handle. One thing that I wanted to do as part
of this was reorganise the station struct to be more cache-efficient,
but for now this just has the mesh code moving out of it, the other
part is still WIP.
(if
From: Johannes Berg johannes.b...@intel.com
There's no driver using this, so remove it.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
include/net/mac80211.h | 1 -
net/mac80211/cfg.c | 1 -
net/mac80211/mlme.c| 6 +-
3 files changed, 1 insertion(+), 7 deletions(-)
diff
From: Johannes Berg johannes.b...@intel.com
There are now a fairly large number of mesh fields that really
aren't needed in any other modes; move those into their own
structure and allocate them separately.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/cfg.c| 8
From: Johannes Berg johannes.b...@intel.com
Currently, the station hash table lookup (or iteration) must
access two cachelines for each station - the one with the hash
table node, and the one with the MAC address.
Duplicate the MAC address next to the hash node to get rid of
this. Since the MAC
From: Johannes Berg johannes.b...@intel.com
The code was always a bit awkward due to the 80-col restriction
and got worse in the previous patch. Refactor it a bit into its
own function to make it read nicer.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/cfg.c | 117
From: Johannes Berg johannes.b...@intel.com
When there are multiple RX queues, the PN checks in mac80211 cannot be
used since packets might be processed out of order on different CPUs.
Allow the driver to report that the PN has been checked, drivers that
will use multi-queue RX will have to set
On Wed, 2015-06-10 at 20:41 +0300, Emmanuel Grumbach wrote:
From: Arik Nemtsov a...@wizery.com
Define a station chandef, to be used for wider-bw TDLS peers. When both
peers support the feature, upgrade the channel bandwidth to the maximum
allowed by both peers and regulatory. Currently
On Wed, 2015-06-10 at 11:02 -0700, Alexis Green wrote:
When the nexthop is unable to resolve its own nexthop it will send back a
PERR with a zero target_sn. According to section 13.10.11.4.3 step b in the
2012 standard that perr should be forwarded and the associated mpath-sn
should be
On Fri, 2015-06-12 at 15:38 -0700, Alexis Green wrote:
From: Jesse Jones jjo...@cococorp.com
When processing a PREQ or PREP it's critical to use the incoming SN. If
that is improperly done routing loops and other types of badness can
happen. But the code was always processing path messages
On Sat, 2015-06-13 at 10:16 -0400, Bob Copeland wrote:
We already set a station to be associated when peering completes, both
in user space and in the kernel. Thus we should always have an
associated sta before sending data frames to that station.
Failure to check assoc state can cause
From: Johannes Berg johannes.b...@intel.com
This struct member is only assigned, never used otherwise;
remove it.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/key.c | 1 -
net/mac80211/sta_info.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/net/mac80211
From: Johannes Berg johannes.b...@intel.com
Short frames less than 16 octets are already blocked in the monitor
code by the should_drop_frame() function, and cannot get into the
regular RX path. Therefore, this check can never trigger and the
counter invariably stays zero. Remove the useless code
From: Johannes Berg johannes.b...@intel.com
We typically use 'sta' for the station info struct, and if needed
'pubsta' for the public (driver-visible) portion thereof. Do this
in the ieee80211_sta_ps_transition() function.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211
From: Johannes Berg johannes.b...@intel.com
There are no RX queues in mac80211 (yet), the comment should refer
to the TID (including one slot for non-QoS) rather than 'RX queue'.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/sta_info.h | 3 ++-
1 file changed, 2
From: Johannes Berg johannes.b...@intel.com
This function is only used in the RX code, so moving it into
that file gives the compiler better optimisation possibilities
and also allows us to remove the check for short frames (which
in the RX path cannot happen, but as a generic utility needed
From: Johannes Berg johannes.b...@intel.com
When introducing multiple RX queues, a single NAPI struct will not
be sufficient. Instead of trying to store multiple, simply change
the API to have the NAPI struct passed to the RX function. This of
course means that drivers using rx_irqsafe() cannot
From: Johannes Berg johannes.b...@intel.com
This counter is inherently racy (since it can be incremented by RX
as well as by concurrent TX) and only available in debugfs. Instead
of fixing it to be per-CPU or similar, remove it for now. If needed
it should be added without races and with proper
From: Johannes Berg johannes.b...@intel.com
As there's no driver using this capability and reporting zero-length
A-MPDU subframes for radiotap monitoring, remove the capability to
free up two RX flags.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
include/net/mac80211.h | 6
On Fri, 2015-06-12 at 02:34 +0530, Chaitanya T K wrote:
In case of Dynamic SMPS enable RTS/CTS for all rates.
Applied. I really think you should drop the . at the end of the
subject though :)
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a
On Wed, 2015-06-17 at 15:47 +0530, Krishna Chaitanya wrote:
On Wed, Jun 17, 2015 at 2:38 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Fri, 2015-06-12 at 02:34 +0530, Chaitanya T K wrote:
In case of Dynamic SMPS enable RTS/CTS for all rates.
Applied. I really think you should
On Tue, 2015-06-16 at 08:30 +0200, Janusz Dziedzic wrote:
Other fix I can image is change wpa_supplicant and add
NL80211_SCAN_FLAG_AP to p2p_find, and set in ath9k driver
wiphy-features |= NL80211_FEATURE_AP_SCAN;
NL80211_FEATURE_AP_SCAN is not set when use_chanctx=1
I am not sure which
to userspace with proper
local/remote indication
Arik Nemtsov (1):
mac80211: disconnect TDLS stations on STA CSA
Johannes Berg (3):
mac80211: fix memory leak
mac80211: add missing drv_priv description for TXQ struct
On Fri, 2015-05-29 at 13:34 +0200, Michal Kazior wrote:
I'm a bit undecided about this. Is this really the only place that
assumes use_4addr implies that it's a VLAN, in a context like this?
Hmm.. I guess TDLS could also have use_4addr and still be a
IFTYPE_STATION, right?
No, TDLS can
On Thu, 2015-05-28 at 11:46 +0200, Uwe Kleine-König wrote:
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Furthermore
On Fri, 2015-05-22 at 10:57 +0200, Michal Kazior wrote:
It was possible for mac80211 to be coerced into an
unexpected flow causing sdata union to become
corrupted. Station pointer was put into
sdata-u.vlan.sta memory location while it was
really master AP's sdata-u.ap.next_beacon. This
led
On Fri, 2015-05-22 at 10:22 +0200, Michal Kazior wrote:
There was a possible race between
ieee80211_reconfig() and
ieee80211_delayed_tailroom_dec(). This could
result in inability to transmit data if driver
crashed during roaming or rekeying and subsequent
skbs with insufficient tailroom
On Fri, 2015-05-22 at 10:57 +0200, Michal Kazior wrote:
It was possible for mac80211 to be coerced into an
unexpected flow causing sdata union to become
corrupted. Station pointer was put into
sdata-u.vlan.sta memory location while it was
really master AP's sdata-u.ap.next_beacon. This
led
On Thu, 2015-05-28 at 11:46 +0200, Uwe Kleine-König wrote:
When assigning directly to the pointer contained in the driver data the
local variable can be dropped together with the extra assignment to it.
I'm not really sure I see the big benefit of this? It doesn't really
seem to make the code
On Fri, 2015-05-29 at 14:42 +0200, Uwe Kleine-König wrote:
On Fri, May 29, 2015 at 01:17:04PM +0200, Johannes Berg wrote:
On Thu, 2015-05-28 at 11:46 +0200, Uwe Kleine-König wrote:
When assigning directly to the pointer contained in the driver data the
local variable can be dropped
On Sun, 2015-05-31 at 17:35 -0700, David Miller wrote:
Pulled, but there was a small conflict in include/net/mac80211.h which seemed
trivially resolvable. Take a look and send me a fixup if I got it wrong,
thanks.
Looks good - it seems I managed to apply two different docbook fixes to
the two
From: Johannes Berg johannes.b...@intel.com
When trying to associate, the AP could send a deauth frame instead.
Currently mac80211 drops that frame and doesn't report it to the
supplicant, which, in some versions and/or in certain circumstances
will simply keep trying to associate over and over
On Mon, 2015-06-01 at 10:37 +0300, Vladimir Kondratiev wrote:
+ # 60 gHz band channels 2-4 at 10mW,
gHz doesn't exist.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Mon, 2015-06-01 at 16:23 +0200, Wojciech Dubowik wrote:
On 01/06/15 16:13, Julian Calaby wrote:
Hi Wojciech,
On Mon, Jun 1, 2015 at 11:54 PM, Wojciech Dubowik
wojciech.dubo...@neratec.com wrote:
We call rcu locked ieee80211_csa_update_counter from
already locked section. Fix it by
701 - 800 of 3637 matches
Mail list logo
