summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-04-25libbpf: add binary to gitignoreMatteo Croce
Some binaries are generated when building libbpf from tools/lib/bpf/, namely libbpf.so.0.0.2 and libbpf.so.0. Add them to the local .gitignore. Signed-off-by: Matteo Croce <mcroce@redhat.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-25tools: bpftool: fix infinite loop in map createAlban Crequy
"bpftool map create" has an infinite loop on "while (argc)". The error case is missing. Symptoms: when forgetting to type the keyword 'type' in front of 'hash': $ sudo bpftool map create /sys/fs/bpf/dir/foobar hash key 8 value 8 entries 128 (infinite loop, taking all the CPU) ^C After the patch: $ sudo bpftool map create /sys/fs/bpf/dir/foobar hash key 8 value 8 entries 128 Error: unknown arg hash Fixes: 0b592b5a01be ("tools: bpftool: add map create command") Signed-off-by: Alban Crequy <alban@kinvolk.io> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-25MIPS: eBPF: Make ebpf_to_mips_reg() staticYueHaibing
Fix sparse warning: arch/mips/net/ebpf_jit.c:196:5: warning: symbol 'ebpf_to_mips_reg' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-26Merge tag 'drm-intel-fixes-2019-04-24' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes A fix for display lanes calculation for BXT and a protection to avoid enabling FEC without DSC. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190424215359.GA26100@intel.com
2019-04-25seccomp: Make NEW_LISTENER and TSYNC flags exclusiveTycho Andersen
As the comment notes, the return codes for TSYNC and NEW_LISTENER conflict, because they both return positive values, one in the case of success and one in the case of error. So, let's disallow both of these flags together. While this is technically a userspace break, all the users I know of are still waiting on me to land this feature in libseccomp, so I think it'll be safe. Also, at present my use case doesn't require TSYNC at all, so this isn't a big deal to disallow. If someone wanted to support this, a path forward would be to add a new flag like TSYNC_AND_LISTENER_YES_I_UNDERSTAND_THAT_TSYNC_WILL_JUST_RETURN_EAGAIN, but the use cases are so different I don't see it really happening. Finally, it's worth noting that this does actually fix a UAF issue: at the end of seccomp_set_mode_filter(), we have: if (flags & SECCOMP_FILTER_FLAG_NEW_LISTENER) { if (ret < 0) { listener_f->private_data = NULL; fput(listener_f); put_unused_fd(listener); } else { fd_install(listener, listener_f); ret = listener; } } out_free: seccomp_filter_free(prepared); But if ret > 0 because TSYNC raced, we'll install the listener fd and then free the filter out from underneath it, causing a UAF when the task closes it or dies. This patch also switches the condition to be simply if (ret), so that if someone does add the flag mentioned above, they won't have to remember to fix this too. Reported-by: syzbot+b562969adb2e04af3442@syzkaller.appspotmail.com Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace") CC: stable@vger.kernel.org # v5.0+ Signed-off-by: Tycho Andersen <tycho@tycho.ws> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: James Morris <jamorris@linux.microsoft.com>
2019-04-25selftests/seccomp: Prepare for exclusive seccomp flagsKees Cook
Some seccomp flags will become exclusive, so the selftest needs to be adjusted to mask those out and test them individually for the "all flags" tests. Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Tycho Andersen <tycho@tycho.ws> Acked-by: James Morris <jamorris@linux.microsoft.com>
2019-04-26power: supply: sysfs: prevent endless uevent loop with CONFIG_POWER_SUPPLY_DEBUGAndrey Smirnov
Fix a similar endless event loop as was done in commit 8dcf32175b4e ("i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE"): The culprit is the dev_dbg printk in the i2c uevent handler. If this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results in an endless loop with systemd-journald. This happens if user-space scans the system log and reads the uevent file to get information about a newly created device, which seems fair use to me. Unfortunately reading the "uevent" file uses the same function that runs for creating the uevent for a new device, generating the next syslog entry Both CONFIG_I2C_DEBUG_CORE and CONFIG_POWER_SUPPLY_DEBUG were reported in https://bugs.freedesktop.org/show_bug.cgi?id=76886 but only former seems to have been fixed. Drop debug prints as it was done in I2C subsystem to resolve the issue. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Chris Healy <cphealy@gmail.com> Cc: linux-pm@vger.kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-04-25bpftool: show flow_dissector attachment statusStanislav Fomichev
Right now there is no way to query whether BPF flow_dissector program is attached to a network namespace or not. In previous commit, I added support for querying that info, show it when doing `bpftool net`: $ bpftool prog loadall ./bpf_flow.o \ /sys/fs/bpf/flow type flow_dissector \ pinmaps /sys/fs/bpf/flow $ bpftool prog 3: flow_dissector name _dissect tag 8c9e917b513dd5cc gpl loaded_at 2019-04-23T16:14:48-0700 uid 0 xlated 656B jited 461B memlock 4096B map_ids 1,2 btf_id 1 ... $ bpftool net -j [{"xdp":[],"tc":[],"flow_dissector":[]}] $ bpftool prog attach pinned \ /sys/fs/bpf/flow/flow_dissector flow_dissector $ bpftool net -j [{"xdp":[],"tc":[],"flow_dissector":["id":3]}] Doesn't show up in a different net namespace: $ ip netns add test $ ip netns exec test bpftool net -j [{"xdp":[],"tc":[],"flow_dissector":[]}] Non-json output: $ bpftool net xdp: tc: flow_dissector: id 3 v2: * initialization order (Jakub Kicinski) * clear errno for batch mode (Quentin Monnet) Signed-off-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-04-25bpf: support BPF_PROG_QUERY for BPF_FLOW_DISSECTOR attach_typeStanislav Fomichev
target_fd is target namespace. If there is a flow dissector BPF program attached to that namespace, its (single) id is returned. v5: * drop net ref right after rcu unlock (Daniel Borkmann) v4: * add missing put_net (Jann Horn) v3: * add missing inline to skb_flow_dissector_prog_query static def (kbuild test robot <lkp@intel.com>) v2: * don't sleep in rcu critical section (Jakub Kicinski) * check input prog_cnt (exit early) Cc: Jann Horn <jannh@google.com> Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-04-25samples: bpf: add hbm sample to .gitignoreDaniel T. Lee
This commit adds hbm to .gitignore which is currently ommited from the ignore file. Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-04-25libbpf: fix samples/bpf build failure due to undefined UINT32_MAXDaniel T. Lee
Currently, building bpf samples will cause the following error. ./tools/lib/bpf/bpf.h:132:27: error: 'UINT32_MAX' undeclared here (not in a function) .. #define BPF_LOG_BUF_SIZE (UINT32_MAX >> 8) /* verifier maximum in kernels <= 5.1 */ ^ ./samples/bpf/bpf_load.h:31:25: note: in expansion of macro 'BPF_LOG_BUF_SIZE' extern char bpf_log_buf[BPF_LOG_BUF_SIZE]; ^~~~~~~~~~~~~~~~ Due to commit 4519efa6f8ea ("libbpf: fix BPF_LOG_BUF_SIZE off-by-one error") hard-coded size of BPF_LOG_BUF_SIZE has been replaced with UINT32_MAX which is defined in <stdint.h> header. Even with this change, bpf selftests are running fine since these are built with clang and it includes header(-idirafter) from clang/6.0.0/include. (it has <stdint.h>) clang -I. -I./include/uapi -I../../../include/uapi -idirafter /usr/local/include -idirafter /usr/include \ -idirafter /usr/lib/llvm-6.0/lib/clang/6.0.0/include -idirafter /usr/include/x86_64-linux-gnu \ -Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm -c progs/test_sysctl_prog.c -o - | \ llc -march=bpf -mcpu=generic -filetype=obj -o /linux/tools/testing/selftests/bpf/test_sysctl_prog.o But bpf samples are compiled with GCC, and it only searches and includes headers declared at the target file. As '#include <stdint.h>' hasn't been declared in tools/lib/bpf/bpf.h, it causes build failure of bpf samples. gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes \ -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ \ -I./tools/ lib/ -I./tools/include -I./tools/perf -c -o ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c; This commit add declaration of '#include <stdint.h>' to tools/lib/bpf/bpf.h to fix this problem. Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-04-25mtd: rawnand: marvell: Clean the controller state before each operationMiquel Raynal
Since the migration of the driver to stop using the legacy ->select_chip() hook, there is nothing deselecting the target anymore, thus the selection is not forced at the next access. Ensure the ND_RUN bit and the interrupts are always in a clean state. Cc: Daniel Mack <daniel@zonque.org> Cc: stable@vger.kernel.org Fixes: b25251414f6e00 ("mtd: rawnand: marvell: Stop implementing ->select_chip()") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Daniel Mack <daniel@zonque.org> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2019-04-25Merge branch 'libbpf-fixes'Alexei Starovoitov
Daniel Borkmann says: ==================== Two small fixes in relation to global data handling. Thanks! ==================== Acked-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-25bpf, libbpf: fix segfault in bpf_object__init_maps' pr_debug statementDaniel Borkmann
Ran into it while testing; in bpf_object__init_maps() data can be NULL in the case where no map section is present. Therefore we simply cannot access data->d_size before NULL test. Move the pr_debug() where it's safe to access. Fixes: d859900c4c56 ("bpf, libbpf: support global data/bss/rodata sections") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-25bpf, libbpf: handle old kernels more graceful wrt global data sectionsDaniel Borkmann
Andrii reported a corner case where e.g. global static data is present in the BPF ELF file in form of .data/.bss/.rodata section, but without any relocations to it. Such programs could be loaded before commit d859900c4c56 ("bpf, libbpf: support global data/bss/rodata sections"), whereas afterwards if kernel lacks support then loading would fail. Add a probing mechanism which skips setting up libbpf internal maps in case of missing kernel support. In presence of relocation entries, we abort the load attempt. Fixes: d859900c4c56 ("bpf, libbpf: support global data/bss/rodata sections") Reported-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-25sched/numa: Fix a possible divide-by-zeroXie XiuQi
sched_clock_cpu() may not be consistent between CPUs. If a task migrates to another CPU, then se.exec_start is set to that CPU's rq_clock_task() by update_stats_curr_start(). Specifically, the new value might be before the old value due to clock skew. So then if in numa_get_avg_runtime() the expression: 'now - p->last_task_numa_placement' ends up as -1, then the divider '*period + 1' in task_numa_placement() is 0 and things go bang. Similar to update_curr(), check if time goes backwards to avoid this. [ peterz: Wrote new changelog. ] [ mingo: Tweaked the code comment. ] Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: cj.chengjian@huawei.com Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20190425080016.GX11158@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-04-25Merge tag 'ceph-for-5.1-rc7' of git://github.com/ceph/ceph-clientLinus Torvalds
Pull ceph fixes from Ilya Dryomov: "dentry name handling fixes from Jeff and a memory leak fix from Zheng. Both are old issues, marked for stable" * tag 'ceph-for-5.1-rc7' of git://github.com/ceph/ceph-client: ceph: fix ci->i_head_snapc leak ceph: handle the case where a dentry has been renamed on outstanding req ceph: ensure d_name stability in ceph_dentry_hash() ceph: only use d_name directly when parent is locked
2019-04-25wlcore: simplify/fix/optimize reg_ch_conf_pending operationsPaolo Bonzini
Bitmaps are defined on unsigned longs, so the usage of u32[2] in the wlcore driver is incorrect. As noted by Peter Zijlstra, casting arrays to a bitmap is incorrect for big-endian architectures. When looking at it I observed that: - operations on reg_ch_conf_pending is always under the wl_lock mutex, so set_bit is overkill - the only case where reg_ch_conf_pending is accessed a u32 at a time is unnecessary too. This patch cleans up everything in this area, and changes tmp_ch_bitmap to have the proper alignment. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25Revert "brcmfmac: send mailbox interrupt twice for specific hardware device"Kalle Valo
This reverts commit 99d94ef367af67f630b38c93ff46c5819b7d06b6. I accidentally applied this broken (failed to compile) patch due to a bug in my patchwork script. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25brcmfmac: send mailbox interrupt twice for specific hardware deviceWright Feng
For PCIE wireless device with core revision less than 14, device may miss PCIE to System Backplane Interrupt via PCIEtoSBMailbox. So add sending mail box interrupt twice as a hardware workaround. Signed-off-by: Wright Feng <wright.feng@cypress.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2x00: add RT3883 supportGabor Juhos
Patch add support for RT3883 chip. Code was taken direclty from openwrt project and merge into one patch. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCsHans de Goede
The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which is way too generic. The DMI strings on which we are matching are somewhat generic too, but "To be filled by O.E.M." is less common then "Default string" and the system-sku and bios-version strings are pretty unique. Beside the DMI strings we also check the wifi-module chip-id and revision. I'm confident that the combination of all this is unique. Both the T8 and T11 use the same wifi-module, this commit adds DMI quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt . BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25p54: drop device reference count if fails to enable devicePan Bian
The function p54p_probe takes an extra reference count of the PCI device. However, the extra reference count is not dropped when it fails to enable the PCI device. This patch fixes the bug. Cc: stable@vger.kernel.org Signed-off-by: Pan Bian <bianpan2016@163.com> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rtlwifi: rtl8723ae: Fix missing break in switch statementGustavo A. R. Silva
Add missing break statement in order to prevent the code from falling through to case 0x1025, and erroneously setting rtlhal->oem_id to RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and none of the cases in switch (rtlefuse->eeprom_smid) match. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwifiex: fix spelling mistake "capabilties" -> "capabilities"Colin Ian King
There various spelling mistakes in function names and in message text. Fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25iwlegacy: fix spelling mistake "acumulative" -> "accumulative"Colin Ian King
Fix spelling mistakes in rx stats text. I missed these from an earlier round of fixing the same spelling mistake. Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwifiex: add support for SD8987 chipsetTamás Szűcs
This patch adds support for Marvell 88W8987 chipset with SDIO interface. Register offsets and supported feature flags are updated. The corresponding firmware image file shall be "mrvl/sd8987_uapsta.bin". Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwl8k: Fix rate_idx underflowPetr Štetiar
It was reported on OpenWrt bug tracking system[1], that several users are affected by the endless reboot of their routers if they configure 5GHz interface with channel 44 or 48. The reboot loop is caused by the following excessive number of WARN_ON messages: WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516 ieee80211_rx_napi+0x1fc/0xa54 [mac80211] as the messages are being correctly emitted by the following guard: case RX_ENC_LEGACY: if (WARN_ON(status->rate_idx >= sband->n_bitrates)) as the rate_idx is in this case erroneously set to 251 (0xfb). This fix simply converts previously used magic number to proper constant and guards against substraction which is leading to the currently observed underflow. 1. https://bugs.openwrt.org/index.php?do=details&task_id=2218 Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive") Cc: <stable@vger.kernel.org> Tested-by: Eubert Bao <bunnier@gmail.com> Reported-by: Eubert Bao <bunnier@gmail.com> Signed-off-by: Petr Štetiar <ynezz@true.cz> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25at76c50x-usb: Don't register led_trigger if usb_register_driver failedYueHaibing
Syzkaller report this: [ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338 [ 1213.469530] #PF error: [normal kernel read fault] [ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0 [ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI [ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8 [ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 1213.473514] RIP: 0010:strcmp+0x31/0xa0 [ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d [ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246 [ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6 [ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0 [ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004 [ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900 [ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0 [ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000 [ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0 [ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1213.473514] PKRU: 55555554 [ 1213.473514] Call Trace: [ 1213.473514] led_trigger_register+0x112/0x3f0 [ 1213.473514] led_trigger_register_simple+0x7a/0x110 [ 1213.473514] ? 0xffffffffc1c10000 [ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb] [ 1213.473514] do_one_initcall+0xbc/0x47d [ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0 [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40 [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40 [ 1213.473514] do_init_module+0x1b5/0x547 [ 1213.473514] load_module+0x6405/0x8c10 [ 1213.473514] ? module_frob_arch_sections+0x20/0x20 [ 1213.473514] ? kernel_read_file+0x1e6/0x5d0 [ 1213.473514] ? find_held_lock+0x32/0x1c0 [ 1213.473514] ? cap_capable+0x1ae/0x210 [ 1213.473514] ? __do_sys_finit_module+0x162/0x190 [ 1213.473514] __do_sys_finit_module+0x162/0x190 [ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0 [ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690 [ 1213.473514] ? wait_for_completion+0x370/0x370 [ 1213.473514] ? vfs_write+0x204/0x4a0 [ 1213.473514] ? do_syscall_64+0x18/0x450 [ 1213.473514] do_syscall_64+0x9f/0x450 [ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1213.473514] RIP: 0033:0x462e99 [ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 [ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 [ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003 [ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000 [ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc [ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004 If usb_register failed, no need to call led_trigger_register_simple. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 1264b951463a ("at76c50x-usb: add driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwl8k: fix error handling in mwl8k_post_cmd()Alexey Khoroshilov
If pci_map_single() fails in mwl8k_post_cmd(), it returns -ENOMEM immediately, while cleanup is required. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25b43: Remove empty function lpphy_papd_cal()Larry Finger
In commit d825db346270e ("b43: shut up clang -Wuninitialized variable warning"), the message noted that function lpphy_papd_cal() was empty and had an old TODO regarding its implementation. As the reverse engineering project that created the LP-PHY version of this driver has not been active for some time, it is safe to remove this empty function. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwifiex: prevent an array overflowDan Carpenter
The "rate_index" is only used as an index into the phist_data->rx_rate[] array in the mwifiex_hist_data_set() function. That array has MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some debugfs information. The "rate_index" variable comes from the network skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap it to prevent an array overflow. Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25zd1211rw: use struct_size() helperGustavo A. R. Silva
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace code of the following form: sizeof(struct usb_req_write_regs) + count * sizeof(struct reg_data) with: struct_size(req, reg_writes, count) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwifiex: use struct_size() in kzalloc()Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable regd_size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: miscallaneous changes for 9116 and commonSiva Rebbagondla
Below changes are done: * Device 80MHz clock should be disabled for 9116 in 20MHz band. * Default edca parameters should be used initially before connection. * Default TA aggregation is 3 for 9116. * Bootup parameters should be loaded first when channel is changed. * 4 byte register writes are possible for 9116. Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: reset device changes for 9116Siva Rebbagondla
Device reset register(watchdog timer related) addresses and values are different for 9116. Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: send new tx command frame wlan9116 featuresSiva Rebbagondla
For 9116 device, we have introduced w9116 features frame, which shall be send when radio capabilities confirm is received. Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: new bootup parameters for 9116Siva Rebbagondla
Bootup parameters are different for 9116 device. Check added for device model where-ever bootup parameters are being send. Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: change in device init frame sequence for 9116Siva Rebbagondla
Initial frame exchange sequence has been changed for 9116 chip. Getting MAC address using EEPROM read frame will be once common device configuration is done and RESET_MAC frame is sending after bootup parameters confirmation is received, which are different from RS9113 device Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: add firmware loading for 9116 deviceSiva Rebbagondla
New firmware files and firmware loading method are added for 9116. Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: move common part of firmware load to separate functionSiva Rebbagondla
Till software bootloader ready state, communication with device is common for 9113 and 9116. Hence moved that part of firmware loading to separate function rsi_prepare_fw_load(). Also LMAC_VER_OFFSET is different for 9113 and 9116, so renamed existing macro to LMAC_VER_OFFSET_9113 Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rsi: add new device model for 9116Siva Rebbagondla
9116 device id entry is added in both SDIO and USB interfaces. New enumberation value taken for the device model. Based on the device model detected run time, few device specific operations needs to be performed. adding rsi_dev_model to get device type in run time, as we can use same driver for 9113 and 9116 except few firmware load changes. Signed-off-by: Siva Rebbagondla <siva8118@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2x00mmio: remove legacy commentStanislaw Gruszka
Remove comment about fields that were removed. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2x00: remove not used entry fieldStanislaw Gruszka
Remove not used any longer queue_entry field and flag. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2x00: remove last_nostatus_checkStanislaw Gruszka
We do not any longer check txstatus timeout from tasklet, so do not need this optimization. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2800mmio: use timer and work for handling tx statuses timeoutsStanislaw Gruszka
Sometimes we can get into situation when there are pending statuses, but we do not get INT_SOURCE_CSR_TX_FIFO_STATUS. Handle this situation by arming timeout timer and read statuses (it will fix case when we just do not have irq) and queue work to handle case we missed statues from hardware FIFO. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2800mmio: fetch tx status changesStanislaw Gruszka
Prepare to use rt2800mmio_fetch_txstatus() in concurrent manner and drop return value since is not longer needed. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2800: move txstatus pending routineStanislaw Gruszka
Move rt2800usb_txstatus_pending routine to rt2800lib. It will be reused by rt2800mmio code. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2800: new flush implementation for SoC devicesStanislaw Gruszka
Use new flush_queue() callback for SoC devices, what was already done for PCIe devices. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25rt2800: partially restore old mmio txstatus behaviourStanislaw Gruszka
Do not disable txstatus interrupt and add quota of processed tx statuses in one tasklet. Quota is needed to allow to fed device with new frames during processing of tx statuses. Patch fixes about 15% performance degradation on some scenarios caused by 0b0d556e0ebb ("rt2800mmio: use txdone/txstatus routines from lib"). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>