inue;
D'oh. I don't know how that ended up in there, tbh.
Acked-by: Johannes Berg
johannes
On Thu, 2017-03-16 at 11:18 -0700, David Miller wrote:
> From: Johannes Berg
> Date: Thu, 16 Mar 2017 10:51:55 +0100
>
> > Here's the pull request you were waiting for. I went through all my
> > pending patches but only this one is applicable for net.git at this
>
> Attach at just above the driver, before it ever gets to
> stations/vdevs, and ignore radiotap headers and/or add special
> processing for metadata like rx-info?
That'd be a different feature, perhaps more like XDP.
There anyway is no radiotap header at that point, but not changing
whether or n
Hi all,
Occasionally - we just had another case - people want to hook into
packets received and processed by the mac80211 stack, but because they
don't need all of them (e.g. not data packets), even adding a monitor
interface and bringing it up has too high a cost because SKBs need to
be prepared
On Thu, 2017-03-09 at 10:34 +0100, ondrej.lyso...@seznam.cz wrote:
> From: Ondřej Lysoněk
>
> Use setup_timer() and setup_deferrable_timer() to set the data and
> function timer fields. It makes the code cleaner and will allow for
> easier change of the timer struct internals.
>
Applied, thanks.
ix dumpit error path RTNL deadlocks (2017-03-16 10:30:03 +0100)
Just a single fix, for the RTNL locking issues.
----
Johannes Berg (1):
nl80211: fix dumpit error
On Wed, 2017-03-15 at 14:59 -0700, David Miller wrote:
> From: Johannes Berg
> Date: Wed, 15 Mar 2017 14:29:13 +0100
>
> > From: Johannes Berg
> >
> > Sowmini pointed out Dmitry's RTNL deadlock report to me, and it
> turns out
> > to be perfectly accu
From: Johannes Berg
Sowmini pointed out Dmitry's RTNL deadlock report to me, and it turns out
to be perfectly accurate - there are various error paths that miss unlock
of the RTNL.
To fix those, change the locking a bit to not be conditional in all those
nl80211_prepare_*_dump() functions
On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote:
> From: Ondřej Lysoněk
>
> Use setup_timer() and setup_deferrable_timer() to set the data and
> function timer fields. It makes the code cleaner and will allow for
> easier change of the timer struct internals.
Btw, I suspect you generated thi
On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote:
> From: Ondřej Lysoněk
>
> Use setup_timer() and setup_deferrable_timer() to set the data and
> function timer fields. It makes the code cleaner and will allow for
> easier change of the timer struct internals.
Applied.
johannes
On Mon, 2017-03-06 at 13:25 +0100, Johannes Berg wrote:
> On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote:
> > From: Ondřej Lysoněk
> >
> > Use setup_timer() and setup_deferrable_timer() to set the data and
> > function timer fields. It makes the code cleaner an
> Not really. This is one of assignments for students I lead, so this
> is done by hand every end of winter semester (Note the From line.)
You really should teach them about coccinelle then :-)
> > Care to send a patch for that one too?
>
> I am just a forwarder, he received this request too, s
On Thu, 2017-03-02 at 17:50 +0100, Marcel Holtmann wrote:
> Hi Johannes,
>
> you have removed GENL_ID_GENERATE in 4.10, but that is actually
> breaking userspace API.
>
> commit a07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5
> Author: Johannes Berg
> Date: Mon Oc
next trees.
----
Johannes Berg (1):
average: change to declare precision, not factor
drivers/net/virtio_net.c| 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 2 +-
include/linux/average.h
within a BA session
Johannes Berg (3):
mac80211: fix packet statistics for fast-RX
mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length
mac80211: use driver-indicated transmitter STA only for data frames
Matt Chen (1):
mac80211: flush delayed work when entering sus
> > Chosen colors are questionable. Best solution would be also allow
> user to
> > redefine colors, like ls does with LS_COLORS or grep with
> GREP_COLORS. But that
> > is maybe overkill.
>
> I think you may have posted this to the wrong mailing list.
Actually, it seems to just be missing the "
From: Johannes Berg
Declaring the factor is counter-intuitive, and people are prone
to using small(-ish) values even when that makes no sense.
Change the DECLARE_EWMA() macro to take the fractional precision,
in bits, rather than a factor, and update all users.
While at it, add some more
er (1):
mac80211: check for allocation failure in debugfs code
Johannes Berg (7):
cfg80211: fix a documentation warning
mac80211: fix documentation warnings
rfkill: remove rfkill-regulator
wireless: radiotap: rewrite the radiotap header file
wireless: define ciphe
On Wed, 2017-02-08 at 13:03 +0100, Arnd Bergmann wrote:
>
> - Moving nla_put_{u8,u16,u32} out of line is probably uncontroversial
> and
> it helps enough with br_netlink.c, but nl820211 is worse and needs
> some
> additional fiddling.
Why would that not be sufficient by itself for nl80211?
B
Both applied, thanks.
johannes
On Wed, 2017-02-08 at 07:45 +, Ard Biesheuvel wrote:
> On 8 February 2017 at 07:00, Johannes Berg > wrote:
> > This looks strange to me:
> >
> > > +static int aes_s2v(struct crypto_shash *tfm,
> > > size_t num_elem, const u
This looks strange to me:
> +static int aes_s2v(struct crypto_shash *tfm,
> size_t num_elem, const u8 *addr[], size_t len[],
> u8 *v)
> {
> - u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
> + u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE] = {};
> + SHASH_DESC_ON_STACK(desc, t
> {
> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
> + struct shash_desc *desc;
> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)]
> CRYPTO_MINALIGN_ATTR;
> size_t i;
> - const u8 *data[2];
> - size_t data_len[2], data_elems;
> +
> + desc = (struct shash_desc *)b
Hi Dave,
I know it's super late, but I was travelling last week and the
whole FILS AEAD thing only played out over the weekend anyway.
Since the FILS code is all new in this cycle, it'd be good to
have the fixes, and the others are a bit older but still would
be good to fix sooner rather than late
On Fri, 2017-01-27 at 22:26 +0300, Pichugin Dmitry wrote:
> This fixes the checkpatch.pl warnings:
> * Macros should not use a trailing semicolon.
> * Spaces required around that '='.
> * Symbolic permissions 'S_IRUGO' are not preferred.
> * Macro argument reuse 'buflen' - possible side-effects
I
On Thu, 2017-01-26 at 07:27 -0800, Eric Dumazet wrote:
>
> if (!uh->check && !udp_sk(sk)->no_check6_rx) {
> udp6_csum_zero_error(skb);
> goto csum_error;
> }
Yeah, I'd found no_check6_rx already, was still trying to
On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote:
>
> > Unfortunately, I haven't been able to actually test this yet. I
> > also
> > didn't find the code that would drop frames with CSUM 0 either,
On Thu, 2017-01-26 at 06:45 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote:
>
> > Oops, sorry - receive. We can only indicate "CHECKSUM_UNNECESSARY",
> > nothing more advanced right now, but right now we'd indicate that
> &
On Thu, 2017-01-26 at 05:44 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 14:27 +0100, Johannes Berg wrote:
> > Hi,
> >
> > It looks like right now we may have a hardware bug and accept
> > 0x as
> > valid, when the outcome of the calculation is 0xff
Hi,
It looks like right now we may have a hardware bug and accept 0x as
valid, when the outcome of the calculation is 0x.
What do you think we should do about this?
We could ignore the issue entirely, since 0 wasn't ever supposed to be
sent anyway - but then we don't drop frames that we
On Tue, 2017-01-24 at 16:42 +0100, Amadeusz Sławiński wrote:
> cleanup patch to make use of ieee80211_ac_from_tid() to retrieve ac
> from
> ieee802_1d_to_ac[]
Applied.
johannes
On Wed, 2017-01-25 at 09:55 +0100, Amadeusz Slawinski wrote:
> And yes I did. Somehow managed to ignore those warnings though, sorry
> about that.
:)
That was intentional so nobody changing mac80211 in the future will
accidentally play with those flags through the normal accessors.
> Rechecked wi
On Tue, 2017-01-24 at 16:42 +0100, Amadeusz Sławiński wrote:
> cleanup patch to make use of set_sta_flag()/clear_sta_flag() in
> places
> where we access sta->_flags
>
> Signed-off-by: Amadeusz Sławiński
> ---
> net/mac80211/sta_info.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 dele
't try to sleep in rate_control_rate_init() (2017-01-24 16:31:54
+0100)
A single fix, for a sleeping context problem found by LTP.
----
Johannes Berg (1):
mac80211
---
Beni Lev (1):
cfg80211: consider VHT opmode on station update
Cedric Izoard (1):
mac80211: Fix headroom allocation when forwarding mesh pkt
Emmanuel Grumbach (1):
mac80211: fix the TID on NDPs sent as EOSP carrier
Felix Fietkau (1):
mac80211: initialize SMPS fiel
mac80211: minstrel: store probability variance instead of standard
deviation
mac80211: minstrel: make prob_ewma u16 instead of u32
mac80211: minstrel_ht: remove obsolete #if for >= 3 streams
Ilan peer (1):
mac80211: Fix addition of mesh configuration element
Johann
On Thu, 2017-01-12 at 20:02 +0100, Jason A. Donenfeld wrote:
> Hi Dan,
>
> Thanks for your response. I'd thought about this, at least for
> adding/removing wgpeers/wgipmasks and for configuring wgdevices. This
> would fit into multiple smaller messages indeed.
>
> But what about fetching the list
On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote:
> On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote:
> >
> > Applied. Also fixed the typo in the subject :)
>
> Thanks! Unfortunately I now got another warning for the same
> function, and though I
> Come to think of it, I'm thinking I should drop this patch and the
> driver should just use iwe_stream_add_event() instead? It'll be
> somewhat tricky to get the length correct though.
No, turns out that's basically impossible with all the compat etc.
stuff here.
johannes
On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote:
> On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote:
> >
> > Applied. Also fixed the typo in the subject :)
>
> Thanks! Unfortunately I now got another warning for the same
> function, and though I
On Wed, 2017-01-11 at 16:00 +0100, Arnd Bergmann wrote:
> On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
> wrote:
> > On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> > > This works fine here because iwe->u.data.length is guaranteed to
> > > be
> >
On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> gcc-7 complains that wl3501_cs passes NULL into a function that
> then uses the argument as the input for memcpy:
>
> drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
> include/net/iw_handler.h:559:3: error: argument 2 null
> > Exactly. My point is that this is breaking the expectation that
> > hosts are actually able to drop such packets.
>
> [readding CCs I removed earlier]
>
> Ah! Thanks. I was worried about creating packetloss :D.
Ah, well, no - at least not in this case.
> Hm, for this other other way round,
On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> > I wonder if MAC80211 should be doing IGMP snooping and not bridge
> > in this environment.
>
> In the long term, yes. For now, not quite sure.
There's no "for now" in t
On Mon, 2017-01-09 at 16:25 +0100, michael-dev wrote:
> Am 09.01.2017 13:15, schrieb Johannes Berg:
> > > That is bridge fdb entries (need to) expire so the bridge might
> > > "forget" a still-connected station not sending but only consuming
> > > broadcast
> > A host SHOULD silently discard a datagram that is received via
> > a link-layer broadcast (see Section 2.4) but does not specify
> > an IP multicast or broadcast destination address.
>
> This example is the other way round. It specifies how the IP
> destination shou
On Mon, 2017-01-09 at 12:44 +0100, M. Braun wrote:
> Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> > Does it make sense to implement the two in separate layers though?
> >
> > Clearly, this part needs to be implemented in the bridge layer due
> > to
> > the sn
On Fri, 2017-01-06 at 16:27 -0500, David Miller wrote:
> From: Johannes Berg
> Date: Fri, 6 Jan 2017 13:37:20 +0100
>
> > Here's another fix for something I noticed while reviewing the code
> in
> > a new suggested patch that added another netlink socket destroy
&
On Thu, 2017-01-05 at 15:38 +0100, Jorge Ramirez wrote:
> do you mean this?
>
> [jramirez@igloo ~ (debian-qcom-dragonboard410c-16.09-local $)]$ git
> diff
> diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
> index a4e8af3..c56bac5 100644
> --- a/net/wireless/wext-sme.c
> +++ b/net/w
> > Looks better, but
> >
> > > +static struct work_struct rfkill_any_work;
> >
> > At least on module exit you need to cancel this work.
>
> It is cancelled in rfkill_any_led_trigger_unregister(). It seemed
> fitting to do it this way as rfkill_any_work is initialized in
> rfkill_any_led_trig
On Sat, 2017-01-07 at 15:55 +0100, Linus Lüssing wrote:
> On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> > Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> > >
> > > > The bridge layer can use IGMP snooping to ensure that the
> > > > multi
On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:
> Actually, I do not quite understand that remark in the mac80211
> multicast-to-unicast patch. IP should not care about the ethernet
> header?
But it does, for example RFC 1122 states:
When a host sends a datagram to a link-layer
> The bridge layer can use IGMP snooping to ensure that the multicast
> stream is only transmitted to clients that are actually a member of
> the group. Can the mac80211 feature do the same?
No, it'll convert the packet for all clients that are behind that
netdev. But that's an argument for dropp
On Mon, 2017-01-02 at 20:32 +0100, Linus Lüssing wrote:
> Implements an optional, per bridge port flag and feature to deliver
> multicast packets to any host on the according port via unicast
> individually. This is done by copying the packet per host and
> changing the multicast destination MAC to
017-01-05 10:59:53
+0100)
Another single fix, to correctly handle destruction of a
single netlink socket having ownership of multiple objects
(scheduled scan requests and interfaces.)
----
Johannes Berg (1):
nl80211: fix sched
On Fri, 2017-01-06 at 07:07 +0100, Michał Kępień wrote:
> Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-
> any,
> which may be useful on laptops with a single "radio LED" and multiple
> radio transmitters. The trigger is meant to turn a LED on whenever
> there is at least one
> I am not sure it matters - if I understood your reply, there is no
> valid use case to change the frequency in that mode (and all that
> code should be removed);
All of wext *is* being removed - slowly :)
It's not longer default in the kernel configuration now.
IIRC, there actually was a vali
+linux-wireless, where this should've gone
> I am running a single wlan0 interface in managed mode (no aliases,
> no other wireless interfaces).
> The association with the AP still hasn't happened.
>
> I noticed that if trying to change the frequency to one of the valid
> values, the driver ret
On Mon, 2017-01-02 at 16:01 +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> There are no users of this ("vrfkill") in the tree, so it's just
> dead code - remove it.
>
> This also isn't really how rfkill is supposed to be used - it's
> intende
From: Johannes Berg
There are no users of this ("vrfkill") in the tree, so it's just
dead code - remove it.
This also isn't really how rfkill is supposed to be used - it's
intended as a signalling mechanism to/from the device, which the
driver (and partially cfg8021
> My understanding is it is generally felt that using the regulator
> enable GPIO commonly found on WiFi chips for rfkill is an abuse of
> rfkill as it is more that just an RF disable. From a DT standpoint,
> this seems like creating a binding for what a Linux driver wants.
> Instead, I think this
--
A single fix to avoid loading an skb->cb pointer too early.
----
Johannes Berg (1):
mac80211: initialize fast-xmit 'info' later
net/mac80211/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On Mon, 2017-01-02 at 13:21 +0100, Johannes Berg wrote:
> > I'm not super happy with this conditional locking - can't we
> > instead
> > defer the necessary work to a workqueue, or so, for purposes of the
> > LED?
>
> Actually, since you can sleep in
> I'm not super happy with this conditional locking - can't we instead
> defer the necessary work to a workqueue, or so, for purposes of the
> LED?
Actually, since you can sleep in here, and do various other things like
scheduling etc. this can't even be correct as is - one thread might be
in the
> - Handle the global mutex properly when rfkill_set_{hw,sw}_state()
> or
> rfkill_set_states() is called from within an rfkill callback. v2
> always tried to lock the global mutex in such a case, which led
> to a
> deadlock when an rfkill driver called one of the above functions
>
> Just to ensure things get cleaned up properly, as of now it looks
> like you only reverted patch 2/2 of my v2 and Arnd's fix to patch
> 1/2, not patch 1/2 itself.
Oops. I've fixed that up to only revert your patch - I wanted the
revert in the tree to document the issue, rather than just droppin
Hi Mike,
Thanks for the report. I'm sorry I missed this in review - obviously we
can't call something that acquires the mutex from rfkill_set_sw_state()
which clearly states, in the documentation:
* This function can be called in any context, even from within rfkill
* callbacks.
I've reverted
c80211: Ensure enough headroom when forwarding mesh pkt
Johannes Berg (1):
mac80211: don't call drv_set_default_unicast_key() for VLANs
net/mac80211/key.c | 3 ++-
net/mac80211/rx.c | 2 +-
net/mac80211/sta_info.c | 14 --
3 files changed, 11 insertions(+), 8 deletions(-)
On Fri, 2016-12-16 at 09:44 +0100, Arnd Bergmann wrote:
> A cleanup introduced a harmless warning in some configurations:
>
> net/rfkill/core.c: In function 'rfkill_init':
> net/rfkill/core.c:1350:1: warning: label 'error_input' defined but
> not used [-Wunused-label]
>
> This adds another #ifdef
On Thu, 2016-12-08 at 08:30 +0100, Michał Kępień wrote:
> Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-
> any,
> which may be useful on laptops with a single "radio LED" and multiple
> radio transmitters. The trigger is meant to turn a LED on whenever
> there is at least one
On Thu, 2016-12-08 at 08:30 +0100, Michał Kępień wrote:
> Use a separate label per error condition in rfkill_init() to make it
> a bit cleaner and easier to extend.
applied.
johannes
confusing (trying to use
a single attribute for two purposes)
* fix a long-standing BSS leak that happens when an
association attempt is abandoned
----
Johannes Berg (2):
nl80211: fix logic inversion in start_nan()
cfg802
On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
> It seems that there should be a better way to do it,
> but this works too.
In some cases there might be:
> --- a/drivers/s390/virtio/Makefile
> +++ b/drivers/s390/virtio/Makefile
> @@ -6,6 +6,8 @@
> # it under the terms of the GNU G
> Maybe someone could vouch that other checks prevent
> this kind of situation from happening but not me.
No, now that you spell it out (and I see the patch) - this is
absolutely needed because nla_for_each_attr() [1] can be called on
arbitrary data coming from userspace in a message, e.g. by way
> Thanks, these are obviously all valid concerns. Sorry for being
> sloppy
> with the ifdefs. If I get positive feedback on the proposed feature
> itself, all these issues (and the warning pointed out in the other
> message) will be resolved in v2.
Looks fine, please do that.
johannes
On Wed, 2016-11-23 at 20:45 -0800, Kirtika Ruchandani wrote:
> This patchset is part of the effort led by Arnd Bergmann to clean up
> warnings in the kernel. This and following patchsets will focus on
> "-Wunused-but-set-variable" as it among the noisier ones. These were
> found compiling with W=1.
On Mon, 2016-11-21 at 22:54 -0800, Kirtika Ruchandani wrote:
> Commit 3b17fbf87d5d introduced sta_get_expected_throughput()
> leaving variable 'struct rate_control_ref* ref' set but unused.
> Compiling with W=1 gives the following warning, fix it.
>
> net/mac80211/sta_info.c: In function ‘sta_set_
On Mon, 2016-10-31 at 14:41 +0100, Michael Braun wrote:
> +static int ieee80211_set_multicast_to_unicast(struct wiphy *wiphy,
> + struct net_device
> *dev,
> + const bool enabled)
> +{
> + struct ieee80211_sub
On Mon, 2016-10-31 at 14:40 +0100, Michael Braun wrote:
> There is no need to prevent toggling multicast_to_unicast while
> interface is already up. This change simplifies reconfiguration
> from hostapd.
Applied. This check never should've been there anyway, if desired,
NEED_NETDEV_UP should've be
T IE from peer with wrong rx_mcs_map
Johannes Berg (1):
cfg80211: limit scan results cache size
Pedersen, Thomas (1):
cfg80211: add bitrate for 20MHz MCS 9
drivers/net/wireless/mac80211_hwsim.c | 2 +-
net/mac80211/sta_info.c | 2 +-
net/mac80211/tx.c |
On Wed, 2016-11-02 at 10:04 +0100, Filip Matusiak wrote:
> This is a workaround for VHT-enabled STAs which break the spec
> and have the VHT-MCS Rx map filled in with value 3 for all eight
> spacial streams, an example is AR9462 in AP mode.
>
> As per spec, in section 22.1.1 Introduction to the VH
> > I suppose it could be, since family IDs are allocated in a 16-bit
> > range
> > anyway. But family IDs can also never actually be negative, so
> > having
> > an unsigned int in the struct makes sense too.
>
> All idr_* API's accept int, rather than unsigned int. This is my
> point.
Sure, but
On Thu, 2016-11-10 at 09:11 -0800, Cong Wang wrote:
> On Thu, Nov 10, 2016 at 7:57 AM, Colin King > wrote:
> >
> > From: Colin Ian King
> >
> > family->id is unsigned, so the less than zero check for
> > failure return from idr_alloc is never true and so the error exit
> > is never handled. In
> Ideally we prefer that drivers/net/wireless and net/wireless changes
> are
> split into different patches as they get applied to different trees.
> Johannes, is it ok if I take this change through my tree this time?
Sure, please do, thanks.
(I don't particularly care about the lib80211 stuff a
Hi,
Sorry for not chipping in earlier - LPC is taking my time.
> > > > Looks like we are missing a kfree(family->attrbuf); on error
> > > > path, but it is not related to Johannes' recent patches.
Actually, I think it *is* related to my patch - I inserted the code
there in the wrong place or so.
forgot this wasn't even executed.
Sorry about that!
Reviewed-by: Johannes Berg
johannes
On Fri, 2016-10-28 at 19:08 +0100, Colin King wrote:
> From: Colin Ian King
>
> The current exit path when tmp fails to be allocated is via the
> fail label which frees tfm2 which has not yet been allocated,
> which is problematic since tfm2 is not initialized and is a garbage
> pointer. Fix this
On Fri, 2016-10-28 at 16:38 +0200, Filip Matusiak wrote:
> This is a workaround for VHT-enabled STAs which break the spec
> and have the VHT-MCS Rx map filled in with value 3 for all eight
> spacial streams.
>
> As per spec, in section 22.1.1 Introduction to the VHT PHY
> A VHT STA shall support a
1: allow aborting in-progress connection atttempts
Johannes Berg (17):
mac80211: remove unnecessary mesh check
mac80211_hwsim: make multi-channel ops const
mac80211: preserve more bits when building QoS header
nl80211: correctly use nl80211_nan_srf_policy
nl80211: ifdef WoW
On Fri, 2016-10-28 at 12:25 +0200, Arnd Bergmann wrote:
> gcc -Wmaybe-uninitialized reports a bug in aes_siv_encryp:
>
> net/mac80211/fils_aead.c: In function ‘aes_siv_encrypt.constprop’:
> net/mac80211/fils_aead.c:84:26: error: ‘tfm2’ may be used
> uninitialized in this function [-Werror=maybe-un
Emmanuel Grumbach (2):
mac80211: allow the driver not to pass the tid to
ieee80211_sta_uapsd_trigger
mac80211: uapsd_queues is in QoS IE order
Ilan Peer (1):
cfg80211: allow aborting in-progress connection atttempts
Johannes Berg (17):
mac80211: remove unnecessary mesh c
On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote:
> This add a userspace toggle to configure multicast to unicast.
>
I applied this, with a bunch of fixes and documentation improvements.
johannes
> @@ -2242,6 +2242,20 @@ static int ieee80211_set_wds_peer(struct wiphy
> *wiphy, struct net_device *dev,
> return 0;
> }
>
> +static int ieee80211_set_multicast_to_unicast(struct wiphy *wiphy,
> + struct net_device
> *dev,
> +
is
suspended
* small markup fixes for the sphinx documentation conversion
that's coming into the tree via the doc tree
Jani Nikula (1):
mac80211: fix some sphinx warnings
Johannes Berg (1):
cfg80211: proc
From: Johannes Berg
Use nla_parse_nested instead of open-coding the call to
nla_parse() with the attribute data/len.
Signed-off-by: Johannes Berg
---
net/sched/act_api.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index
On Wed, 2016-10-26 at 11:52 +0200, Thomas Graf wrote:
> On 10/26/16 at 10:59am, Johannes Berg wrote:
> >
> >
> > >
> > > /**
> > > + * nla_memdup - duplicate attribute memory (kmemdup)
> > > + * @src: netlink attribute to duplicate from
>
> /**
> + * nla_memdup - duplicate attribute memory (kmemdup)
> + * @src: netlink attribute to duplicate from
> + * @gfp: GFP mask
Actually, is there any point in passing a GFP mask? None of the current
users need it, and it seems fairly unlikely to be needed since this is
typically used on the
On Wed, 2016-10-26 at 10:53 +0200, Thomas Graf wrote:
> Wrap several common instances of:
> kmemdup(nla_data(attr), nla_len(attr), GFP_KERNEL);
Makes sense
Acked-by: Johannes Berg
johannes
On Tue, 2016-10-25 at 11:25 +, David Laight wrote:
> > Actually, with the new system where it's not const, I could even
> > split this up and submit per subsystem, i.e. the fourth patch
> > doesn't depend on it. I thought it would, since I wanted to make it
> > const, but since I failed it doe
On Mon, 2016-10-24 at 14:40 +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> Instead of providing macros/inline functions to initialize
> the families, make all users initialize them statically and
> get rid of the macros.
>
> This reduces the kernel code size by
801 - 900 of 1980 matches
Mail list logo
