* Re: [PATCH v2 net] inet: frags: rework rhashtable dismantle
From: Eric Dumazet @ 2018-10-02 13:16 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: David Miller, netdev, Eric Dumazet, Thomas Graf, Herbert Xu
In-Reply-To: <CACT4Y+YH92M_X7h21W-unhp73tXV+itxuL0JjrfEd4B4Lohjig@mail.gmail.com>
On Tue, Oct 2, 2018 at 1:19 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Oct 2, 2018 at 7:49 AM, Eric Dumazet <edumazet@google.com> wrote:
>
>
> Does inet_frag_kill() hold fq->lock? I am missing how inet_frag_kill()
> and inet_frags_exit_net() are synchronized.
> Since you use smp_store_release()/READ_ONCE() they seem to run in
> parallel. But then isn't it possible that inet_frag_kill() reads
> nf->dead == 0, then inet_frags_exit_net() sets nf->dead, and then we
> have the same race on concurrent removal? Or, isn't it possible that
> inet_frag_kill() reads nf->dead == 1, but does not set
> INET_FRAG_HASH_DEAD yet, and then inet_frags_free_cb() misses the
> INET_FRAG_HASH_DEAD flag?
>
Yes this is kind of implied in my patch.
I put the smp_store_release() and READ_ONCE exactly to document the
possible races.
This was the reason for my attempt in V1, doing a walk, but Herbert
said walk was not designed for doing deletes.
Proper synch will need a synchronize_rcu(), and thus a future
conversion in net-next because we can not really
add new synchronize_rcu() calls in an (struct
pernet_operations.)exit() without considerable performance hit of
netns dismantles.
So this will require a conversion of all inet_frags_exit_net() callers
to .exit_batch() to mitigate the cost.
I thought of synchronize_rcu_bh() but this beast is going away soon anyway.
^ permalink raw reply
* Re: [PATCH ethtool v2] ethtool: Fix uninitialized variable use at qsfp dump
From: Andrew Lunn @ 2018-10-02 12:50 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: netdev, John W. Linville, Chris Preimesberger, Neil Horman,
Vidya Sagar Ravipati
In-Reply-To: <1538465059-24645-1-git-send-email-eranbe@mellanox.com>
On Tue, Oct 02, 2018 at 10:24:19AM +0300, Eran Ben Elisha wrote:
> Struct sff_diags can be used uninitialized at sff8636_show_dom, this
> caused the tool to show unreported fields (supports_alarms) by the lower
> level driver.
>
> In addition, make sure the same struct is being initialized at
> sff8472_parse_eeprom function, to avoid the same issue here.
>
> Fixes: a5e73bb05ee4 ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support")
> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Hi Eran
Thanks for fixing both cases.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 1/1] net: fec: fix rare tx timeout
From: rickard.andersson @ 2018-10-02 12:49 UTC (permalink / raw)
To: fugang.duan, netdev; +Cc: Rickard x Andersson
In-Reply-To: <20181002124932.14810-1-rickard.andersson@axis.com>
From: Rickard x Andersson <rickaran@axis.com>
During certain heavy network loads TX could time out
with TX ring dump.
TX is sometimes never restarted after reaching
"tx_stop_threshold" because function "fec_enet_tx_queue"
only tests the first queue.
In addition the TX timeout callback function failed to
recover because it also operated only on the first queue.
Signed-off-by: Rickard x Andersson <rickaran@axis.com>
---
drivers/net/ethernet/freescale/fec_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index eb2ea231c7..8bfa6ef826 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1155,7 +1155,7 @@ static void fec_enet_timeout_work(struct work_struct *work)
napi_disable(&fep->napi);
netif_tx_lock_bh(ndev);
fec_restart(ndev);
- netif_wake_queue(ndev);
+ netif_tx_wake_all_queues(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
}
@@ -1270,7 +1270,7 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
/* Since we have freed up a buffer, the ring is no longer full
*/
- if (netif_queue_stopped(ndev)) {
+ if (netif_tx_queue_stopped(nq)) {
entries_free = fec_enet_get_free_txdesc_num(txq);
if (entries_free >= txq->tx_wake_threshold)
netif_tx_wake_queue(nq);
@@ -1747,7 +1747,7 @@ static void fec_enet_adjust_link(struct net_device *ndev)
napi_disable(&fep->napi);
netif_tx_lock_bh(ndev);
fec_restart(ndev);
- netif_wake_queue(ndev);
+ netif_tx_wake_all_queues(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
}
@@ -2249,7 +2249,7 @@ static int fec_enet_set_pauseparam(struct net_device *ndev,
napi_disable(&fep->napi);
netif_tx_lock_bh(ndev);
fec_restart(ndev);
- netif_wake_queue(ndev);
+ netif_tx_wake_all_queues(ndev);
netif_tx_unlock_bh(ndev);
napi_enable(&fep->napi);
}
--
2.11.0
^ permalink raw reply related
* [PATCH 0/1] net: fec: fix rare tx timeout
From: rickard.andersson @ 2018-10-02 12:49 UTC (permalink / raw)
To: fugang.duan, netdev; +Cc: Rickard x Andersson
From: Rickard x Andersson <rickaran@axis.com>
This patch is not fully verified yet but I would much
appreciate feedback.
Rickard x Andersson (1):
net: fec: fix rare tx timeout
drivers/net/ethernet/freescale/fec_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/5] xsk: fix bug when trying to use both copy and zero-copy mode
From: Magnus Karlsson @ 2018-10-02 12:49 UTC (permalink / raw)
To: jakub.kicinski
Cc: Karlsson, Magnus, Björn Töpel, ast, Daniel Borkmann,
Network Development, Jesper Dangaard Brouer
In-Reply-To: <20181001133146.1b8f3810@cakuba.netronome.com>
On Mon, Oct 1, 2018 at 10:34 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Mon, 1 Oct 2018 14:51:32 +0200, Magnus Karlsson wrote:
> > Jakub, please take a look at your patches. The last one I had to
> > change slightly to make it fit with the new interface
> > xdp_get_umem_from_qid(). An added bonus with this function is that we,
> > in the future, can also use it from the driver to get a umem, thus
> > simplifying driver implementations (and later remove the umem from the
> > NDO completely). Björn will mail patches, at a later point in time,
> > using this in the i40e and ixgbe drivers, that removes a good chunk of
> > code from the ZC implementations.
>
> Nice, drivers which don't follow the prepare/commit model of handling
> reconfigurations will benefit!
>
> > I also made your code aware of Tx queues. If we create a socket that
> > only has a Tx queue, then the queue id will refer to a Tx queue id
> > only and could be larger than the available amount of Rx queues.
> > Please take a look at it.
>
> The semantics of Tx queue id are slightly unclear. To me XDP is
> associated with Rx, so the qid in driver context can only refer to
> Rx queue and its associated XDP Tx queue. It does not mean the Tx
> queue stack uses, like it does for copy fallback. If one doesn't have
> a Rx queue $id, there will be no associated XDP Tx queue $id (in all
> drivers but Intel, and virtio, which use per-CPU Tx queues making TX
> queue even more meaningless).
>
> Its to be seen how others implement AF_XDP. My general feeling is
> that we should only talk about Rx queues in context of driver XDP.
This is the way I see it. From an uapi point of view we can create a
socket that can only do Rx, only Tx or both. We then bind this socket
to a specific queue id on a device. If a packet is received on this
queue id it is sent (by the default xdpsock sample program) to the
socket. If a packet is sent on this socket it goes out on this same
queue id. If you have not registered an Rx ring (in user space) for
this socket, you cannot receive anything on this socket. And
conversely, if you have no Tx ring, you will not be able to send
anything.
But if we take a look at this from the driver perspective and the NDO
XDP_SETUP_XSK_UMEM, today it does not know anything about if Rx and Tx
rings have been setup in the socket. It will always initialize the HW
Rx and Tx queues of the supplied queue id. So with today's NDO
interface you will always get a Rx/Tx queue pair. In order to realize
the uapi above in an efficient manner and to support devices with more
Tx queues than Rx, we need to change the NDO.
Just as a note, in the applications I am used to work on, radio base
stations and other telecom apps, it is the common case to have many
more Tx queues than Rx queues just to be able to use scheduling,
shaping and other QoS features that are important on egress in those
systems. Therefore the interest in supporting Tx only queues. But
maybe this is just a weird case, do not know.
^ permalink raw reply
* Re: [PATCH bpf-next 0/3] nfp: bpf: support big map entries
From: Daniel Borkmann @ 2018-10-02 12:41 UTC (permalink / raw)
To: Jakub Kicinski, alexei.starovoitov; +Cc: netdev, oss-drivers
In-Reply-To: <20181002013034.8144-1-jakub.kicinski@netronome.com>
On 10/02/2018 03:30 AM, Jakub Kicinski wrote:
> Hi!
>
> This series makes the control message parsing for interacting
> with BPF maps more flexible. Up until now we had a hard limit
> in the ABI for key and value size to be 64B at most. Using
> TLV capability allows us to support large map entries.
>
> Jakub Kicinski (3):
> nfp: bpf: parse global BPF ABI version capability
> nfp: allow apps to request larger MTU on control vNIC
> nfp: bpf: allow control message sizing for map ops
>
> drivers/net/ethernet/netronome/nfp/bpf/cmsg.c | 70 ++++++++++++++++---
> drivers/net/ethernet/netronome/nfp/bpf/fw.h | 11 ++-
> drivers/net/ethernet/netronome/nfp/bpf/main.c | 52 ++++++++++++--
> drivers/net/ethernet/netronome/nfp/bpf/main.h | 11 +++
> drivers/net/ethernet/netronome/nfp/nfp_app.h | 4 ++
> .../ethernet/netronome/nfp/nfp_net_common.c | 14 +++-
> .../net/ethernet/netronome/nfp/nfp_net_ctrl.h | 2 +-
> 7 files changed, 142 insertions(+), 22 deletions(-)
>
Applied to bpf-next, thanks Jakub!
^ permalink raw reply
* Re: re iproute2 - don't return error on success fix
From: Or Gerlitz @ 2018-10-02 12:21 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stephen Hemminger, David Ahern, Linux Netdev List, Roi Dayan
In-Reply-To: <20180927125339.GA14666@orbyte.nwl.cc>
On Thu, Sep 27, 2018 at 3:53 PM Phil Sutter <phil@nwl.cc> wrote:
> On Thu, Sep 27, 2018 at 03:22:41PM +0300, Or Gerlitz wrote:
> > Something is still broken also after commit b45e300 "libnetlink: don't
> > return error on success" - when error is returned, the error code is
> > success..
> >
> > $ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
> > ip_flags nofirstfrag action drop && echo "success" || echo "failed"
> >
> > RTNETLINK answers: Operation not supported
> > success
>
> Hmm, I can't reproduce this. My HEAD is at the commit you mentioned:
>
> | % sudo ./tc/tc filter add dev d0 protocol ip parent ffff: flower skip_sw ip_flags nofirstfrag action drop
> | RTNETLINK answers: Operation not supported
> | We have an error talking to the kernel, -1
> | % echo $?
> | 2
>
> Are you sure you tested the right binary?
double checked now, seems broken on my end:
$ git log --oneline -3
b45e300 libnetlink: don't return error on success
5dc2204 testsuite: add libmnl
8804a8c Makefile: Add check target
$./tc/tc filter add dev enp33s0f0 protocol ip parent ffff: flower
skip_sw ip_flags frag action drop && echo "success" || echo "failed"
success
$ ./tc/tc filter add dev enp33s0f0 protocol ip parent ffff: flower
skip_sw ip_flags firstfrag action drop && echo "success" || echo
"failed"
RTNETLINK answers: Operation not supported
success
$ ./tc/tc filter show dev enp33s0f0 ingress
filter protocol ip pref 49152 flower chain 0
filter protocol ip pref 49152 flower chain 0 handle 0x1
eth_type ipv4
ip_flags frag
skip_sw
in_hw
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2018-10-02
From: David Miller @ 2018-10-02 18:47 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87ftxojn1l.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 02 Oct 2018 20:06:30 +0300
> here's the first pull request to net-next for 4.20. This is rather large
> due to mt76 refactoring and me not being able to send the pull request
> earlier, sorry about that.
>
> Most of this has been in linux-next for some time now so I'm hoping
> there should not be any nasty surprises, but please let me know if you
> have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH] declance: Fix continuation with the adapter identification message
From: David Miller @ 2018-10-02 18:32 UTC (permalink / raw)
To: macro; +Cc: netdev, linux-kernel
In-Reply-To: <alpine.LFD.2.21.1810021401530.5483@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Tue, 2 Oct 2018 14:23:45 +0100 (BST)
> Fix a commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
> continuation lines") regression with the `declance' driver, which caused
> the adapter identification message to be split between two lines, e.g.:
>
> declance.c: v0.011 by Linux MIPS DECstation task force
> tc6: PMAD-AA
> , addr = 08:00:2b:1b:2a:6a, irq = 14
> tc6: registered as eth0.
>
> Address that properly, by printing identification with a single call,
> making the messages now look like:
>
> declance.c: v0.011 by Linux MIPS DECstation task force
> tc6: PMAD-AA, addr = 08:00:2b:1b:2a:6a, irq = 14
> tc6: registered as eth0.
>
> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
> Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
Applied.
^ permalink raw reply
* Re: [PATCH] isdn/hisax: Fix fall-through annotation
From: David Miller @ 2018-10-02 18:24 UTC (permalink / raw)
To: gustavo; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <20181002102832.GA4873@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 2 Oct 2018 12:28:32 +0200
> Replace "fallthru" with a proper "fall through" annotation.
>
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* [PATCH net] ipv6: revert degradation in IPv6 Ready Logo test results
From: Mike Manning @ 2018-10-02 11:40 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
This reverts commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags
smaller than min mtu"). While one should not get fragments smaller than
the IPv6 minimum MTU, not handling crafted packets in the TAHI IPv6
conformance test suite (v6eval) for IPv6 Ready Logo results in 18
failures representing over 5% of the score.
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
The failures which are reverted by this fix are:
Section 1: RFC 2460 - IPv6 Specification
Test v6LC.1.2.4: Extension Header Processing Order
33-34
Test v6LC.1.3.1: Fragment Reassembly
67-72
Test v6LC.1.3.2: Reassembly Time Exceeded
73-76
Test v6LC.1.3.3: Fragment Header M-Bit Set, Payload Length Invalid
78
Section 5: RFC 4443 - ICMPv6
Test v6LC.5.1.6: Erroneous Header Field (Parameter Problem Generation)
20 Erroneous Header Field (Parameter Problem Generation)
Test v6LC.5.1.10: Error Condition With Multicast Destination
31 Part B: Echo Request Reassembly Timeout
Test v6LC.5.1.11: Error Condition With Non-Unique Source - Unspecified
35 Part C: Echo Request Reassembly Timeout (Routers and Hosts)
Test v6LC.5.1.12: Error Condition With Non-Unique Source - Multicast
40 Part C: Echo Request Reassembly Timeout (Routers and Hosts)
Test v6LC.5.1.13: Error Condition With Non-Unique Source Anycast (Routers Only)
45 Part C: Echo Request Reassembly Timeout
net/ipv6/netfilter/nf_conntrack_reasm.c | 4 ----
net/ipv6/reassembly.c | 4 ----
2 files changed, 8 deletions(-)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 8f68a518d9db..8c69c4fc78d8 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -559,10 +559,6 @@ int nf_ct_frag6_gather(struct net *net, struct sk_buff *skb, u32 user)
hdr = ipv6_hdr(skb);
fhdr = (struct frag_hdr *)skb_transport_header(skb);
- if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU &&
- fhdr->frag_off & htons(IP6_MF))
- return -EINVAL;
-
skb_orphan(skb);
fq = fq_find(net, fhdr->identification, user, hdr,
skb->dev ? skb->dev->ifindex : 0);
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 5c5b4f79296e..b4e558ab39fa 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -456,10 +456,6 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
return 1;
}
- if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU &&
- fhdr->frag_off & htons(IP6_MF))
- goto fail_hdr;
-
iif = skb->dev ? skb->dev->ifindex : 0;
fq = fq_find(net, fhdr->identification, hdr, iif);
if (fq) {
--
2.11.0
^ permalink raw reply related
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: Jiri Benc @ 2018-10-02 11:27 UTC (permalink / raw)
To: Christian Brauner; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002111831.j6ov4bqhy3zi3vj6@brauner.io>
On Tue, 2 Oct 2018 13:18:32 +0200, Christian Brauner wrote:
> I didn't find this in the linked thread.
Maybe it was suggested in another thread or in person on a conference,
I can't remember, it's too long ago, sorry.
> What I find interesting and convincing is one of Dave's points:
>
> "I'm beginning to wonder if we can just change this unilaterally to
> not ignore unrecognized attributes.
>
> I am increasingly certain that things that would "break" we wouldn't
> want to succeed anyways." [1]
It's unfortunate we can't do that. I'd like it.
> But a socket option or this header flag both sound acceptable to me. Was
> there any more detail on how a socket option would look like, i.e. an
> api proposal or something?
Look at how NETLINK_CAP_ACK and NETLINK_EXT_ACK is implemented.
Jiri
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: Christian Brauner @ 2018-10-02 11:18 UTC (permalink / raw)
To: Jiri Benc; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002130614.77856ff8@redhat.com>
On Tue, Oct 02, 2018 at 01:06:14PM +0200, Jiri Benc wrote:
> On Mon, 1 Oct 2018 17:28:29 -0700, David Ahern wrote:
> > Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
> > kernel that it believes it is sending the right header struct for the
> > dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
>
> Why is this limited to dumps? Other kind of netlink messages contain
> the common struct, too. When introducing such mechanism, please make it
> generic.
>
> Last time when we were discussing strict checking in netlink, it was
> suggested to add a socket option instead of adding NLM flags[1].
I didn't find this in the linked thread. What I find interesting and
convincing is one of Dave's points:
"I'm beginning to wonder if we can just change this unilaterally to
not ignore unrecognized attributes.
I am increasingly certain that things that would "break" we wouldn't
want to succeed anyways." [1]
:)
But a socket option or this header flag both sound acceptable to me. Was
there any more detail on how a socket option would look like, i.e. an
api proposal or something?
[1]: https://marc.info/?l=linux-netdev&m=144522081220166&w=2
> It makes a lot of sense: the number of flags is very limited and we'd
> run out of them pretty fast. It's not just the header structure that
> is currently checked sloppily. It's also attributes, flags in
> attributes, etc. We can't assign a flag to all of them.
>
> You should also consider a different name for the flag: it should
> reflect what the effect of the flag is. "Proper header" is not an
> effect, it's a requirement for the message to pass. The effect is
> enforced strict checking of the header.
>
> Jiri
>
> [1] https://marc.info/?l=linux-netdev&m=144492718118955
^ permalink raw reply
* Re: [PATCH] team: set IFF_SLAVE on team ports
From: Jiri Pirko @ 2018-10-02 11:12 UTC (permalink / raw)
To: Chas Williams; +Cc: Stephen Hemminger, Jan Blunck, LKML, netdev
In-Reply-To: <b3cf1799-7ee2-47b3-e9ed-98e41ae56853@gmail.com>
Mon, Oct 01, 2018 at 04:06:16PM CEST, 3chas3@gmail.com wrote:
>
>
>On 09/30/18 05:34, Jiri Pirko wrote:
>> Sun, Sep 30, 2018 at 11:38:05AM CEST, stephen@networkplumber.org wrote:
>> > On Sun, 30 Sep 2018 09:14:14 +0200
>> > Jiri Pirko <jiri@resnulli.us> wrote:
>> >
>> > > Thu, Sep 27, 2018 at 04:04:26PM CEST, 3chas3@gmail.com wrote:
>> > > >
>> > > >
>> > > > On 07/10/15 02:41, Jiri Pirko wrote:
>> > > > > Thu, Jul 09, 2015 at 05:36:55PM CEST, jblunck@infradead.org wrote:
>> > > > > > On Thu, Jul 9, 2015 at 12:07 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> > > > > > > Thu, Jul 09, 2015 at 11:58:34AM CEST, jblunck@infradead.org wrote:
>> > > > > > > > The code in net/ipv6/addrconf.c:addrconf_notify() tests for IFF_SLAVE to
>> > > > > > > > decide if it should start the address configuration. Since team ports
>> > > > > > > > shouldn't get link-local addresses assigned lets set IFF_SLAVE when linking
>> > > > > > > > a port to the team master.
>> > > > > > >
>> > > > > > > I don't want to use IFF_SLAVE in team. Other master-slave devices are
>> > > > > > > not using that as well, for example bridge, ovs, etc.
>> > > > > >
>> > > > > > Maybe they need to get fixed too. I've used that flag because it is
>> > > > > > documented as
>> > > > > > a "slave of a load balancer" which describes what a team port is.
>> > > > > >
>> > > > > > > I think that this should be fixed in addrconf_notify. It should lookup
>> > > > > > > if there is a master on top and bail out in that case.
>> > > > > >
>> > > > > > There are other virtual interfaces that have a master assigned and want to
>> > > > > > participate in IPv6 address configuration.
>> > > > >
>> > > > > Can you give me an example?
>> > > >
>> > > > I would like to revisit this patch (yes, I know it has been a while). I
>> > > > believe the VRF implementation uses master to group the interfaces under
>> > > > a single interface.
>> > > >
>> > > > I don't see a reason not to use IFF_SLAVE since team and bonding are fairly
>> > > > similar.
>> > >
>> > > Again, why do you need team port to have IFF_SLAVE flag? What do you
>> > > want to achieve
>> >
>> > Without setting this flag IPv6 will try and make a link specific address.
You are talking about addrconf_notify() right? Easy to fix to check
something more convenient. Like netif_is_lag_port() if you want to avoid
it for bond/team. netif_is_ovs_port(), netif_is_bridge_port() etc. Lot's
of helpers to cover this.
>>
>> Why is it not an issue with bridge, ovs, and other master-slave devices?
>>
>
>It very well might be an issue for bridge and ovs. Other master-slave
>devices include the existing VRF implementation in the kernel and those slave
>interfaces will certainly want to use IPv6.
>
>However, IFF_SLAVE has a specific meaning:
>
>./include/uapi/linux/if.h: * @IFF_SLAVE: slave of a load balancer. Volatile.
I know that some userspace apps are using this flag to determine a
"bonding slave". I don't think that they care much about eql...
>
>The bonding driver is not the only user:
>
>./drivers/net/eql.c:#define eql_is_slave(dev) ((dev->flags & IFF_SLAVE) ==
>IFF_SLAVE)
>./drivers/net/eql.c: slave->dev->flags &= ~IFF_SLAVE;
>./drivers/net/eql.c: slave->dev->flags |= IFF_SLAVE;
>
>The team driver would like to use this same flag since it is a load balancer
>as well. The side effect of not assigning IPv6 is a bonus. The fact that
No, please leave IFF_SLAVE as it is. Both kernel and userspace have
their clear indications right now about the master/slave relationships.
>bridges and ovs are also likely broken is a different issue. Should there be
>a another flag that says "layer 2 only"? Very possibly, but that is
>something all these interfaces should be using to include bonding, team, eql,
>obs, bridge etc. That's not a reasonable objection to labeling the team
>slave as slaves since they are literally slaves of a load balancer.
>
>
>
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Christian Brauner @ 2018-10-02 11:09 UTC (permalink / raw)
To: Jiri Benc; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002130749.422272fc@redhat.com>
On Tue, Oct 02, 2018 at 01:07:49PM +0200, Jiri Benc wrote:
> On Tue, 2 Oct 2018 13:03:00 +0200, Christian Brauner wrote:
> > Well, it's a namespace filter that's how I saw it.
>
> That would imply that without it, you get data from all name spaces
> (= unfiltered by name space), which is not what's happening :-)
Yeah, you convinced me already. I'm not one to argue for the sake of
winning an argument (At least I hope so.) :)
Christian
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Jiri Benc @ 2018-10-02 11:07 UTC (permalink / raw)
To: Christian Brauner; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002110259.tqh4uz46g3ihakir@brauner.io>
On Tue, 2 Oct 2018 13:03:00 +0200, Christian Brauner wrote:
> Well, it's a namespace filter that's how I saw it.
That would imply that without it, you get data from all name spaces
(= unfiltered by name space), which is not what's happening :-)
Jiri
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 01/25] net/netlink: Pass extack to dump callbacks
From: Christian Brauner @ 2018-10-02 11:07 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, jbenc, stephen, David Ahern
In-Reply-To: <20181002002851.5002-2-dsahern@kernel.org>
On Mon, Oct 01, 2018 at 05:28:27PM -0700, David Ahern wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Pass extack to dump callbacks by adding extack to netlink_dump_control,
> transferring to netlink_callback and adding to the netlink_dump. Update
> rtnetlink as the first user. Update netlink_dump to add any message after
> the dump_done_errno.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
This makes sense to me as it would allow us to report back more
meaningful errors to userspace.
> ---
> include/linux/netlink.h | 2 ++
> net/core/rtnetlink.c | 1 +
> net/netlink/af_netlink.c | 20 +++++++++++++++-----
> 3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/netlink.h b/include/linux/netlink.h
> index 71f121b66ca8..8fc90308a653 100644
> --- a/include/linux/netlink.h
> +++ b/include/linux/netlink.h
> @@ -176,6 +176,7 @@ struct netlink_callback {
> void *data;
> /* the module that dump function belong to */
> struct module *module;
> + struct netlink_ext_ack *extack;
> u16 family;
> u16 min_dump_alloc;
> unsigned int prev_seq, seq;
> @@ -197,6 +198,7 @@ struct netlink_dump_control {
> int (*done)(struct netlink_callback *);
> void *data;
> struct module *module;
> + struct netlink_ext_ack *extack;
> u16 min_dump_alloc;
> };
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 35162e1b06ad..da91b38297d3 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -4689,6 +4689,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
> .dump = dumpit,
> .min_dump_alloc = min_dump_alloc,
> .module = owner,
> + .extack = extack
> };
> err = netlink_dump_start(rtnl, skb, nlh, &c);
> /* netlink_dump_start() will keep a reference on
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index e3a0538ec0be..7094156c94f0 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -129,7 +129,7 @@ static const char *const nlk_cb_mutex_key_strings[MAX_LINKS + 1] = {
> "nlk_cb_mutex-MAX_LINKS"
> };
>
> -static int netlink_dump(struct sock *sk);
> +static int netlink_dump(struct sock *sk, struct netlink_ext_ack *extack);
>
> /* nl_table locking explained:
> * Lookup and traversal are protected with an RCU read-side lock. Insertion
> @@ -1981,7 +1981,7 @@ static int netlink_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>
> if (nlk->cb_running &&
> atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf / 2) {
> - ret = netlink_dump(sk);
> + ret = netlink_dump(sk, NULL);
> if (ret) {
> sk->sk_err = -ret;
> sk->sk_error_report(sk);
> @@ -2168,7 +2168,7 @@ EXPORT_SYMBOL(__nlmsg_put);
> * It would be better to create kernel thread.
> */
>
> -static int netlink_dump(struct sock *sk)
> +static int netlink_dump(struct sock *sk, struct netlink_ext_ack *extack)
> {
> struct netlink_sock *nlk = nlk_sk(sk);
> struct netlink_callback *cb;
> @@ -2222,8 +2222,11 @@ static int netlink_dump(struct sock *sk)
> skb_reserve(skb, skb_tailroom(skb) - alloc_size);
> netlink_skb_set_owner_r(skb, sk);
>
> - if (nlk->dump_done_errno > 0)
> + if (nlk->dump_done_errno > 0) {
> + cb->extack = extack;
> nlk->dump_done_errno = cb->dump(skb, cb);
> + cb->extack = NULL;
> + }
>
> if (nlk->dump_done_errno > 0 ||
> skb_tailroom(skb) < nlmsg_total_size(sizeof(nlk->dump_done_errno))) {
> @@ -2246,6 +2249,12 @@ static int netlink_dump(struct sock *sk)
> memcpy(nlmsg_data(nlh), &nlk->dump_done_errno,
> sizeof(nlk->dump_done_errno));
>
> + if (extack && extack->_msg && nlk->flags & NETLINK_F_EXT_ACK) {
> + nlh->nlmsg_flags |= NLM_F_ACK_TLVS;
> + if (!nla_put_string(skb, NLMSGERR_ATTR_MSG, extack->_msg))
> + nlmsg_end(skb, nlh);
> + }
> +
> if (sk_filter(sk, skb))
> kfree_skb(skb);
> else
> @@ -2307,6 +2316,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
> cb->module = control->module;
> cb->min_dump_alloc = control->min_dump_alloc;
> cb->skb = skb;
> + cb->extack = control->extack;
>
> if (control->start) {
> ret = control->start(cb);
> @@ -2319,7 +2329,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
>
> mutex_unlock(nlk->cb_mutex);
>
> - ret = netlink_dump(sk);
> + ret = netlink_dump(sk, cb->extack);
>
> sock_put(sk);
>
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER_HDR flag
From: Jiri Benc @ 2018-10-02 11:06 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, christian, stephen, David Ahern
In-Reply-To: <20181002002851.5002-4-dsahern@kernel.org>
On Mon, 1 Oct 2018 17:28:29 -0700, David Ahern wrote:
> Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
> kernel that it believes it is sending the right header struct for the
> dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
Why is this limited to dumps? Other kind of netlink messages contain
the common struct, too. When introducing such mechanism, please make it
generic.
Last time when we were discussing strict checking in netlink, it was
suggested to add a socket option instead of adding NLM flags[1].
It makes a lot of sense: the number of flags is very limited and we'd
run out of them pretty fast. It's not just the header structure that
is currently checked sloppily. It's also attributes, flags in
attributes, etc. We can't assign a flag to all of them.
You should also consider a different name for the flag: it should
reflect what the effect of the flag is. "Proper header" is not an
effect, it's a requirement for the message to pass. The effect is
enforced strict checking of the header.
Jiri
[1] https://marc.info/?l=linux-netdev&m=144492718118955
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Christian Brauner @ 2018-10-02 11:03 UTC (permalink / raw)
To: Jiri Benc; +Cc: David Ahern, netdev, davem, stephen, David Ahern
In-Reply-To: <20181002125425.35e96876@redhat.com>
On Tue, Oct 02, 2018 at 12:54:25PM +0200, Jiri Benc wrote:
> On Mon, 1 Oct 2018 17:28:28 -0700, David Ahern wrote:
> > Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
> > into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
> > NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
>
> IFA_TARGET_NETNSID is not a filter.
Well, it's a namespace filter that's how I saw it.
>
> "Filter" returns a subset of the results. It's kind of optimization
That's an argument I can buy.
> when one is interested only in some data but not all of them. Instead
> of dumping everything, going through the results and picking only the
> data one is interested in, it's better to pass a filter and get only
> the relevant data. But you're not really required to: you can filter in
> your app.
>
> By contrast, IFA_TARGET_NETNSID returns a completely different set of
> data. It's impossible to not set it and filter the results in your app.
>
> As the consequence, IFA_TARGET_NETNSID must not set NLM_F_DUMP_FILTERED
> (if not complemented by a real filter).
>
> I understand that you want to differentiate between data dumped without
> and with IFA_TARGET_NETNSID present. But we already have that: the
> IFA_TARGET_NETNSID attribute is returned back in the latter case.
>
> Nacked-by: Jiri Benc <jbenc@redhat.com>
>
> Jiri
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to push inet6_fill_args to in6_dump_addrs
From: Jiri Benc @ 2018-10-02 10:54 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, christian, stephen, David Ahern
In-Reply-To: <20181002002851.5002-3-dsahern@kernel.org>
On Mon, 1 Oct 2018 17:28:28 -0700, David Ahern wrote:
> Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
> into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
> NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
IFA_TARGET_NETNSID is not a filter.
"Filter" returns a subset of the results. It's kind of optimization
when one is interested only in some data but not all of them. Instead
of dumping everything, going through the results and picking only the
data one is interested in, it's better to pass a filter and get only
the relevant data. But you're not really required to: you can filter in
your app.
By contrast, IFA_TARGET_NETNSID returns a completely different set of
data. It's impossible to not set it and filter the results in your app.
As the consequence, IFA_TARGET_NETNSID must not set NLM_F_DUMP_FILTERED
(if not complemented by a real filter).
I understand that you want to differentiate between data dumped without
and with IFA_TARGET_NETNSID present. But we already have that: the
IFA_TARGET_NETNSID attribute is returned back in the latter case.
Nacked-by: Jiri Benc <jbenc@redhat.com>
Jiri
^ permalink raw reply
* Re: [PATCH net-next] netfilter: xt_quota: fix the behavior of xt_quota module
From: Pablo Neira Ayuso @ 2018-10-02 10:52 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Chenbo Feng, Linux NetDev, netfilter-devel, kernel-team,
Lorenzo Colitti, Chenbo Feng
In-Reply-To: <20181002105125.uv7mcitvaalpjueo@salvia>
On Tue, Oct 02, 2018 at 12:51:25PM +0200, Pablo Neira Ayuso wrote:
> On Tue, Oct 02, 2018 at 03:38:24AM -0700, Maciej Żenczykowski wrote:
> > > Well, you will need a kernel + userspace update anyway, right?
> >
> > It's true you need new iptables userspace to *see* during dump and/or
> > manually *set* during restore the remain counter.
> >
> > However, (and I believe Chenbo tested this) just a new kernel is
> > enough to fix the problem of modifications within the table resetting
> > the counter.
> > This is because the data gets copied out of kernel and back into
> > kernel by old iptables without any further modifications.
> > ie. the new kernel not clearing the field on copy to userspace and
> > honouring it on copy to kernel is sufficient.
>
> I see, Willem removed this behaviour in newer kernels. The private
> area is now zeroed, is that what you mean right? So I guess this
> cannot be done transparently.
>
> Anyway, I think the --remain approach to fix this longstanding
> problem from iptables :-).
Argh, broken sentence: I mean, I think it's the way to go for
iptables.
^ permalink raw reply
* Re: [PATCH net-next] netfilter: xt_quota: fix the behavior of xt_quota module
From: Pablo Neira Ayuso @ 2018-10-02 10:51 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Chenbo Feng, Linux NetDev, netfilter-devel, kernel-team,
Lorenzo Colitti, Chenbo Feng
In-Reply-To: <CANP3RGf4pnPYiLoLNqULz-ELUT18qDctmi3kUw6qpkppwtcXmg@mail.gmail.com>
On Tue, Oct 02, 2018 at 03:38:24AM -0700, Maciej Żenczykowski wrote:
> > Well, you will need a kernel + userspace update anyway, right?
>
> It's true you need new iptables userspace to *see* during dump and/or
> manually *set* during restore the remain counter.
>
> However, (and I believe Chenbo tested this) just a new kernel is
> enough to fix the problem of modifications within the table resetting
> the counter.
> This is because the data gets copied out of kernel and back into
> kernel by old iptables without any further modifications.
> ie. the new kernel not clearing the field on copy to userspace and
> honouring it on copy to kernel is sufficient.
I see, Willem removed this behaviour in newer kernels. The private
area is now zeroed, is that what you mean right? So I guess this
cannot be done transparently.
Anyway, I think the --remain approach to fix this longstanding
problem from iptables :-).
> So iptables-save | iptables-restore doesn't work, but iptables -A foo does.
>
> (currently iptables -t X -{A,D} foo clears all xt_quota counters in
> table X even when foo is utterly unrelated)
>
> >> I mean: Instead of using atomic64_set() to set the counter to 1 once
> >> we went over quota,
> >
> > incomplete sentence, sorry:
> >
> > I mean: Instead of using atomic64_set() to set the counter to 1 once
> > we go overquota, we just keep updating 'consumed' bytes.
>
> I guess it's a fair point that with a u64 we won't ever realistically
> overflow the number of sent bytes, so this could be a running counter
> of matched bytes...
>
> and we don't even need to update it if it was over the quota when we
> first looked at it, so we'll go over by at most # of cpus * max size
> of gso packet bytes.
>
> > ie. we don't express things in 'remaining bytes' logic, but we account
> > for 'bytes we already consumed'. So we never go negative - I know
> > understand what you mean about -1... I think we are each other
> > thinking from our respective approach proposal.
>
> I guess our decision was probably driven by xt_quota2 use on android
> where infinite quota is often used as a temporary placeholder.
I see, thanks for explaining.
Thanks.
^ permalink raw reply
* Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels
From: Wolfgang Walter @ 2018-10-02 17:34 UTC (permalink / raw)
To: Florian Westphal
Cc: Steffen Klassert, David Miller, netdev, linux-kernel, torvalds,
christophe.gouault
In-Reply-To: <20181002145616.pwdhbmafgsihbxvm@breakpoint.cc>
Am Dienstag, 2. Oktober 2018, 16:56:16 schrieb Florian Westphal:
> Wolfgang Walter <linux@stwm.de> wrote:
> > Since my last reply to this message I didn't get a reply: is there any
> > progress how to fix this performance regression I missed?
>
> Did you test/experiment with hthresh config option?
I did. It did not improve the situation.
I suppose that is because our masks range from /16 to /30 and excpecially have
for example /16 <=> /8 and vice versa.
When forwarding, every policy A => B also implies that you add a policy B =>
A.
I'm not familiar when the policy database is consulted, but I think it now has
to for every not encrypted paket, and for those all rules have to be
consulted. And unencrypted traffic is a large part of the traffic on that
router.
That is: for unencrypted traffic neither the buckets of the hash nor the
inexact list may be large.
>
> > Or are we stuck here with longterm kernel 4.9 for a long time?
>
> I'm experimenting with per-dst inexact lists in an rbtree but
> this will take time.
Hmm, I doubt that this is worth the effort. And certainly not that easy
correctly done, as it still would have to obey the original order of the rules
(their priority).
You may have a lot of rules of the form say
10.0.0.0/16 <=> 10.1.0.0/29 encrypt ....
10.0.0.0/16 <=> 10.1.0.8/29 encrypt ....
....
And things like that.
Also, you get something like that
10.0.1.0/24 <=> 10.0.2.0/29 allow
10.0.0.0/16 <=> 10.0.2.0/24 encrypt
0.0.0.0 <=> 10.0.2.0/16 block
And people may use source port and/or destination port or protocol
(tcp/udp/imcp) to further tailor there ruleset.
Here is the approach HiPAC took for packet classification
https://pdfs.semanticscholar.org/a0bb/9d31e2499fb659c9e0d9544072d2f3c25079.pdf
https://pdfs.semanticscholar.org/0dea/8ee87f596f200de2722cbe9480610dd1a0db.pdf
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
^ permalink raw reply
* Re: [PATCH net-next] netfilter: xt_quota: fix the behavior of xt_quota module
From: Maciej Żenczykowski @ 2018-10-02 10:38 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Chenbo Feng, Linux NetDev, netfilter-devel, kernel-team,
Lorenzo Colitti, Chenbo Feng
In-Reply-To: <20181002101556.lpvn4kz7xgv2at3f@salvia>
> Well, you will need a kernel + userspace update anyway, right?
It's true you need new iptables userspace to *see* during dump and/or
manually *set* during restore the remain counter.
However, (and I believe Chenbo tested this) just a new kernel is
enough to fix the problem of modifications within the table resetting
the counter.
This is because the data gets copied out of kernel and back into
kernel by old iptables without any further modifications.
ie. the new kernel not clearing the field on copy to userspace and
honouring it on copy to kernel is sufficient.
So iptables-save | iptables-restore doesn't work, but iptables -A foo does.
(currently iptables -t X -{A,D} foo clears all xt_quota counters in
table X even when foo is utterly unrelated)
>> I mean: Instead of using atomic64_set() to set the counter to 1 once
>> we went over quota,
>
> incomplete sentence, sorry:
>
> I mean: Instead of using atomic64_set() to set the counter to 1 once
> we go overquota, we just keep updating 'consumed' bytes.
I guess it's a fair point that with a u64 we won't ever realistically
overflow the number of sent bytes, so this could be a running counter
of matched bytes...
and we don't even need to update it if it was over the quota when we
first looked at it, so we'll go over by at most # of cpus * max size
of gso packet bytes.
> ie. we don't express things in 'remaining bytes' logic, but we account
> for 'bytes we already consumed'. So we never go negative - I know
> understand what you mean about -1... I think we are each other
> thinking from our respective approach proposal.
I guess our decision was probably driven by xt_quota2 use on android
where infinite quota is often used as a temporary placeholder.
^ permalink raw reply
* pull-request: wireless-drivers-next 2018-10-02
From: Kalle Valo @ 2018-10-02 17:06 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's the first pull request to net-next for 4.20. This is rather large
due to mt76 refactoring and me not being able to send the pull request
earlier, sorry about that.
Most of this has been in linux-next for some time now so I'm hoping
there should not be any nasty surprises, but please let me know if you
have any problems.
Kalle
The following changes since commit 050cdc6c9501abcd64720b8cc3e7941efee9547d:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-08-27 11:59:39 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2018-10-02
for you to fetch changes up to 08b0109eea36d71f87b863045d91bbcee98758bd:
Merge tag 'iwlwifi-next-for-kalle-2018-09-28' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next (2018-10-01 18:49:48 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.20
First set of new features for 4.20. mt76 driver is going through major
refactoring and that's why there are so many mt76 patches. iwlwifi is
also under heavy development and smaller changes to other drivers.
Also wireless-drivers was merged to fix a conflict between the two trees.
Major changes:
ath10k
* limit available channels via DT ieee80211-freq-limit
wil6210
* add 802.11r Fast Roaming support for AP and station modes
* add support for channel 4
iwlwifi
* new FW API handling
* some improvements in the PCI recovery mechanism
* enable a new scanning feature;
* continued work on HE (mostly radiotap)
* TKIP implementation in new devices
* work continues for new 22560 hardware
mt76
* add support for Alfa AWUS036ACM
* lots of refactoring to make it easier to add new hardware support
* prepare for adding mt76x0e (pci-e variant) support
* add CONFIG_MT76x0E kconfig symbol
brcmfmac
* add support CYW89342 mini-PCIe device
* add 4-way handshake offload detection for FT-802.1X
* enable NL80211_EXT_FEATURE_CQM_RSSI_LIST
* fix for proper support of 160MHz bandwidth
rtl8xxxu
* add rtl8188ctv support
----------------------------------------------------------------
Ahmad Masri (1):
wil6210: add FT roam support for AP and station
Aleksei Mamlin (1):
rtl8xxxu: Add rtl8188ctv support
Alexei Avshalom Lazar (1):
wil6210: add support for channel 4
Arend van Spriel (2):
brcmfmac: fix for proper support of 160MHz bandwidth
brcmfmac: increase buffer for obtaining firmware capabilities
Avraham Stern (3):
iwlwifi: set the tid for non-QOS frames to zero
iwlwifi: mvm: Send LQ command as async when necessary
iwlwifi: mvm: set wep key for all stations in soft ap mode
Ayala Beker (2):
iwlwifi: mvm: skip EBS in low latency mode while fragmented scan isn't supported
iwlwifi: mvm: activate fragmented EBS in case of fragmented scan
Chung-Hsien Hsu (2):
brcmfmac: add FT-based AKMs in brcmf_set_key_mgmt() for FT support
brcmfmac: add 4-way handshake offload detection for FT-802.1X
Colin Ian King (3):
ath9k: remove unused array firstep_table
orinoco: remove unused array encaps_hdr and macro ENCAPS_OVERHEAD
b43: fix spelling mistake "hw_registred" -> "hw_registered"
Dan Carpenter (2):
libertas_tf: prevent underflow in process_cmdrequest()
rt2x00: use simple_read_from_buffer()
David Spinadel (1):
iwlwifi: mvm: Support TKIP on gen2 data path
Dedy Lansky (2):
wil6210: drop Rx multicast packets that are looped-back to STA
wil6210: fix invalid memory access for rx_buff_mgmt debugfs
Dreyfuss, Haim (1):
iwlwifi: mvm: cleanup dead code on resume flow for non unified image.
Emmanuel Grumbach (5):
iwlwifi: improve the flow when a NIC is disconnected
iwlwifi: mvm: send BCAST management frames to the right station
iwlwifi: mvm: fix a comment about the SP length
iwlwifi: dbg: don't crash if the firmware crashes in the middle of a debug dump
iwlwifi: mvm: remove support for adjacent channel compensation
Erel Geron (3):
iwlwifi: mvm: support Coex Schema 2
iwlwifi: fix non_shared_ant for 22000 devices
iwlwifi: mvm: TLC support for Coex Schema 2
Felix Fietkau (2):
ath9k: fix tx99 with monitor mode interface
mt76: use a per rx queue page fragment cache
Ganapathi Bhat (2):
mwifiex: do no submit URB in suspended state
mwifex: free rx_cmd skb in suspended state
Geert Uytterhoeven (1):
mt76: Fix comparisons with invalid hardware key index
Golan Ben Ami (9):
iwlwifi: add required include to iwl-fh.h
iwlwifi: pcie: allow using tx init for other queues but the command queue
iwlwifi: pcie: make non-static hcmd and rx code
iwlwifi: remove FSF's address from the license notice
iwlwifi: pcie: store the default rxq number
iwlwifi: pcie: make gen2 of apm_init non-static
iwlwifi: refactor txq_alloc for supporting more command type
iwlwifi: pcie: fit reclaim msg to MAX_MSG_LEN
iwlwifi: configure power scheme to balanced for 22560 devices
Gregory Greenman (1):
iwlwifi: mvm: add NOA and CSA to a probe response
Gustavo A. R. Silva (2):
ath10k: use struct_size() in kzalloc()
orinoco_usb: fix spelling mistake in fall-through annotation
Haim Dreyfuss (1):
iwlwifi: mvm: support new reduce tx power FW API.
Ido Yariv (1):
iwlwifi: Add missing 11n disable module parameter check
Igor Mitsyanko (11):
qtnfmac_pcie: do not store FW name in driver state structure
qtnfmac_pcie: move Pearl pcie sources to pcie-specific directory
qtnfmac_pcie: rename private Pearl PCIe state structure
qtnfmac_pcie: indicate pearl-specific structures by their names
qtnfmac_pcie: pearl: rename spinlock tx0_lock to tx_lock
qtnfmac_pcie: separate platform-independent PCIe structure
qtnfmac_pcie: rename platform-specific functions
qtnfmac: add missing header includes to bus.h
qtnfmac_pcie: extract platform-independent PCIe code
qtnfmac: wait for FW load work to finish at PCIe remove
qtnfmac_pcie: check for correct CHIP ID at pcie probe
Igor Stoppa (1):
wireless: remove unnecessary unlikely()
Ilan Peer (1):
iwlwifi: mvm: Allow TKIP for AP mode
Jia-Shyr Chuang (1):
brcmfmac: add CYW89342 mini-PCIe device
Johannes Berg (19):
iwlwifi: remove dump_regs() from transport ops
iwlwifi: don't WARN on trying to dump dead firmware
iwlwifi: mvm: implement extended HE-MU sniffer API
iwlwifi: mvm: put LTF symbol size into HE radiotap
iwlwifi: mvm: properly decode HE GI duration
iwlwifi: mvm: report # of LTF symbols for extended range SU PPDUs
iwlwifi: mvm: remove channel 2 from HE radiotap if not applicable
iwlwifi: mvm: decode HE TB PPDU data
Revert "iwlwifi: allow memory debug TLV to specify the memory type"
iwlwifi: RX API: remove unnecessary anonymous struct
iwlwifi: mvm: report RU offset is known
iwlwifi: remove ucode error tracepoint
iwlwifi: api: annotate compressed BA notif array sizes
iwlwifi: pcie: gen2: pull adding frags to helper routine
iwlwifi: pcie: gen2: build A-MSDU only for GSO
iwlwifi: pcie: tx: unify TFD unmapping
iwlwifi: pcie: tx: pull tracing out of iwl_fill_data_tbs()
iwlwifi: pcie: support transmitting SKBs with fraglist
iwlwifi: fix LED command capability bit
Kalle Valo (5):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Merge tag 'iwlwifi-next-for-kalle-2018-08-31' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge wireless-drivers into wireless-drivers-next
Merge tag 'mt76-for-kvalo-2018-09-19' of https://github.com/nbd168/wireless
Merge tag 'iwlwifi-next-for-kalle-2018-09-28' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Karthick Gopalasubramanian (1):
wil6210: remove reset file from debugfs
Kevin Lo (1):
rtlwifi: remove set but unused variables
Kristian Evensen (1):
mt76: Enable NL80211_EXT_FEATURE_CQM_RSSI_LIST
Larry Finger (1):
rtl8187: Fix warning generated when strncpy() destination length matches the sixe argument
Liad Kaufman (2):
iwlwifi: mvm: add bss color to radiotap
iwlwifi: mvm: add support for RX_AMPDU_EOF bit for HE SU
Lorenzo Bianconi (76):
mt76x2u: run device cleanup routine if resume fails
mt76: verify evt type in usb mcu response
mt76: move mt76_reg_pair definition in mt76.h
mt76: split __mt76u_mcu_send_msg and mt76u_mcu_send_msg routines
mt76: move mt76x2u_mcu_deinit routine in mt76-usb module
mt76: add multiple regs read support to usb_mcu layer
mt76x0: use mt76u_init for bus initialization
mt76x0: remove mt76x0_vendor_reset routine
mt76x0: remove mt76x0_vendor_single_wr routine
mt76x0: remove mt76x0_mcu_msg_alloc routine
mt76x0: use shared mt76 usb mcu completion
mt76x0: remove mt76x0_complete_urb routine
mt76x0: remove mt76x0_vendor_request routine
mt76x0: remove unused mt76x0_wait_asic_ready routine
mt76x0: use mt76u_mcu_send_msg utility routine to send fw cmds
mt76x0: remove unused mt76x0_mcu structure
mt76x0: use mt76u_mcu_fw_send_data for fw uploading
mt76x0: remove unused routines for usb_buff alloc/free
mt76x2: change mt76x2_tx_complete routine signature
mt76: move mt76x2_tx_complete routine in mt76x02-lib module
mt76: move mt76x2u_remove_dma_hdr in mt76x02-lib module
mt76: move mt76x2u_tx_complete_skb in mt76x02-lib moudule
mt76: move mt76_qsel definition in dma.h
mt76: move mt76x2u_set_txinfo in mt76x02-lib module
mt76x0: introduce mt76x0_tx_prepare_skb routine
mt76: move mt76x2u_tx_status_data in mt76x02-lib module
mt76x0: disable usb rx bulk aggregation
mt76x0: mark device as running in mt76x0_start
mt76x0: simplify mt76_mac_process_rx signature
mt76x0: add mt76x0_queue_rx_skb routine
mt76x0: init mt76_driver_ops callbacks
mt76x0: use mt76_alloc_device for device allocation
mt76x0: unify tx/rx datapath with mt76x2u driver
mt76x0: stop stat workqueue at hw stop
mt76x0: set max fragments size
mt76x0: remove unused dma.c source file
mt76x0: remove unused stat work_queue
mt76x0: remove unused {tx/rx}_queue definitions
mt76x0: remove unused mt76x0_tx_status routine
mt76x0: remove unused endpoint definitions
mt76x0: remove unused stat_work
mt76x0: enable per-sta tx queueing
mt76x0: init hw capabilities
mt76: remove unused MT76_MORE_STATS state
mt76x0: remove mt76x0_stop_hardware routine
mt76: move mt76 rate definitions in mt76x02-lib module
mt76x0: alloc mcu buffers first in mt76x0_mcu_cmd_init
mt76x0: fix memory leak during hw probe
mt76x0: move stop related routines in mt76x0_mac_stop
mt76x0: move mt76x0_init_hardware in mt76x0_register_device
mt76x0: do not free/alloc buffers during suspend/resume
mt76x0: remove has_{2,5}ghz fields of mt76x0_eeprom_params
mt76x0: use mt76_register_device for device registration
mt76x0: run vco calibration for each channel configuration
mt76: move mt76x0 and mt76x2 mcu shared defs in mt76x02_mcu.h
mt76: add mt76_mcu_ops data structure for mcu related pointers
mt76: usb: use common helpers for mcu_alloc_msg()/mcu_send_msg()
mt76: usb: move mt76x02 mcu code in mt76x02-usb module
mt76: usb: move mt76u_skb_dma_info in mt76x02_usb_core.c
mt76x02: move TXD/RXD/MCU definitions in mt76x02_dma.h
mt76x02: add static qualifier to mt76x02_remove_dma_hdr
mt76: usb: remove skb check in mt76x{0,2}u mcu routines
mt76x2: use mt76_dev instead of mt76x2_dev in mt76x2_tx_queue_mcu
mt76x2: remove leftover mt76u_buf data structure in mt76x2_mcu
mt76: introduce mmio data structure in mt76_dev
mt76: move __iomem regs in mt76_mmio
mt76x2: use mt76_dev instead of mt76x2_dev in mt76x2_mcu_msg_send
mt76x2: use common helpers for mcu_alloc_msg()/mcu_send_msg()
mt76: unify firmware header between mt76x0 and mt76x2
mt76: move mt76{0,2} mcu shared code in mt76x02_mcu.c
mt76x2: move mt76x2 mcu shared code in mt76x2_mcu_common.c
mt76: move shared mcu_calibrate routine in mt76x02-lib module
mt76x2: move mt76x2_phy_tssi_compensate in mt76x2-common module
mt76x0: remove mcu source file
mt76x0: remove unused usb header file
mt76x0: usb: remove mt76_fw definition
Luca Coelho (6):
iwlwifi: remove unused TLC debugging commands
iwlwifi: mvm: remove duplicate if in iwl_mvm_setup_connection_keep()
iwlwifi: mvm: protect D0i3 code behind CONFIG_PM
iwlwifi: mvm: support new WoWLAN status FW API
iwlwifi: remove all occurrences of the FSF address paragraph
iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF modules
Martin Willi (1):
ath10k: schedule hardware restart if WMI command times out
Matt Chen (1):
iwlwifi: pcie: avoid unnecessary work if NIC is disconnected
Maya Erez (4):
wil6210: set edma variables only for Talyn-MB devices
wil6210: allocate rx reorder buffer only if rx reorder is enabled
wil6210: prevent usage of tx ring 0 for eDMA
wil6210: fix RX buffers release and unmap
Mordechay Goodstein (3):
iwlwifi: turn timestamp marker cmd off by default
iwlwifi: enable reading the value of delay in timestamp_marker cmd
iwlwifi: add 80211 hdr offset to trace data
Naftali Goldstein (4):
iwlwifi: runtime: avoid calling debugfs read functions more than once
iwlwifi: mvm: always init rs_fw with 20MHz bandwidth rates
iwlwifi: rs-fw: enable STBC in he correctly
iwlwifi: rs-fw: support dcm
Nathan Chancellor (4):
ipw2x00: Remove unnecessary parentheses
rsi: Remove unnecessary boolean condition
ath5k: Remove unused BUG_ON
rtlwifi: btcoex: Use proper enumerated types for Wi-Fi only interface
Rajat Jain (1):
iwlwifi: pcie: Fail fast if HW is inaccessible at probe
Rakesh Pillai (1):
ath10k: skip resetting rx filter for WCN3990
Rasmus Villemoes (1):
brcmfmac: fix wrong strnchr usage
Rosen Penev (1):
mt76x2u: Add support for Alfa AWUS036ACM
Sara Sharon (11):
iwlwifi: mvm: move he RX handling to a separate function
iwlwifi: mvm: move he RX handling to a separate function
iwlwifi: drop packets with bad status in CD
iwlwifi: mvm: fix BAR seq ctrl reporting
iwlwifi: mvm: avoid sending too many BARs
iwlwifi: pcie: set interrupt coalescing also for gen2
iwlwifi: fw: add a restart FW debug function
iwlwifi: fw: stop and start debugging using host command
iwlwifi: pcie: read correct prph address for newer devices
iwlwifi: mvm: use correct FIFO length
iwlwifi: pcie: add infrastructure for multiple debug buffers
Shahar S Matityahu (4):
iwlwifi: add d3 debug data support
iwlwifi: change monitor DMA to be coherent
iwlwifi: avoid code duplication in stopping fw debug data recording
iwlwifi: debug flow cleanup
Shaul Triebitz (4):
iwlwifi: iwlmvm: fix typo when checking for TX Beamforming
iwlwifi: mvm: enable sending HE_AIR_SNIFFER command via debugfs
iwlwifi: mvm: do not override amsdu size user settings
iwlwifi: pcie: set RB size according to user settings
Siva Rebbagondla (2):
rsi: fix memory alignment issue in ARM32 platforms
rsi: improve kernel thread handling to fix kernel panic
Stanislaw Gruszka (52):
mt76: unify wait_for_mac
mt76: rename mt76x2_regs.h
mt76: merge mt76x0/regs.h into mt76x02_regs.h
mt76: create new mt76x02-lib module for common mt76x{0,2} code
mt76: unify mac_get_key_info
mt76: add helpers for register access with mt76_dev struct
mt76: unify mac_shared_key_setup
mt76: unify mac_wcid_set_key
mt76: unify mac_wcid_setup
mt76: use mac_wcid_set_drop in mt76x0
mt76x0: use mt76_wcid_free in mt76x0
mt76: unify mt76x02_vif struct
mt76: unify sta structure part 1
mt76: unify sta structure part 2
mt76x0: initalize custom tx queues
mt76x0: use mt76x02_sta and mt76x02_tx_status
mt76x0: fix remove_interface
mt76: move wcid fields to common mt76_dev struct
mt76: unify sta_add / sta_remove
mt76: pratially unify add_interface
mt76: unify ampdu_action
mt76: unify set_key
mt76x0: remove empty sta_notify
mt76: unify AC to hw queue mapping
mt76: unify conf_tx
mt76x0: remove vif_mask
mt76: unify remove_interface
mt76: unify add_interface
mt76: unify sta_rate_tbl_update and related helpers
mt76: unify txwi and rxwi structures
mt76: unify load_tx_status
mt76: unify send_tx_status and related helpers
mt76: use mt76_rx_status in mt76x0
mt76: unify mac_process_rate
mt76x0: reserve enough space in mac80211
mt76: unify {insert/remove}_hdr_pad
mt76: partially unify filling txwi fields
mt76x0: trim rx skb to proper length
mt76x0: inital split between pci and usb
mt76x0: remove unused mt76x0_wcid
mt76x0: remove some usb specific code from mt76x0_register_device
mt76x0: make device allocation bus neutral
mt76: add usb implementation of {wr,rd}_rp
mt76: add rd_rp and wr_rp to bus_ops/mcu_ops
mt76x0: remove unused mt76x0_burst_read_regs
mt76x0: remove mt76x0_burst_write_regs()
mt76x0: usb: move firmware loading to usb.c
rt2800: move usb specific txdone/txstatus routines to rt2800lib
rt2800mmio: use txdone/txstatus routines from lib
rt2x00: do not check for txstatus timeout every time on tasklet
rt2x00: use different txstatus timeouts when flushing
rt2800: flush and txstatus rework for rt2800mmio
Sven Eckelmann (1):
ath10k: limit available channels via DT ieee80211-freq-limit
Takashi Iwai (1):
brcmsmac: Use kvmalloc() for ucode allocations
Tamizh chelvam (1):
ath10k: fix kernel panic by moving pci flush after napi_disable
Varsha Rao (4):
ath9k: Remove unnecessary parentheses
ath6kl: Remove unnecessary parentheses
brcmsmac: Remove extra parentheses
cw1200: Remove extra parentheses
YueHaibing (5):
wcn36xx: Use kmemdup instead of duplicating it in wcn36xx_smd_process_ptt_msg_rsp
wcn36xx: use dma_zalloc_coherent instead of allocator/memset
rsi: remove set but not used variables 'header_size' and 'tx_params'
brcmfmac: remove set but not used variables 'sfdoff' and 'pad_size'
qtnfmac: remove set but not used variable 'vif'
zhong jiang (1):
brcm80211: remove redundant condition check before debugfs_remove_recursive
drivers/net/wireless/ath/ath10k/ahb.c | 4 +-
drivers/net/wireless/ath/ath10k/ce.c | 24 +-
drivers/net/wireless/ath/ath10k/core.c | 17 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 4 +-
drivers/net/wireless/ath/ath10k/hw.h | 5 +
drivers/net/wireless/ath/ath10k/mac.c | 2 +
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 6 +
drivers/net/wireless/ath/ath5k/debug.c | 2 -
drivers/net/wireless/ath/ath6kl/main.c | 2 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 4 -
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/debug_sta.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 12 +-
drivers/net/wireless/ath/ath9k/tx99.c | 9 -
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
drivers/net/wireless/ath/carl9170/tx.c | 4 +-
drivers/net/wireless/ath/wcn36xx/dxe.c | 19 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 333 ++++-
drivers/net/wireless/ath/wil6210/debugfs.c | 47 +-
drivers/net/wireless/ath/wil6210/main.c | 13 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 1 +
drivers/net/wireless/ath/wil6210/rx_reorder.c | 12 +-
drivers/net/wireless/ath/wil6210/txrx.c | 98 +-
drivers/net/wireless/ath/wil6210/txrx_edma.c | 26 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 19 +
drivers/net/wireless/ath/wil6210/wmi.c | 350 ++++-
drivers/net/wireless/ath/wil6210/wmi.h | 2 +
drivers/net/wireless/broadcom/b43/b43.h | 2 +-
drivers/net/wireless/broadcom/b43/dma.c | 2 +-
drivers/net/wireless/broadcom/b43/main.c | 8 +-
drivers/net/wireless/broadcom/b43legacy/dma.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 8 +
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 5 +-
.../wireless/broadcom/brcm80211/brcmsmac/debug.c | 3 +-
.../broadcom/brcm80211/brcmsmac/mac80211_if.c | 6 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 +-
.../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 34 +-
.../broadcom/brcm80211/include/brcmu_wifi.h | 3 +
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/1000.c | 4 -
drivers/net/wireless/intel/iwlwifi/cfg/2000.c | 4 -
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 71 +-
drivers/net/wireless/intel/iwlwifi/cfg/5000.c | 4 -
drivers/net/wireless/intel/iwlwifi/cfg/6000.c | 4 -
drivers/net/wireless/intel/iwlwifi/cfg/7000.c | 5 -
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 5 -
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/dvm/agn.h | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/calib.c | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/calib.h | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/dev.h | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/devices.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/led.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/led.h | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 6 +-
drivers/net/wireless/intel/iwlwifi/dvm/power.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/power.h | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/rs.h | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/rx.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/rxon.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/scan.c | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/sta.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/tt.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/tt.h | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/tx.c | 5 -
drivers/net/wireless/intel/iwlwifi/dvm/ucode.c | 5 -
drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 3 -
drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 3 -
drivers/net/wireless/intel/iwlwifi/fw/api/coex.h | 3 +
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 3 +-
drivers/net/wireless/intel/iwlwifi/fw/api/d3.h | 89 +-
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 5 +
drivers/net/wireless/intel/iwlwifi/fw/api/debug.h | 32 +
.../net/wireless/intel/iwlwifi/fw/api/mac-cfg.h | 49 +
drivers/net/wireless/intel/iwlwifi/fw/api/mac.h | 14 +
drivers/net/wireless/intel/iwlwifi/fw/api/power.h | 30 +-
drivers/net/wireless/intel/iwlwifi/fw/api/rs.h | 78 +-
drivers/net/wireless/intel/iwlwifi/fw/api/rx.h | 189 ++-
drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 1 +
drivers/net/wireless/intel/iwlwifi/fw/api/sta.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 8 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 337 ++---
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 97 +-
drivers/net/wireless/intel/iwlwifi/fw/debugfs.c | 124 +-
drivers/net/wireless/intel/iwlwifi/fw/debugfs.h | 3 -
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 8 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 32 +-
drivers/net/wireless/intel/iwlwifi/fw/img.h | 5 -
drivers/net/wireless/intel/iwlwifi/fw/notif-wait.c | 5 -
drivers/net/wireless/intel/iwlwifi/fw/notif-wait.h | 5 -
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-agn-hw.h | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 18 +-
.../net/wireless/intel/iwlwifi/iwl-context-info.h | 25 +-
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 6 +-
drivers/net/wireless/intel/iwlwifi/iwl-debug.c | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-debug.h | 4 -
.../net/wireless/intel/iwlwifi/iwl-devtrace-data.h | 10 +-
.../net/wireless/intel/iwlwifi/iwl-devtrace-io.h | 4 -
.../wireless/intel/iwlwifi/iwl-devtrace-iwlwifi.h | 69 +-
.../net/wireless/intel/iwlwifi/iwl-devtrace-msg.h | 4 -
.../wireless/intel/iwlwifi/iwl-devtrace-ucode.h | 4 -
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c | 7 +-
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.h | 22 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 24 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.h | 5 -
.../net/wireless/intel/iwlwifi/iwl-eeprom-parse.c | 7 +-
.../net/wireless/intel/iwlwifi/iwl-eeprom-parse.h | 5 -
.../net/wireless/intel/iwlwifi/iwl-eeprom-read.c | 5 -
.../net/wireless/intel/iwlwifi/iwl-eeprom-read.h | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 5 +-
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 4 -
drivers/net/wireless/intel/iwlwifi/iwl-io.h | 4 -
drivers/net/wireless/intel/iwlwifi/iwl-modparams.h | 3 -
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-op-mode.h | 7 +-
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.h | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-scd.h | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 41 +-
drivers/net/wireless/intel/iwlwifi/mvm/binding.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 23 +-
drivers/net/wireless/intel/iwlwifi/mvm/constants.h | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 183 ++-
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 37 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.h | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 28 +-
drivers/net/wireless/intel/iwlwifi/mvm/led.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 70 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 91 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 36 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 5 -
.../net/wireless/intel/iwlwifi/mvm/offloading.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 69 +-
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/quota.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 35 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 25 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 721 ++++++----
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 26 +-
drivers/net/wireless/intel/iwlwifi/mvm/sf.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 30 +-
drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 3 -
drivers/net/wireless/intel/iwlwifi/mvm/testmode.h | 5 -
.../net/wireless/intel/iwlwifi/mvm/time-event.h | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/tof.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/tof.h | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 5 -
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 162 ++-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 27 +-
.../wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 4 +-
.../net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 28 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 60 +-
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 109 +-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 20 +-
.../net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 9 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 267 ++--
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 182 ++-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 93 +-
.../net/wireless/intersil/orinoco/orinoco_usb.c | 6 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 5 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 13 +
drivers/net/wireless/mediatek/mt76/Kconfig | 29 +-
drivers/net/wireless/mediatek/mt76/Makefile | 10 +-
drivers/net/wireless/mediatek/mt76/dma.c | 16 +-
drivers/net/wireless/mediatek/mt76/dma.h | 51 +-
drivers/net/wireless/mediatek/mt76/mac80211.c | 6 +-
drivers/net/wireless/mediatek/mt76/mmio.c | 12 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 94 +-
drivers/net/wireless/mediatek/mt76/mt76x0/Makefile | 13 +-
drivers/net/wireless/mediatek/mt76/mt76x0/core.c | 34 -
drivers/net/wireless/mediatek/mt76/mt76x0/dma.c | 522 -------
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 26 +-
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.h | 3 -
drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 400 ++----
drivers/net/wireless/mediatek/mt76/mt76x0/mac.c | 437 +-----
drivers/net/wireless/mediatek/mt76/mt76x0/mac.h | 136 +-
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 272 +---
drivers/net/wireless/mediatek/mt76/mt76x0/mcu.c | 656 ---------
drivers/net/wireless/mediatek/mt76/mt76x0/mcu.h | 61 +-
drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 181 +--
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 81 ++
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 37 +-
drivers/net/wireless/mediatek/mt76/mt76x0/regs.h | 651 ---------
drivers/net/wireless/mediatek/mt76/mt76x0/trace.h | 14 +-
drivers/net/wireless/mediatek/mt76/mt76x0/tx.c | 245 +---
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 382 +++--
drivers/net/wireless/mediatek/mt76/mt76x0/usb.h | 61 -
drivers/net/wireless/mediatek/mt76/mt76x0/util.c | 42 -
drivers/net/wireless/mediatek/mt76/mt76x02_dma.h | 60 +
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 504 +++++++
drivers/net/wireless/mediatek/mt76/mt76x02_mac.h | 205 +++
drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c | 213 +++
drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h | 100 ++
.../mt76/{mt76x2_regs.h => mt76x02_regs.h} | 78 +-
.../mediatek/mt76/{mt76x2_dma.h => mt76x02_usb.h} | 22 +-
.../net/wireless/mediatek/mt76/mt76x02_usb_core.c | 72 +
.../net/wireless/mediatek/mt76/mt76x02_usb_mcu.c | 359 +++++
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 456 ++++++
drivers/net/wireless/mediatek/mt76/mt76x02_util.h | 54 +
drivers/net/wireless/mediatek/mt76/mt76x2.h | 88 +-
drivers/net/wireless/mediatek/mt76/mt76x2_common.c | 318 +----
drivers/net/wireless/mediatek/mt76/mt76x2_dma.c | 55 +-
drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 27 +-
.../wireless/mediatek/mt76/mt76x2_init_common.c | 48 +-
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 19 +-
drivers/net/wireless/mediatek/mt76/mt76x2_mac.h | 131 +-
.../net/wireless/mediatek/mt76/mt76x2_mac_common.c | 488 +------
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 93 +-
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c | 261 +---
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h | 68 +-
.../net/wireless/mediatek/mt76/mt76x2_mcu_common.c | 124 ++
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 65 +-
.../net/wireless/mediatek/mt76/mt76x2_phy_common.c | 53 +-
drivers/net/wireless/mediatek/mt76/mt76x2_trace.h | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 13 +-
.../net/wireless/mediatek/mt76/mt76x2_tx_common.c | 49 +-
drivers/net/wireless/mediatek/mt76/mt76x2_usb.c | 17 +-
drivers/net/wireless/mediatek/mt76/mt76x2u.h | 17 +-
drivers/net/wireless/mediatek/mt76/mt76x2u_core.c | 69 +-
drivers/net/wireless/mediatek/mt76/mt76x2u_init.c | 23 +-
drivers/net/wireless/mediatek/mt76/mt76x2u_mac.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x2u_main.c | 47 +-
drivers/net/wireless/mediatek/mt76/mt76x2u_mcu.c | 218 +--
drivers/net/wireless/mediatek/mt76/mt76x2u_phy.c | 67 +-
drivers/net/wireless/mediatek/mt76/tx.c | 16 +
drivers/net/wireless/mediatek/mt76/usb.c | 105 +-
drivers/net/wireless/mediatek/mt76/usb_mcu.c | 204 +--
drivers/net/wireless/quantenna/qtnfmac/Makefile | 3 +-
drivers/net/wireless/quantenna/qtnfmac/bus.h | 5 +-
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 3 -
drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 391 +++++
.../wireless/quantenna/qtnfmac/pcie/pcie_priv.h | 85 ++
.../wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 1262 +++++++++++++++++
.../{pearl/pcie_ipc.h => pcie/pearl_pcie_ipc.h} | 58 -
.../pcie_regs_pearl.h => pcie/pearl_pcie_regs.h} | 0
.../net/wireless/quantenna/qtnfmac/pearl/pcie.c | 1494 --------------------
.../quantenna/qtnfmac/pearl/pcie_bus_priv.h | 91 --
.../net/wireless/quantenna/qtnfmac/qtn_hw_ids.h | 14 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 154 ++
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 3 +
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 277 ++--
drivers/net/wireless/ralink/rt2x00/rt2800mmio.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 143 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 3 +
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 18 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 4 +
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 2 +
.../net/wireless/realtek/rtl818x/rtl8187/leds.c | 2 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 4 +-
drivers/net/wireless/rsi/rsi_91x_hal.c | 4 -
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 2 +-
drivers/net/wireless/rsi/rsi_91x_usb.c | 11 +-
drivers/net/wireless/rsi/rsi_common.h | 1 -
drivers/net/wireless/st/cw1200/txrx.c | 4 +-
276 files changed, 8620 insertions(+), 9949 deletions(-)
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/core.c
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/dma.c
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/pci.c
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/regs.h
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/usb.h
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x0/util.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_mac.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h
rename drivers/net/wireless/mediatek/mt76/{mt76x2_regs.h => mt76x02_regs.h} (89%)
rename drivers/net/wireless/mediatek/mt76/{mt76x2_dma.h => mt76x02_usb.h} (58%)
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_util.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x02_util.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mcu_common.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/pcie/pcie_priv.h
create mode 100644 drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
rename drivers/net/wireless/quantenna/qtnfmac/{pearl/pcie_ipc.h => pcie/pearl_pcie_ipc.h} (68%)
rename drivers/net/wireless/quantenna/qtnfmac/{pearl/pcie_regs_pearl.h => pcie/pearl_pcie_regs.h} (100%)
delete mode 100644 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
delete mode 100644 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox