* Re: [PATCH net] sctp: add SCTP_CID_RECONF conversion in sctp_cname
From: Marcelo Ricardo Leitner @ 2017-12-18 13:08 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <ae9172b7dc432d6092ab2bc061a0cf322a3939b5.1513577597.git.lucien.xin@gmail.com>
On Mon, Dec 18, 2017 at 02:13:17PM +0800, Xin Long wrote:
> Whenever a new type of chunk is added, the corresp conversion in
> sctp_cname should be added. Otherwise, in some places, pr_debug
> will print it as "unknown chunk".
>
> Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo R. Leitner <marcelo.leitner@gmail.com>
...
> case SCTP_CID_AUTH:
> return "AUTH";
>
> + case SCTP_CID_RECONF:
> + return "RECONF";
> +
> default:
> break;
Now we also need idata and ifwdtsn in there too, btw.
Marcelo
^ permalink raw reply
* [PATCH] bpf: fix broken BPF selftest build on s390
From: Hendrik Brueckner @ 2017-12-18 13:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Arnaldo Carvalho de Melo, Hendrik Brueckner, linux-s390, netdev
With 720f228e8d31 ("bpf: fix broken BPF selftest build") the
inclusion of arch-specific header files changed. Including the
asm/bpf_perf_event.h on s390, correctly includes the s390 specific
header file. This header file tries then to include the s390
asm/ptrace.h and the build fails with:
cc -Wall -O2 -I../../../include/uapi -I../../../lib -I../../../../include/generated -I../../../include test_verifier.c
+/root/git/linux/tools/testing/selftests/bpf/libbpf.a /root/git/linux/tools/testing/selftests/bpf/cgroup_helpers.c -lcap -lelf -o
+/root/git/linux/tools/testing/selftests/bpf/test_verifier
In file included from ../../../include/uapi/asm/bpf_perf_event.h:4:0,
from ../../../include/uapi/linux/bpf_perf_event.h:11,
from test_verifier.c:29:
../../../include/uapi/../../arch/s390/include/uapi/asm/bpf_perf_event.h:7:9: error: unknown type name 'user_pt_regs'
typedef user_pt_regs bpf_user_pt_regs_t;
^~~~~~~~~~~~
make: *** [../lib.mk:109: /root/git/linux/tools/testing/selftests/bpf/test_verifier] Error 1
This is caused by a recent update to the s390 asm/ptrace.h file
that is not (yet) available in the local installation. That means,
the s390 asm/ptrace.h must be included from the tools/arch/s390
directory.
Because there is no proper framework to deal with asm specific
includes in tools/, slightly modify the s390 asm/bpf_perf_event.h
to include the local ptrace.h header file.
See also discussion on
https://marc.info/?l=linux-s390&m=151359424420691&w=2
Please note that this needs to be preserved until tools/ is able to
correctly handle asm specific headers.
References: https://marc.info/?l=linux-s390&m=151359424420691&w=2
Fixes: 720f228e8d31 ("bpf: fix broken BPF selftest build")
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
---
tools/arch/s390/include/uapi/asm/bpf_perf_event.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/arch/s390/include/uapi/asm/bpf_perf_event.h b/tools/arch/s390/include/uapi/asm/bpf_perf_event.h
index cefe7c7..0a8e37a 100644
--- a/tools/arch/s390/include/uapi/asm/bpf_perf_event.h
+++ b/tools/arch/s390/include/uapi/asm/bpf_perf_event.h
@@ -2,7 +2,7 @@
#ifndef _UAPI__ASM_BPF_PERF_EVENT_H__
#define _UAPI__ASM_BPF_PERF_EVENT_H__
-#include <asm/ptrace.h>
+#include "ptrace.h"
typedef user_pt_regs bpf_user_pt_regs_t;
--
1.8.3.1
^ permalink raw reply related
* Re: [bpf-next V1-RFC PATCH 01/14] xdp: base API for new XDP rx-queue info concept
From: David Ahern @ 2017-12-18 13:23 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, gospo, bjorn.topel,
michael.chan
In-Reply-To: <20171218115501.3f1fcf36@redhat.com>
On 12/18/17 3:55 AM, Jesper Dangaard Brouer wrote:
>
> Handling return-errors in the drivers complicated the driver code, as it
> involves unraveling and deallocating other RX-rings etc (that were
> already allocated) if the reg fails. (Also notice next patch will allow
> dev == NULL, if right ptype is set).
>
> I'm not completely rejecting you idea, as this is a good optimization
> trick, which is to move validation checks to setup-time, thus allowing
> less validation checks at runtime. I sort-of actually already did
> this, as I allow bpf to deref dev without NULL check. I would argue
> this is good enough, as we will crash in a predictable way, as above
> WARN will point to which driver violated the API.
>
> If people think it is valuable I can change this API to return an err?
Saeed's suggested API in a comment on patch 12 also removes most of the
WARN_ONs as it sets the device and index:
xdp_rxq_info_reg(netdev, rxq_index)
{
rxqueue = dev->_rx + rxq_index;
xdp_rxq = rxqueue.xdp_rxq;
xdp_rxq_info_init(xdp_rxq);
xdp_rxq.dev = netdev;
xdp_rxq.queue_index = rxq_index;
}
xdp_rxq_info_unreg(netdev, rxq_index)
{
...
}
^ permalink raw reply
* RE: [PATCH] qed: Remove unused QED_RDMA_DEV_CAP_* symbols and dev->dev_caps
From: Amrani, Ram @ 2017-12-18 13:30 UTC (permalink / raw)
To: Bjorn Helgaas, netdev@vger.kernel.org
Cc: linux-pci@vger.kernel.org, Elior, Ariel,
Dept-Eng Everest Linux L2
In-Reply-To: <20171215230301.177993.80284.stgit@bhelgaas-glaptop.roam.corp.google.com>
> From: Bjorn Helgaas <bhelgaas@google.com>
>
> The QED_RDMA_DEV_CAP_* symbols are only used to set bits in dev->dev_caps.
> Nobody ever looks at those bits. Remove the symbols and dev_caps itself.
>
> Note that if these are ever used and added back, it looks incorrect to set
> QED_RDMA_DEV_CAP_ATOMIC_OP based on PCI_EXP_DEVCTL2_LTR_EN. LTR is the
> Latency Tolerance Reporting mechanism, which has nothing to do with Atomic
> Ops.
>
> No functional change intended.
>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/net/ethernet/qlogic/qed/qed_rdma.c | 20 ----------
> include/linux/qed/qed_rdma_if.h | 55 +---------------------------
> 2 files changed, 1 insertion(+), 74 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
> index c8c4b3940564..1091b6aae0c6 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
> @@ -394,7 +394,6 @@ static void qed_rdma_init_devinfo(struct qed_hwfn *p_hwfn,
> {
> struct qed_rdma_device *dev = p_hwfn->p_rdma_info->dev;
> struct qed_dev *cdev = p_hwfn->cdev;
> - u32 pci_status_control;
> u32 num_qps;
>
> /* Vendor specific information */
> @@ -468,25 +467,6 @@ static void qed_rdma_init_devinfo(struct qed_hwfn *p_hwfn,
> dev->max_ah = p_hwfn->p_rdma_info->num_qps;
> dev->max_stats_queues = (u8)RESC_NUM(p_hwfn, QED_RDMA_STATS_QUEUE);
>
> - /* Set capablities */
> - dev->dev_caps = 0;
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_RNR_NAK, 1);
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_PORT_ACTIVE_EVENT, 1);
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_PORT_CHANGE_EVENT, 1);
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_RESIZE_CQ, 1);
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_BASE_MEMORY_EXT, 1);
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_BASE_QUEUE_EXT, 1);
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_ZBVA, 1);
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_LOCAL_INV_FENCE, 1);
> -
> - /* Check atomic operations support in PCI configuration space. */
> - pci_read_config_dword(cdev->pdev,
> - cdev->pdev->pcie_cap + PCI_EXP_DEVCTL2,
> - &pci_status_control);
> -
> - if (pci_status_control & PCI_EXP_DEVCTL2_LTR_EN)
> - SET_FIELD(dev->dev_caps, QED_RDMA_DEV_CAP_ATOMIC_OP, 1);
> -
> if (QED_IS_IWARP_PERSONALITY(p_hwfn))
> qed_iwarp_init_devinfo(p_hwfn);
> }
> diff --git a/include/linux/qed/qed_rdma_if.h b/include/linux/qed/qed_rdma_if.h
> index 4dd72ba210f5..a8db5572d3c2 100644
> --- a/include/linux/qed/qed_rdma_if.h
> +++ b/include/linux/qed/qed_rdma_if.h
> @@ -109,60 +109,7 @@ struct qed_rdma_device {
> u8 max_pkey;
> u16 max_srq_wr;
> u8 max_stats_queues;
> - u32 dev_caps;
> -
> - /* Abilty to support RNR-NAK generation */
> -
> -#define QED_RDMA_DEV_CAP_RNR_NAK_MASK 0x1
> -#define QED_RDMA_DEV_CAP_RNR_NAK_SHIFT 0
> - /* Abilty to support shutdown port */
> -#define QED_RDMA_DEV_CAP_SHUTDOWN_PORT_MASK 0x1
> -#define QED_RDMA_DEV_CAP_SHUTDOWN_PORT_SHIFT 1
> - /* Abilty to support port active event */
> -#define QED_RDMA_DEV_CAP_PORT_ACTIVE_EVENT_MASK 0x1
> -#define QED_RDMA_DEV_CAP_PORT_ACTIVE_EVENT_SHIFT 2
> - /* Abilty to support port change event */
> -#define QED_RDMA_DEV_CAP_PORT_CHANGE_EVENT_MASK 0x1
> -#define QED_RDMA_DEV_CAP_PORT_CHANGE_EVENT_SHIFT 3
> - /* Abilty to support system image GUID */
> -#define QED_RDMA_DEV_CAP_SYS_IMAGE_MASK 0x1
> -#define QED_RDMA_DEV_CAP_SYS_IMAGE_SHIFT 4
> - /* Abilty to support bad P_Key counter support */
> -#define QED_RDMA_DEV_CAP_BAD_PKEY_CNT_MASK 0x1
> -#define QED_RDMA_DEV_CAP_BAD_PKEY_CNT_SHIFT 5
> - /* Abilty to support atomic operations */
> -#define QED_RDMA_DEV_CAP_ATOMIC_OP_MASK 0x1
> -#define QED_RDMA_DEV_CAP_ATOMIC_OP_SHIFT 6
> -#define QED_RDMA_DEV_CAP_RESIZE_CQ_MASK 0x1
> -#define QED_RDMA_DEV_CAP_RESIZE_CQ_SHIFT 7
> - /* Abilty to support modifying the maximum number of
> - * outstanding work requests per QP
> - */
> -#define QED_RDMA_DEV_CAP_RESIZE_MAX_WR_MASK 0x1
> -#define QED_RDMA_DEV_CAP_RESIZE_MAX_WR_SHIFT 8
> - /* Abilty to support automatic path migration */
> -#define QED_RDMA_DEV_CAP_AUTO_PATH_MIG_MASK 0x1
> -#define QED_RDMA_DEV_CAP_AUTO_PATH_MIG_SHIFT 9
> - /* Abilty to support the base memory management extensions */
> -#define QED_RDMA_DEV_CAP_BASE_MEMORY_EXT_MASK 0x1
> -#define QED_RDMA_DEV_CAP_BASE_MEMORY_EXT_SHIFT 10
> -#define QED_RDMA_DEV_CAP_BASE_QUEUE_EXT_MASK 0x1
> -#define QED_RDMA_DEV_CAP_BASE_QUEUE_EXT_SHIFT 11
> - /* Abilty to support multipile page sizes per memory region */
> -#define QED_RDMA_DEV_CAP_MULTI_PAGE_PER_MR_EXT_MASK 0x1
> -#define QED_RDMA_DEV_CAP_MULTI_PAGE_PER_MR_EXT_SHIFT 12
> - /* Abilty to support block list physical buffer list */
> -#define QED_RDMA_DEV_CAP_BLOCK_MODE_MASK 0x1
> -#define QED_RDMA_DEV_CAP_BLOCK_MODE_SHIFT 13
> - /* Abilty to support zero based virtual addresses */
> -#define QED_RDMA_DEV_CAP_ZBVA_MASK 0x1
> -#define QED_RDMA_DEV_CAP_ZBVA_SHIFT 14
> - /* Abilty to support local invalidate fencing */
> -#define QED_RDMA_DEV_CAP_LOCAL_INV_FENCE_MASK 0x1
> -#define QED_RDMA_DEV_CAP_LOCAL_INV_FENCE_SHIFT 15
> - /* Abilty to support Loopback on QP */
> -#define QED_RDMA_DEV_CAP_LB_INDICATOR_MASK 0x1
> -#define QED_RDMA_DEV_CAP_LB_INDICATOR_SHIFT 16
> +
> u64 page_size_caps;
> u8 dev_ack_delay;
> u32 reserved_lkey;
Acked-by: Ram Amrani <Ram.Amrani@cavium.com>
Thanks,
Ram
^ permalink raw reply
* [PATCH 2/3] rhashtable: Add rhashtable_walk_curr
From: Andreas Gruenbacher @ 2017-12-18 13:31 UTC (permalink / raw)
To: cluster-devel, Thomas Graf, Herbert Xu, netdev; +Cc: Andreas Gruenbacher
In-Reply-To: <20171218133122.29179-1-agruenba@redhat.com>
When iterating through an rhashtable is stopped with
rhashtable_walk_stop and then resumed with rhashtable_walk_start, there
currently is no way to get back to the current object and thus revisit
the object rhashtable_walk_next has previously returned.
This functionality is useful when dumping an rhashtable via the seq file
interface: seq_read will convert one object after the other. When an
object doesn't fit in the remaining buffer space anymore, user-space
will be returned all objects that have been fully converted so far.
Upon the next read from user-space, the object that didn't fit
previously will be revisited.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
---
include/linux/rhashtable.h | 1 +
lib/rhashtable.c | 17 +++++++++++++++++
2 files changed, 18 insertions(+)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index 361c08e35dbc..1a1608bc5405 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -380,6 +380,7 @@ void rhashtable_walk_enter(struct rhashtable *ht,
void rhashtable_walk_exit(struct rhashtable_iter *iter);
int rhashtable_walk_start(struct rhashtable_iter *iter) __acquires(RCU);
void *rhashtable_walk_next(struct rhashtable_iter *iter);
+void *rhashtable_walk_curr(struct rhashtable_iter *iter);
void rhashtable_walk_stop(struct rhashtable_iter *iter) __releases(RCU);
void rhashtable_free_and_destroy(struct rhashtable *ht,
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index ddd7dde87c3c..1d45a4274b7a 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -842,6 +842,23 @@ void *rhashtable_walk_next(struct rhashtable_iter *iter)
}
EXPORT_SYMBOL_GPL(rhashtable_walk_next);
+/**
+ * rhashtable_walk_next - Return the current object
+ * @iter: Hash table iterator
+ *
+ * Returns the object previously returned by rhashtable_walk_next.
+ *
+ * Returns -ENOENT if rhashtable_walk_next hasn't been called previously.
+ */
+void *rhashtable_walk_curr(struct rhashtable_iter *iter)
+{
+ if (!iter->skip)
+ return ERR_PTR(-ENOENT);
+ iter->skip--;
+ return rhashtable_walk_next(iter);
+}
+EXPORT_SYMBOL_GPL(rhashtable_walk_curr);
+
/**
* rhashtable_walk_stop - Finish a hash table walk
* @iter: Hash table iterator
--
2.14.3
^ permalink raw reply related
* Re: r8169 regression: UDP packets dropped intermittantly
From: Holger Hoffstätte @ 2017-12-18 13:38 UTC (permalink / raw)
To: Jonathan Woithe, netdev; +Cc: linux-kernel
In-Reply-To: <20171218054951.GJ17747@marvin.atrad.com.au>
On 12/18/17 06:49, Jonathan Woithe wrote:
> Resend to netdev. LKML CCed in case anyone in the wider kernel community
> can suggest a way forward. Please CC responses if replying only to LKML.
>
> It seems that this 4+ year old regression in the r8169 driver (documented in
> this thread on netdev beginning on 9 March 2013) will never be fixed,
> despite the identification of the commit which broke it. Cards using this
> driver will therefore remain unusable for certain workloads utilising UDP.
(snip)
Hi,
Since I've seen your postings several times now with no comment or resolution
I've decided to try your reproducer on my own systems. In short, I cannot
reproduce any packet loss, despite having 2 (cheap) 1Gb switches between the
two machines. Both are running 4.14.7.
Both NICs are onboard PCIe and identify as:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
$ethtool -i eth0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168e-3_0.0.4 03/27/12
..
Both machines are from 2012, so quite dated already. Nevertheless your
reproducer runs forever and all I see is 6 bytes request, 14 bytes response,
with no drops. Not one. I tried in both directions - no difference.
I realize this doesn't actually solve your immediate problem, but it is
nevertheless an indicator that whatever you have been observing is caused
by something else.
regards,
Holger
^ permalink raw reply
* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Knut Omang @ 2017-12-18 13:41 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Stephen Hemminger, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mauro Carvalho Chehab, Nicolas Palix, Jonathan Corbet,
Santosh Shilimkar, Matthew Wilcox, cocci-/FJkirnvOdkvYVN+rsErww,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Doug Ledford,
Mickaël Salaün, Shuah Khan,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA, Michal Marek, Julia Lawall,
John Haxby, Åsmund Østvold, Masahiro Yamada
In-Reply-To: <20171218050043.GA1307-uk2M96/98Pc@public.gmane.org>
On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
>
> > > I like the ability to add more checkers and keep then in the main
> > > upstream tree. But adding overrides for specific subsystems goes against
> > > the policy that all subsystems should be treated equally.
> >
> > This is a tool to enable automated testing for as many checks as
> > possible, as soon as possible. Like any tool, it can be misused, but
> > that's IMHO an orthogonal problem that I think the maintainers will
> > be more than capable of preventing.
> >
> > Think of this as a tightening screw: We eliminate errors class by
> > class or file by file, and in the same commit narrows in the list of
> > exceptions. That way we can fix issues piece by piece while avoiding
> > a lot of regressions in already clean parts.
>
> Since you used drivers/infiniband as an example for this script..
>
> I will say I agree with this idea.
> It is not that we *want* infiniband to be different from the rest of
> the kernel, it is that we have this historical situation where we
> don't have a code base that already passes the various static checker
> things.
I poked around trying make M= in different parts of the kernel to get some
"mileage" and to get as much examples as possible, and it appears most of
the kernel has issues of sorts. Also Joe and others keep adding more checks
as well, and we'd want that process to coexist with the need for automatic
regression testing in this area.
> I would like it very much if I could run 'make static checker' and see
> no warnings.
which is just what is the result with 'make C=2 M=drivers/infiniband/core'
and the patches #1 and #5 in this set in case not everyone got the point,
> This helps me know that I when I accept patches I am not
> introducing new problems to code that has already been cleaned up.
>
> Today when we run checkers we get so many warnings it is too hard to
> make any sense of it.
>
> Being able to say File X is now clean for check XYZ seems very useful
> and may motivate people to clean up the files they actualy care
> about...
>
> > > There was discussion at Kernel Summit about how the different
> > > subsystems already have different rules. This appears to be a way
> > > to make that worse.
> >
> > IMHO this is a tool that should help maintainers implement the
> > policies they desire. But the tool itself does not dictate any
> > such.
>
> Yes, again, in infiniband we like to see checkpatch be good for new
> submission, even if that clashes with surrounding code. For instance
> we have a mixture of sizeof foo and sizeof(foo) styles in the same
> file/function now.
That's one of the fixes that the excellent --fix-inplace handles so
one of my patches here
https://github.com/torvalds/linux/compare/master...knuto:runchecks
fixes those in drivers/infiniband/core.
> I certainly don't want to tell people they need to follow some
> different style from 10 years ago when they send patches.
>
Thanks,
Knut
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] wil6210: fix build warnings without CONFIG_PM
From: Arnd Bergmann @ 2017-12-18 13:45 UTC (permalink / raw)
To: Maya Erez, Kalle Valo
Cc: Arnd Bergmann, Lazar Alexei, Dedy Lansky, Hamad Kadmany,
Lior David, Gidon Studinski, linux-wireless, wil6210, netdev,
linux-kernel
The #ifdef checks are hard to get right, in this case some functions
should have been left inside a CONFIG_PM_SLEEP check as seen by this
message:
drivers/net/wireless/ath/wil6210/pcie_bus.c:489:12: error: 'wil6210_pm_resume' defined but not used [-Werror=unused-function]
drivers/net/wireless/ath/wil6210/pcie_bus.c:484:12: error: 'wil6210_pm_suspend' defined but not used [-Werror=unused-function]
Using an __maybe_unused is easier here, so I'm replacing all the
other #ifdef in this file as well for consistency.
Fixes: 94162666cd51 ("wil6210: run-time PM when interface down")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 25 ++++++++-----------------
drivers/net/wireless/ath/wil6210/wil6210.h | 2 --
2 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 42a5480c764d..9e622ddcc0bb 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -31,10 +31,8 @@ static bool ftm_mode;
module_param(ftm_mode, bool, 0444);
MODULE_PARM_DESC(ftm_mode, " Set factory test mode, default - false");
-#ifdef CONFIG_PM
static int wil6210_pm_notify(struct notifier_block *notify_block,
unsigned long mode, void *unused);
-#endif /* CONFIG_PM */
static
void wil_set_capabilities(struct wil6210_priv *wil)
@@ -307,15 +305,15 @@ static int wil_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto bus_disable;
}
-#ifdef CONFIG_PM
- wil->pm_notify.notifier_call = wil6210_pm_notify;
+ if (IS_ENABLED(CONFIG_PM))
+ wil->pm_notify.notifier_call = wil6210_pm_notify;
+
rc = register_pm_notifier(&wil->pm_notify);
if (rc)
/* Do not fail the driver initialization, as suspend can
* be prevented in a later phase if needed
*/
wil_err(wil, "register_pm_notifier failed: %d\n", rc);
-#endif /* CONFIG_PM */
wil6210_debugfs_init(wil);
@@ -346,9 +344,7 @@ static void wil_pcie_remove(struct pci_dev *pdev)
wil_dbg_misc(wil, "pcie_remove\n");
-#ifdef CONFIG_PM
unregister_pm_notifier(&wil->pm_notify);
-#endif /* CONFIG_PM */
wil_pm_runtime_forbid(wil);
@@ -372,8 +368,6 @@ static const struct pci_device_id wil6210_pcie_ids[] = {
};
MODULE_DEVICE_TABLE(pci, wil6210_pcie_ids);
-#ifdef CONFIG_PM
-
static int wil6210_suspend(struct device *dev, bool is_runtime)
{
int rc = 0;
@@ -481,17 +475,17 @@ static int wil6210_pm_notify(struct notifier_block *notify_block,
return rc;
}
-static int wil6210_pm_suspend(struct device *dev)
+static int __maybe_unused wil6210_pm_suspend(struct device *dev)
{
return wil6210_suspend(dev, false);
}
-static int wil6210_pm_resume(struct device *dev)
+static int __maybe_unused wil6210_pm_resume(struct device *dev)
{
return wil6210_resume(dev, false);
}
-static int wil6210_pm_runtime_idle(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_idle(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct wil6210_priv *wil = pci_get_drvdata(pdev);
@@ -501,12 +495,12 @@ static int wil6210_pm_runtime_idle(struct device *dev)
return wil_can_suspend(wil, true);
}
-static int wil6210_pm_runtime_resume(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_resume(struct device *dev)
{
return wil6210_resume(dev, true);
}
-static int wil6210_pm_runtime_suspend(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct wil6210_priv *wil = pci_get_drvdata(pdev);
@@ -518,15 +512,12 @@ static int wil6210_pm_runtime_suspend(struct device *dev)
return wil6210_suspend(dev, true);
}
-#endif /* CONFIG_PM */
static const struct dev_pm_ops wil6210_pm_ops = {
-#ifdef CONFIG_PM
SET_SYSTEM_SLEEP_PM_OPS(wil6210_pm_suspend, wil6210_pm_resume)
SET_RUNTIME_PM_OPS(wil6210_pm_runtime_suspend,
wil6210_pm_runtime_resume,
wil6210_pm_runtime_idle)
-#endif /* CONFIG_PM */
};
static struct pci_driver wil6210_driver = {
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index cf27d9711dde..366a6ef222dc 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -742,9 +742,7 @@ struct wil6210_priv {
int fw_calib_result;
-#ifdef CONFIG_PM
struct notifier_block pm_notify;
-#endif /* CONFIG_PM */
bool suspend_resp_rcvd;
bool suspend_resp_comp;
--
2.9.0
^ permalink raw reply related
* Re: Wifi RTL8723bu driver test: failed to scan
From: Mylene JOSSERAND @ 2017-12-18 13:47 UTC (permalink / raw)
To: Jes Sorensen
Cc: kvalo, linux-wireless, netdev, Thomas Petazzoni, Maxime Ripard
In-Reply-To: <75669dd0-1f25-fc7e-4a4d-a5549aeeb2cf@gmail.com>
Hello Jes,
Le Tue, 28 Nov 2017 11:14:10 -0500,
Jes Sorensen <jes.sorensen@gmail.com> a écrit :
> On 11/22/2017 04:51 AM, Mylene JOSSERAND wrote:
> > Hello Jes Sorensen,
> >
> > I am currently testing a LM811 Wifi/BT USB dongle [1] on a Sinlinx
> > SinA33 Allwinner SoC board [2]. I saw that I should use the realtek
> > driver RTL8723BU for this USB dongle.
> >
> > Currently, I am only testing the Wifi and the mainline driver (kernel
> > 4.14-rc7) does not seem to work. At least, the scanning does not output
> > anything.
> >
> > I tested the driver recommended by LM Technologies [3] and it works
> > fine (scan, connect and ping are ok). Before investigating on the
> > differences between these two drivers, do you have any idea about this
> > issue?
> >
> > Here are the commands and output I got with mainline's driver:
>
> I have not looked at the driver these LM Technologies people are
> referring to, but I am guessing it's the vendor code.
>
> 8723bu is a little dicey because it has BT in the chip and if you enable
> that the two drivers need to interact, which rtl8xxxu currently doesn't
> know about. Check your dmesg output to make sure you don't have some BT
> thing loaded hijacking the chip.
I finally tested it again without any BT stuff enabled and I am still
not having any output on scanning.
I added DEBUG support to have all dev_dbg outputs for rtl8xxxu (core
and 8723b). Here is the log of boot and different iw commands:
http://code.bulix.org/56345t-242970?raw
Do you have any idea/hint to give me?
I checked the firmware: I am using the last one from linux-firmware's
repository. Have you already tried this chip? With which firmware?
Thank you very much for any help.
Best regards,
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in rds_send_xmit
From: Sowmini Varadhan @ 2017-12-18 13:55 UTC (permalink / raw)
To: syzbot; +Cc: netdev, rds-devel, syzkaller-bugs
In-Reply-To: <001a1145ac5480242305609956b3@google.com>
On (12/18/17 00:43), syzbot wrote:
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
> program syz-executor6 is using a deprecated SCSI ioctl, please convert it to
> SG_IO
> IP: rds_send_xmit+0x80/0x930 net/rds/send.c:186
conn->c_trans is at offset 0x28.
Both this and https://marc.info/?l=linux-netdev&m=151360062922798&w=2
are manifestations of the same bug: somehow the cp_send_w is still
getting queued incorrectly after the conn destroy is initiated (commit
681648e67d fixes one such window, maybe there are others).
Let me look at how this slipped through the cracks.
--Sowmini
^ permalink raw reply
* Re: [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Linus Walleij @ 2017-12-18 13:57 UTC (permalink / raw)
To: netdev, David S . Miller, Michał Mirosław
Cc: Janos Laube, Paulius Zaleckas, Linux ARM, Hans Ulli Kroll,
Florian Fainelli, Linus Walleij, Tobias Waldvogel
In-Reply-To: <20171216193911.6938-2-linus.walleij@linaro.org>
On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The Gemini ethernet has been around for years as an out-of-tree
> patch used with the NAS boxen and routers built on StorLink
> SL3512 and SL3516, later Storm Semiconductor, later Cortina
> Systems. These ASICs are still being deployed and brand new
> off-the-shelf systems using it can easily be acquired.
>
> The full name of the IP block is "Net Engine and Gigabit
> Ethernet MAC" commonly just called "GMAC".
>
> The hardware block contains a common TCP Offload Enginer (TOE)
> that can be used by both MACs. The current driver does not use
> it.
>
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Changes from v8:
> - Remove dependency guards in Kconfig to get a wider compile
> coverage for the driver to detect broken APIs etc.
I guess we need to hold this off for a while, the code does
some weird stuff using the ARM-internal page DMA mapping
API.
I *think* what happens is that the driver allocates a global queue
used for RX and TX on both interfaces, then initializes that with
page pointers and gives that to the hardware to play with.
When an RX packet comes in, the RX routine needs to figure
out from the DMA (physical) address which remapped
page/address this random physical address pointer
corresponds to.
The Linux DMA API assumption is that the driver keeps track
of this mapping, not the hardware. So we need to figure out
a way to reverse-map this. Preferably quickly, and without
using any ARM-internal mapping APIs.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH][next] bpf: fix spelling mistake: "funcation"-> "function"
From: Colin King @ 2017-12-18 14:03 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in error message text.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 6d8e432453b8..2f6f09cd1925 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -772,7 +772,7 @@ static int check_subprogs(struct bpf_verifier_env *env)
return -EPERM;
}
if (bpf_prog_is_dev_bound(env->prog->aux)) {
- verbose(env, "funcation calls in offloaded programs are not supported yet\n");
+ verbose(env, "function calls in offloaded programs are not supported yet\n");
return -EINVAL;
}
ret = add_subprog(env, i + insn[i].imm + 1);
--
2.14.1
^ permalink raw reply related
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Rafael J. Wysocki @ 2017-12-18 14:09 UTC (permalink / raw)
To: Marcin Wojtas, linux-kernel, linux-arm-kernel, netdev
Cc: davem, linux, andrew, f.fainelli, antoine.tenart,
thomas.petazzoni, gregory.clement, ezequiel.garcia, nadavh, neta,
ard.biesheuvel, jaz, tn
In-Reply-To: <1513588684-15647-1-git-send-email-mw@semihalf.com>
On 12/18/2017 10:17 AM, Marcin Wojtas wrote:
> Hi,
>
> This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> First three patches introduce fwnode helpers for obtaining PHY
> information from nodes and also MDIO fwnode API for registering
> the bus with its PHY/devices.
>
> Following patches update code of the mvmdio and mvpp2 drivers
> to support ACPI tables handling. The latter is done in 4 steps,
> as can be seen in the commits. For the details, please
> refer to the commit messages.
>
> Drivers operation was tested on top of the net-next branch
> with both DT and ACPI. Although for compatibility reasons
> with older platforms, the mvmdio driver keeps using
> of_ MDIO registering, new fwnode_ one proved to fully work
> with DT as well (tested on MacchiatoBin board).
>
> mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> on a public branch:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> It was compiled together with the most recent Tianocore EDK2 revision.
> Please refer to the firmware build instruction on MacchiatoBin board:
> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>
> Above support configures 1G to use its PHY normally. 10G can work now
> only with the link interrupt mode. Somehow reading of the
> string property in fwnode_mdiobus_child_is_phy works only with
> DT and cannot cope with 10G PHY nodes as in:
> https://pastebin.com/3JnYpU0A
>
> Above root cause will be further checked. In the meantime I will
> appreciate any comments or remarks for the kernel patches.
>
> Best regards,
> Marcin
>
> Marcin Wojtas (8):
> device property: Introduce fwnode_get_mac_address()
> device property: Introduce fwnode_get_phy_mode()
> mdio_bus: Introduce fwnode MDIO helpers
> net: mvmdio: add ACPI support
> net: mvpp2: simplify maintaining enabled ports' list
> net: mvpp2: use device_*/fwnode_* APIs instead of of_*
> net: mvpp2: handle PHY with its fwnode
> net: mvpp2: enable ACPI support in the driver
>
> drivers/base/property.c | 52 +++--
> drivers/net/ethernet/marvell/mvmdio.c | 42 +++-
> drivers/net/ethernet/marvell/mvpp2.c | 246 ++++++++++++--------
> drivers/net/phy/mdio_bus.c | 218 +++++++++++++++++
> include/linux/mdio.h | 3 +
> include/linux/property.h | 3 +
> 6 files changed, 454 insertions(+), 110 deletions(-)
>
Please CC linux-acpi on all submissions of patches touching ACPI,
property.c or property.h.
Thanks!
^ permalink raw reply
* RE: [PATCH 25/27] qede: Use timecounter_reset interface
From: Kalluru, Sudarsana @ 2017-12-18 14:13 UTC (permalink / raw)
To: Sagar Arun Kamble, linux-kernel@vger.kernel.org
Cc: Richard Cochran, Elior, Ariel, Dept-Eng Everest Linux L2,
netdev@vger.kernel.org
In-Reply-To: <1513323522-15021-26-git-send-email-sagar.a.kamble@intel.com>
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
-----Original Message-----
From: Sagar Arun Kamble [mailto:sagar.a.kamble@intel.com]
Sent: 15 December 2017 13:09
To: linux-kernel@vger.kernel.org
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>; Richard Cochran <richardcochran@gmail.com>; Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>; netdev@vger.kernel.org
Subject: [PATCH 25/27] qede: Use timecounter_reset interface
With new interface timecounter_reset we can update the start time for timecounter. Update qede_ptp_settime with this new function.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ariel Elior <Ariel.Elior@cavium.com>
Cc: everest-linux-l2@cavium.com
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/qlogic/qede/qede_ptp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ptp.c b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
index 0d054dc..c2de311 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ptp.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
@@ -129,9 +129,9 @@ static int qede_ptp_settime(struct ptp_clock_info *info,
DP_VERBOSE(edev, QED_MSG_DEBUG, "PTP settime called, ns = %llu\n", ns);
- /* Re-init the timecounter */
+ /* Reset the timecounter */
spin_lock_bh(&ptp->lock);
- timecounter_init(&ptp->tc, ns);
+ timecounter_reset(&ptp->tc, ns);
spin_unlock_bh(&ptp->lock);
return 0;
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 18/27] bnx2x: Use timecounter_reset interface
From: Kalluru, Sudarsana @ 2017-12-18 14:13 UTC (permalink / raw)
To: Sagar Arun Kamble, linux-kernel@vger.kernel.org
Cc: Richard Cochran, Elior, Ariel, Dept-Eng Everest Linux L2,
netdev@vger.kernel.org
In-Reply-To: <1513323522-15021-19-git-send-email-sagar.a.kamble@intel.com>
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
-----Original Message-----
From: Sagar Arun Kamble [mailto:sagar.a.kamble@intel.com]
Sent: 15 December 2017 13:09
To: linux-kernel@vger.kernel.org
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>; Richard Cochran <richardcochran@gmail.com>; Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>; netdev@vger.kernel.org
Subject: [PATCH 18/27] bnx2x: Use timecounter_reset interface
With new interface timecounter_reset we can update the start time for timecounter. Update bnx2x_ptp_settime with this new function.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ariel Elior <ariel.elior@cavium.com>
Cc: everest-linux-l2@cavium.com
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 1e10a81..e30e736 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13849,8 +13849,8 @@ static int bnx2x_ptp_settime(struct ptp_clock_info *ptp,
DP(BNX2X_MSG_PTP, "PTP settime called, ns = %llu\n", ns);
- /* Re-init the timecounter */
- timecounter_init(&bp->timecounter, ns);
+ /* Reset the timecounter */
+ timecounter_reset(&bp->timecounter, ns);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] cxgb4: Report tid start range correctly for T6
From: Ganesh Goudar @ 2017-12-18 14:15 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Ganesh Goudar, Arjun Vynipadath
For T6, tid start range should be read from
LE_DB_ACTIVE_TABLE_START_INDEX_A register.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 4956e42..d8efcd9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -2668,10 +2668,14 @@ static const struct file_operations mem_debugfs_fops = {
static int tid_info_show(struct seq_file *seq, void *v)
{
+ unsigned int tid_start = 0;
struct adapter *adap = seq->private;
const struct tid_info *t = &adap->tids;
enum chip_type chip = CHELSIO_CHIP_VERSION(adap->params.chip);
+ if (chip > CHELSIO_T5)
+ tid_start = t4_read_reg(adap, LE_DB_ACTIVE_TABLE_START_INDEX_A);
+
if (t4_read_reg(adap, LE_DB_CONFIG_A) & HASHEN_F) {
unsigned int sb;
seq_printf(seq, "Connections in use: %u\n",
@@ -2683,8 +2687,8 @@ static int tid_info_show(struct seq_file *seq, void *v)
sb = t4_read_reg(adap, LE_DB_SRVR_START_INDEX_A);
if (sb) {
- seq_printf(seq, "TID range: 0..%u/%u..%u", sb - 1,
- adap->tids.hash_base,
+ seq_printf(seq, "TID range: %u..%u/%u..%u", tid_start,
+ sb - 1, adap->tids.hash_base,
t->ntids - 1);
seq_printf(seq, ", in use: %u/%u\n",
atomic_read(&t->tids_in_use),
@@ -2709,7 +2713,8 @@ static int tid_info_show(struct seq_file *seq, void *v)
seq_printf(seq, "Connections in use: %u\n",
atomic_read(&t->conns_in_use));
- seq_printf(seq, "TID range: 0..%u", t->ntids - 1);
+ seq_printf(seq, "TID range: %u..%u", tid_start,
+ tid_start + t->ntids - 1);
seq_printf(seq, ", in use: %u\n",
atomic_read(&t->tids_in_use));
}
--
2.1.0
^ permalink raw reply related
* pull-request: wireless-drivers-next 2017-12-18
From: Kalle Valo @ 2017-12-18 14:17 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
luciano.coelho-ral2JQCrhuEAvxtiuMwx3w
Hi Dave,
a pull request for 4.16 to net-next tree. This is a big one, but on the
other hand most of the stuff here has been some time on linux-next so
hopefully there are no nasty surprises. Even though Arnd just send a
patch[1] five minutes ago about fixing a wcn36xx build warning, but I
don't think that's critical enough to hold up this, so I'll send it to
you in the next pull request.
But this time we actually have a merge conflict due to a000 hardware
rename in iwlwifi:
CONFLICT (content): Merge conflict in drivers/net/wireless/intel/iwlwifi/pcie/drv.c
The fix is quite straightforward, take the 22000 versions and manually
add an entry for 0xA0F0 device:
{IWL_PCI_DEVICE(0xA0F0, 0x0000, iwl22000_2ax_cfg_hr)},
I put the 'git diff' output of my test resolution below, hopefully it
helps. I'll also Cc Luca so he can correct any mistakes I did :)
Please let me know if you have any problems.
[1] https://patchwork.kernel.org/patch/10119565/
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@@ -652,20 -651,19 +652,20 @@@ static const struct pci_device_id iwl_h
{IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)},
- /* a000 Series */
- {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x34F0, 0x0310, iwla000_2ac_cfg_jf)},
- {IWL_PCI_DEVICE(0x2720, 0x0000, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x0030, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0090, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x0310, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x40C0, 0x0000, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0xA0F0, 0x0000, iwla000_2ax_cfg_hr)},
+ /* 22000 Series */
+ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x34F0, 0x0310, iwl22000_2ac_cfg_jf)},
+ {IWL_PCI_DEVICE(0x2720, 0x0000, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x34F0, 0x0070, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0078, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0070, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x0030, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x1080, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0090, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x0310, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x40C0, 0x0000, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwl22000_2ax_cfg_hr)},
++ {IWL_PCI_DEVICE(0xA0F0, 0x0000, iwl22000_2ax_cfg_hr)},
#endif /* CONFIG_IWLMVM */
The following changes since commit 0fc66ddfaf8bb8f73c965f24928f8815b470304e:
Documentation: net: dsa: Cut set_addr() documentation (2017-11-30 10:10:16 -0500)
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-2017-12-18
for you to fetch changes up to 1dde35d0b8e3a9fbf24e13d16dc583f1cc5d027b:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-12-14 18:38:48 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.16
A bigger pull request this time, the most visible change being the new
driver mt76. But there's also Kconfig refactoring in ath9k and ath10k,
work beginning in iwlwifi to have rate scaling in firmware/hardware,
wcn3990 support getting closer in ath10k and lots of smaller changes.
mt76
* a new driver for MT76x2e, a 2x2 PCIe 802.11ac chipset by MediaTek
ath10k
* enable multiqueue support for all hw using mac80211 wake_tx_queue op
* new Kconfig option ATH10K_SPECTRAL to save RAM
* show tx stats on QCA9880
* new qcom,ath10k-calibration-variant DT entry
* WMI layer support for wcn3990
ath9k
* new Kconfig option ATH9K_COMMON_SPECTRAL to save RAM
wcn36xx
* hardware scan offload support
wil6210
* run-time PM support when interface is down
iwlwifi
* initial work for rate-scaling offload
* Support for new FW API version 36
* Rename the temporary hw name A000 to 22000
ssb
* make SSB a menuconfig to ease disabling it all
mwl8k
* enable non-DFS 5G channels 149-165
----------------------------------------------------------------
Anilkumar Kolli (3):
ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statistics
ath10k: move pktlog_filter out of ath10k_debug
ath10k: add per peer tx stats support for 10.2.4
Arnd Bergmann (3):
wlcore: use boottime for fw time sync
ath10k: use 64-bit crash dump timestamps
wlcore: fix unused function warning
Ashish Kalra (1):
bcma: Adjust block comment
Avraham Stern (1):
iwlwifi: mvm: add WFA vendor specific TPC report IE to probe request
Balaji Pothunoori (1):
ath10k: handling qos at STA side based on AP WMM enable/disable
Ben Greear (1):
ath10k: fix invalid STS_CAP_OFFSET_MASK
Bjorn Andersson (1):
wcn36xx: Reduce spinlock in indication handler
Colin Ian King (3):
rtlwifi: rtl818x: remove redundant check for cck_power > 15
wlcore, wl1251: fix spelling: "Couldnt" -> "Couldn't" and remove error on -ENOMEM
brcmsmac: use ARRAY_SIZE on rfseq_updategainu_events
Dan Carpenter (1):
ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()
Dedy Lansky (1):
wil6210: print human readable names of WMI commands and events
Emmanuel Grumbach (5):
iwlwifi: mvm: rs: don't override the rate history in the search cycle
iwlwifi: mvm: revert support new Coex firmware API
iwlwifi: print the version number of the firmware in hex
iwlwifi: fix the ALIVE notification layout
iwlwifi: mvm: remove set but unused variable in iwl_mvm_roc_done_wk
Eyal Ilsar (1):
wcn36xx: set default BTLE coexistence config
Felix Fietkau (3):
dt-bindings: net: add mt76 wireless device binding
mt76: add common code shared between multiple chipsets
mt76: add driver code for MT76x2e
Gregory Greenman (7):
iwlwifi: mvm: rs: introduce new API for rate scaling
iwlwifi: mvm: rs: add ops for the new rate scaling in the FW
iwlwifi: mvm: rs: add basic implementation of the new RS API handlers
iwlwifi: mvm: rs: new rate scale API - add FW notifications
iwlwifi: mvm: rs: new rate scale API - add debugfs hooks
iwlwifi: mvm: rs: add size checks when printing to a buffer
iwlwifi: mvm: rs: add sanity check when sending LQ command
Gustavo A. R. Silva (1):
ath9k: dfs: use swap macro in ath9k_check_chirping
Hamad Kadmany (1):
wil6210: abort properly in cfg suspend
Ian Molton (20):
brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
brcmfmac: Register sizes on hardware are not dependent on compiler types
brcmfmac: Split brcmf_sdiod_regrw_helper() up.
brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()
brcmfmac: Remove dead IO code
brcmfmac: Remove bandaid for SleepCSR
brcmfmac: Remove brcmf_sdiod_request_data()
brcmfmac: Fix asymmetric IO functions.
brcmfmac: Remove noisy debugging.
brcmfmac: Rename bcmerror to err
brcmfmac: Split brcmf_sdiod_buffrw function up.
brcmfmac: whitespace fixes in brcmf_sdiod_send_buf()
brcmfmac: Clarify if using braces.
brcmfmac: Rename / replace old IO functions with simpler ones.
brcmfmac: Tidy register definitions a little
brcmfmac: Remove brcmf_sdiod_addrprep()
brcmfmac: remove unnecessary call to brcmf_sdiod_set_backplane_window()
brcmfmac: Cleanup offsetof()
brcmfmac: Remove unused macro.
brcmfmac: Remove repeated calls to brcmf_chip_get_core()
Johannes Berg (3):
iwlwifi: mvm: remove TCP wakeup support
iwlwifi: mvm: remove superfluous flush_work()
iwlwifi: mvm: request statistics when reading debugfs
Jérémy Lefaure (1):
wireless: use ARRAY_SIZE
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2017-11-29' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2017-12-05' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Kenneth Lu (2):
ath6kl: remove redundant variable ies_len
ath6kl: improve endianness handling
Larry Finger (1):
rtlwifi: Convert individual interrupt results to struct
Lazar Alexei (5):
wil6210: run-time PM when interface down
wil6210: get suspend reject reason and resume triggers from FW
wil6210: fix PCIe bus mastering in case of interface down
wil6210: remove suspend time statistics
wil6210: update statistics for suspend
Liad Kaufman (3):
iwlwifi: mvm: support MGMT frames in compressed BA
iwlwifi: dbg: allow wrt collection before ALIVE
iwlwifi: mvm: make init_dbg effective only on failure
Limin Zhu (1):
mwifiex: cfg80211: do not change virtual interface during scan processing
Lior David (5):
wil6210: refresh FW capabilities during interface up
wil6210: fix length check in __wmi_send
wil6210: add block size checks during FW load
wil6210: missing length check in wmi_set_ie
wil6210: missing length check in wil_cfg80211_mgmt_tx
Loic Poulain (1):
wcn36xx: Add hardware scan offload support
Luca Coelho (3):
iwlwifi: rename the temporary name of A000 to the official 22000
iwlwifi: bump FW API to 36 for 8000 and up
iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports
Manikanta Pubbisetty (2):
ath10k: update tdls teardown state to target
ath10k: handle tdls peer events
Matthias Schiffer (2):
ath9k: move spectral scan support under a separate config symbol
ath10k: move spectral scan support under a separate config symbol
Nicolas Iooss (1):
rtlwifi: always initialize variables given to RT_TRACE()
Ping-Ke Shih (4):
rtlwifi: Reduce IO in RX interrupt to boost throughput
rtlwifi: fix the wrong size to calculate fifo space
rtlwifi: cleanup the code that check whether TX ring is available
rtlwifi: rtl_pci: 8822BE puts broadcast and multicast packet to HIQ
Rajkumar Manoharan (1):
ath10k: unify rx processing in napi_poll
Rakesh Pillai (4):
ath10k: wmi: modify svc bitmap parsing for wcn3990
ath10k: wmi: add management tx by reference support over wmi
ath10k: wmi: get wmi init parameter values from hw params
ath10k: wmi: add hw params entry for wcn3990
Reizer, Eyal (1):
wlcore: allow elp during wowlan suspend
Sara Sharon (2):
iwlwifi: mvm: check for short GI only for OFDM
iwlwifi: mvm: avoid dumping assert log when device is stopped
Sven Eckelmann (2):
dt: bindings: add new dt entry for ath10k calibration variant
ath10k: search DT for qcom,ath10k-calibration-variant
Toke Høiland-Jørgensen (1):
ath10k: re-enable TXQs for all devices
Tsang-Shian Lin (1):
rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
Vincent Legoll (1):
ssb: make SSB a menuconfig to ease disabling it all
Weixiao Zhang (1):
mwl8k: Expand non-DFS 5G channels
Wright Feng (1):
brcmfmac: enlarge buffer size of caps to 512 bytes
Xinming Hu (1):
mwifiex: do not support change AP interface to station mode
.../bindings/net/wireless/mediatek,mt76.txt | 32 +
.../bindings/net/wireless/qcom,ath10k.txt | 3 +
drivers/bcma/driver_pcie2.c | 3 +-
drivers/net/wireless/ath/ath10k/Kconfig | 9 +-
drivers/net/wireless/ath/ath10k/Makefile | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 95 ++-
drivers/net/wireless/ath/ath10k/core.h | 10 +-
drivers/net/wireless/ath/ath10k/debug.c | 18 +-
drivers/net/wireless/ath/ath10k/debug.h | 21 +-
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 27 -
drivers/net/wireless/ath/ath10k/htt.h | 19 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 181 +++--
drivers/net/wireless/ath/ath10k/hw.c | 2 +
drivers/net/wireless/ath/ath10k/hw.h | 14 +
drivers/net/wireless/ath/ath10k/mac.c | 65 +-
drivers/net/wireless/ath/ath10k/spectral.h | 4 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 9 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 146 +++-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 113 +++
drivers/net/wireless/ath/ath10k/wmi.c | 72 ++
drivers/net/wireless/ath/ath10k/wmi.h | 5 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 -
drivers/net/wireless/ath/ath6kl/txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 14 +-
drivers/net/wireless/ath/ath9k/Makefile | 4 +-
drivers/net/wireless/ath/ath9k/common-spectral.h | 4 +-
drivers/net/wireless/ath/ath9k/dfs.c | 8 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 +
drivers/net/wireless/ath/wcn36xx/hal.h | 107 ++-
drivers/net/wireless/ath/wcn36xx/main.c | 16 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 126 +++-
drivers/net/wireless/ath/wcn36xx/smd.h | 3 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 17 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 150 +++-
drivers/net/wireless/ath/wil6210/ethtool.c | 15 +
drivers/net/wireless/ath/wil6210/fw_inc.c | 79 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 22 +-
drivers/net/wireless/ath/wil6210/main.c | 26 +-
drivers/net/wireless/ath/wil6210/netdev.c | 18 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 97 ++-
drivers/net/wireless/ath/wil6210/pm.c | 104 ++-
drivers/net/wireless/ath/wil6210/wil6210.h | 40 +-
drivers/net/wireless/ath/wil6210/wmi.c | 304 +++++++-
drivers/net/wireless/ath/wil6210/wmi.h | 17 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 377 +++------
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 12 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 248 +++---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 52 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 3 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 462 +++---------
drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 216 ++++++
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 216 ------
drivers/net/wireless/intel/iwlwifi/fw/api/alive.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/coex.h | 30 -
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 2 +-
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 15 +
drivers/net/wireless/intel/iwlwifi/fw/api/rs.h | 262 ++++++-
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 15 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 5 +-
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 8 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 20 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 11 +-
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 12 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 33 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 232 +-----
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 91 ++-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 14 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 43 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 18 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 314 ++++++++
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 234 +++---
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 48 ++
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 35 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 29 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 7 +-
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 20 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 14 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 36 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 4 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 7 +-
drivers/net/wireless/marvell/mwl8k.c | 7 +-
drivers/net/wireless/mediatek/Kconfig | 1 +
drivers/net/wireless/mediatek/Makefile | 1 +
drivers/net/wireless/mediatek/mt76/Kconfig | 10 +
drivers/net/wireless/mediatek/mt76/Makefile | 15 +
drivers/net/wireless/mediatek/mt76/debugfs.c | 77 ++
drivers/net/wireless/mediatek/mt76/dma.c | 451 +++++++++++
drivers/net/wireless/mediatek/mt76/dma.h | 38 +
drivers/net/wireless/mediatek/mt76/eeprom.c | 112 +++
drivers/net/wireless/mediatek/mt76/mac80211.c | 393 ++++++++++
drivers/net/wireless/mediatek/mt76/mmio.c | 61 ++
drivers/net/wireless/mediatek/mt76/mt76.h | 360 +++++++++
drivers/net/wireless/mediatek/mt76/mt76x2.h | 227 ++++++
drivers/net/wireless/mediatek/mt76/mt76x2_core.c | 88 +++
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 133 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c | 493 ++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h | 80 ++
drivers/net/wireless/mediatek/mt76/mt76x2_dma.c | 183 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_dma.h | 68 ++
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c | 647 ++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h | 182 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 839 +++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 755 ++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.h | 190 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 545 +++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c | 451 +++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h | 155 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_pci.c | 110 +++
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 758 +++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_regs.h | 587 ++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_trace.c | 23 +
drivers/net/wireless/mediatek/mt76/mt76x2_trace.h | 144 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 258 +++++++
drivers/net/wireless/mediatek/mt76/trace.c | 23 +
drivers/net/wireless/mediatek/mt76/trace.h | 71 ++
drivers/net/wireless/mediatek/mt76/tx.c | 511 +++++++++++++
drivers/net/wireless/mediatek/mt76/util.c | 78 ++
drivers/net/wireless/mediatek/mt76/util.h | 44 ++
.../net/wireless/realtek/rtl818x/rtl8187/rtl8225.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 75 +-
drivers/net/wireless/realtek/rtlwifi/pci.h | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 57 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 22 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/table.c | 14 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/table.c | 34 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 11 +-
drivers/net/wireless/ti/wl1251/init.c | 4 +-
drivers/net/wireless/ti/wlcore/acx.c | 2 +-
drivers/net/wireless/ti/wlcore/acx.h | 2 -
drivers/net/wireless/ti/wlcore/main.c | 41 +-
drivers/net/wireless/ti/wlcore/tx.c | 4 +-
drivers/ssb/Kconfig | 9 +-
159 files changed, 12700 insertions(+), 2097 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
create mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/22000.c
delete mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/a000.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
create mode 100644 drivers/net/wireless/mediatek/mt76/Kconfig
create mode 100644 drivers/net/wireless/mediatek/mt76/Makefile
create mode 100644 drivers/net/wireless/mediatek/mt76/debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mac80211.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mmio.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_core.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_init.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mac.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_main.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_pci.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_regs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.h
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id
From: Nikolay Aleksandrov @ 2017-12-18 14:22 UTC (permalink / raw)
To: Toshiaki Makita, netdev; +Cc: roopa, davem, stephen, avagin, bridge
In-Reply-To: <0d66d7ab-2837-afcb-430f-32f6e4a5d675@lab.ntt.co.jp>
On 12/18/2017 04:24 AM, Toshiaki Makita wrote:
> On 2017/12/16 20:31, Nikolay Aleksandrov wrote:
[snip]
> ...
>> err = br_changelink(dev, tb, data, extack);
>> - if (err)
>> + if (err) {
>> + /* clean possible fdbs from br_stp_change_bridge_id above */
>> + br_fdb_delete_by_port(br, NULL, 0, 1);
>
> Don't we need to call br_dev_delete (br_link_ops.dellink) after
> successful register instead of br_fdb_delete?
> Particularly I'm wondering if not calling br_sysfs_delbr() is ok or not.
>
Funny, that is actually the only reason we need to call it (br_sysfs_delbr). :-)
Good catch, that is another leak - the bridge sysfs entries are registered when
NETDEV_REGISTER event happens (register_netdevice) but are not properly cleaned up
on error there. This has also been present since the introduction of changelink
during newlink, commit:
b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
I'll send v2 that does br_dev_delete(dev, NULL) instead of the current cleanup.
With kobject debug enabled and that I can see "brif" and the rest of the sysfs
files getting freed properly, while before they weren't.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id
From: Nikolay Aleksandrov @ 2017-12-18 14:23 UTC (permalink / raw)
To: Toshiaki Makita, netdev; +Cc: bridge, roopa, avagin, davem
In-Reply-To: <4b07ce51-177d-df6f-f5ac-321f85402b6c@cumulusnetworks.com>
On 12/18/2017 04:22 PM, Nikolay Aleksandrov wrote:
> On 12/18/2017 04:24 AM, Toshiaki Makita wrote:
>> On 2017/12/16 20:31, Nikolay Aleksandrov wrote:
> [snip]
>> ...
>>> err = br_changelink(dev, tb, data, extack);
>>> - if (err)
>>> + if (err) {
>>> + /* clean possible fdbs from br_stp_change_bridge_id above */
>>> + br_fdb_delete_by_port(br, NULL, 0, 1);
>>
>> Don't we need to call br_dev_delete (br_link_ops.dellink) after
>> successful register instead of br_fdb_delete?
>> Particularly I'm wondering if not calling br_sysfs_delbr() is ok or not.
>>
>
> Funny, that is actually the only reason we need to call it (br_sysfs_delbr). :-)
>
> Good catch, that is another leak - the bridge sysfs entries are registered when
> NETDEV_REGISTER event happens (register_netdevice) but are not properly cleaned up
> on error there. This has also been present since the introduction of changelink
> during newlink, commit:
> b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
err, since the changelink was fixed to be after device registration in commit:
5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
>
> I'll send v2 that does br_dev_delete(dev, NULL) instead of the current cleanup.
> With kobject debug enabled and that I can see "brif" and the rest of the sysfs
> files getting freed properly, while before they weren't.
>
> Thanks,
> Nik
>
^ permalink raw reply
* Re: [PATCH net] sctp: fix the issue that a __u16 variable may overflow in sctp_ulpq_renege
From: Neil Horman @ 2017-12-18 14:33 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <047a7d68a197ff748b48eb8cda4b08fd5b9623fe.1513577245.git.lucien.xin@gmail.com>
On Mon, Dec 18, 2017 at 02:07:25PM +0800, Xin Long wrote:
> Now when reneging events in sctp_ulpq_renege(), the variable freed
> could be increased by a __u16 value twice while freed is of __u16
> type. It means freed may overflow at the second addition.
>
> This patch is to fix it by using __u32 type for 'freed', while at
> it, also to remove 'if (chunk)' check, as all renege commands are
> generated in sctp_eat_data and it can't be NULL.
>
> Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/ulpqueue.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
> index a71be33..e36ec5d 100644
> --- a/net/sctp/ulpqueue.c
> +++ b/net/sctp/ulpqueue.c
> @@ -1084,29 +1084,21 @@ void sctp_ulpq_partial_delivery(struct sctp_ulpq *ulpq,
> void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
> gfp_t gfp)
> {
> - struct sctp_association *asoc;
> - __u16 needed, freed;
> -
> - asoc = ulpq->asoc;
> + struct sctp_association *asoc = ulpq->asoc;
> + __u32 freed = 0;
> + __u16 needed;
>
> - if (chunk) {
> - needed = ntohs(chunk->chunk_hdr->length);
> - needed -= sizeof(struct sctp_data_chunk);
> - } else
> - needed = SCTP_DEFAULT_MAXWINDOW;
> -
> - freed = 0;
> + needed = ntohs(chunk->chunk_hdr->length) -
> + sizeof(struct sctp_data_chunk);
>
> if (skb_queue_empty(&asoc->base.sk->sk_receive_queue)) {
> freed = sctp_ulpq_renege_order(ulpq, needed);
> - if (freed < needed) {
> + if (freed < needed)
> freed += sctp_ulpq_renege_frags(ulpq, needed - freed);
> - }
> }
> /* If able to free enough room, accept this chunk. */
> - if (chunk && (freed >= needed)) {
> - int retval;
> - retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
> + if (freed >= needed) {
> + int retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
> /*
> * Enter partial delivery if chunk has not been
> * delivered; otherwise, drain the reassembly queue.
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] wil6210: fix build warnings without CONFIG_PM
From: Kalle Valo @ 2017-12-18 14:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: qca_merez, QCA_ailizaro, qca_dlansky, QCA_hkadmany, qca_liord,
QCA_gidons, linux-wireless@vger.kernel.org, wil6210,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20171218134604.3087909-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The #ifdef checks are hard to get right, in this case some functions
> should have been left inside a CONFIG_PM_SLEEP check as seen by this
> message:
>
> drivers/net/wireless/ath/wil6210/pcie_bus.c:489:12: error: 'wil6210_pm_resume' defined but not used [-Werror=unused-function]
> drivers/net/wireless/ath/wil6210/pcie_bus.c:484:12: error: 'wil6210_pm_suspend' defined but not used [-Werror=unused-function]
>
> Using an __maybe_unused is easier here, so I'm replacing all the
> other #ifdef in this file as well for consistency.
>
> Fixes: 94162666cd51 ("wil6210: run-time PM when interface down")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A note to myself (unfortunately patchwork doesn't have any way to add
notes to patches): 94162666cd51 is in wireless-drivers-next so this
patch should also go to -next.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net] sctp: add SCTP_CID_RECONF conversion in sctp_cname
From: Neil Horman @ 2017-12-18 14:37 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <ae9172b7dc432d6092ab2bc061a0cf322a3939b5.1513577597.git.lucien.xin@gmail.com>
On Mon, Dec 18, 2017 at 02:13:17PM +0800, Xin Long wrote:
> Whenever a new type of chunk is added, the corresp conversion in
> sctp_cname should be added. Otherwise, in some places, pr_debug
> will print it as "unknown chunk".
>
> Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/debug.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> index 3f619fd..291c97b 100644
> --- a/net/sctp/debug.c
> +++ b/net/sctp/debug.c
> @@ -78,6 +78,9 @@ const char *sctp_cname(const union sctp_subtype cid)
> case SCTP_CID_AUTH:
> return "AUTH";
>
> + case SCTP_CID_RECONF:
> + return "RECONF";
> +
> default:
> break;
> }
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next] udp: handle gro_receive only when necessary
From: Paolo Abeni @ 2017-12-18 14:45 UTC (permalink / raw)
To: zhangliping; +Cc: davem, netdev, zhangliping
In-Reply-To: <1f4bfef5.b4c7.16069879c26.Coremail.zhanglkk1990@163.com>
On Mon, 2017-12-18 at 20:09 +0800, zhangliping wrote:
> My test case is very simple, two VMs were connected via ovs + dpdk.
> Inside VM, rps is enabled. Then one VM runs "iperf -s -u &", another
> VM runs "iperf -c 1.1.1.2 -P 12 -u -b 10Gbps -l 40 -t 36000".
Understood, thanks. Still the time spent in 'udp4_lib_lookup2' looks
quite different/higher than what I observe in my tests. Are you using
x86_64? if not, do you see many cache misses in udp4_lib_lookup2?
Thanks,
Paolo
^ permalink raw reply
* [PATCH RESEND] Bluetooth: Prevent stack info leak from the EFS element.
From: Greg Kroah-Hartman @ 2017-12-18 14:47 UTC (permalink / raw)
To: netdev
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Ben Seri,
linux-kernel
From: Ben Seri <ben@armis.com>
In the function l2cap_parse_conf_rsp and in the function
l2cap_parse_conf_req the following variable is declared without
initialization:
struct l2cap_conf_efs efs;
In addition, when parsing input configuration parameters in both of
these functions, the switch case for handling EFS elements may skip the
memcpy call that will write to the efs variable:
...
case L2CAP_CONF_EFS:
if (olen == sizeof(efs))
memcpy(&efs, (void *)val, olen);
...
The olen in the above if is attacker controlled, and regardless of that
if, in both of these functions the efs variable would eventually be
added to the outgoing configuration request that is being built:
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs);
So by sending a configuration request, or response, that contains an
L2CAP_CONF_EFS element, but with an element length that is not
sizeof(efs) - the memcpy to the uninitialized efs variable can be
avoided, and the uninitialized variable would be returned to the
attacker (16 bytes).
This issue has been assigned CVE-2017-1000410
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Ben Seri <ben@armis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bluetooth/l2cap_core.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
David, can you take this through your tree? It fixes a reported issue
and the bluetooth developers seem to be totally ignoring it for weeks
for some unknown reason :(
Or, I can take it through one of mine if you don't want to touch it.
thanks,
greg k-h
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 43ba91c440bc..fc6615d59165 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3363,9 +3363,10 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
break;
case L2CAP_CONF_EFS:
- remote_efs = 1;
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
+ remote_efs = 1;
memcpy(&efs, (void *) val, olen);
+ }
break;
case L2CAP_CONF_EWS:
@@ -3584,16 +3585,17 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
break;
case L2CAP_CONF_EFS:
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
memcpy(&efs, (void *)val, olen);
- if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != chan->local_stype)
- return -ECONNREFUSED;
+ if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != chan->local_stype)
+ return -ECONNREFUSED;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
- (unsigned long) &efs, endptr - ptr);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
+ (unsigned long) &efs, endptr - ptr);
+ }
break;
case L2CAP_CONF_FCS:
^ permalink raw reply related
* Re: [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Michał Mirosław @ 2017-12-18 14:48 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev, David S . Miller, Janos Laube, Paulius Zaleckas,
Linux ARM, Hans Ulli Kroll, Florian Fainelli, Tobias Waldvogel
In-Reply-To: <CACRpkdZ3t9ZDB-GOoriq0Jm=-GtYzUX-qc36o_XbWO9NQzMUmA@mail.gmail.com>
On Mon, Dec 18, 2017 at 02:57:37PM +0100, Linus Walleij wrote:
> On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > The Gemini ethernet has been around for years as an out-of-tree
> > patch used with the NAS boxen and routers built on StorLink
> > SL3512 and SL3516, later Storm Semiconductor, later Cortina
> > Systems. These ASICs are still being deployed and brand new
> > off-the-shelf systems using it can easily be acquired.
[...]
> > ---
> > Changes from v8:
> > - Remove dependency guards in Kconfig to get a wider compile
> > coverage for the driver to detect broken APIs etc.
>
> I guess we need to hold this off for a while, the code does
> some weird stuff using the ARM-internal page DMA mapping
> API.
>
> I *think* what happens is that the driver allocates a global queue
> used for RX and TX on both interfaces, then initializes that with
> page pointers and gives that to the hardware to play with.
>
> When an RX packet comes in, the RX routine needs to figure
> out from the DMA (physical) address which remapped
> page/address this random physical address pointer
> corresponds to.
>
> The Linux DMA API assumption is that the driver keeps track
> of this mapping, not the hardware. So we need to figure out
> a way to reverse-map this. Preferably quickly, and without
> using any ARM-internal mapping APIs.
IIRC, the hardware copies descriptors from free queue (FREEQ)
to RX queues. FREEQ is shared among the two ethernet ports.
This platform is CPU bound, so every additional lookup will
hit performance here. In my version I had an #ifdef for
COMPILE_TEST that replaced ARM-specific calls with stubs.
Since the driver is not expected to work on other platforms,
this seemed like the best workaround to make it compile
on other arches.
Best Regards,
Michał Mirosław
^ 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