- 07 Oct, 2016 40 commits
-
-
Russell King authored
commit 02ba38a5 upstream. pxa_timer wants to be able to call clk_enable() etc on this clock, but our clk_enable() implementation expects non-NULL enable/disable operations. Provide these dummy implementations. Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 80000005 [#1] ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.8.0-rc2+ #887 Hardware name: Intel-Assabet task: c0644590 task.stack: c0640000 PC is at 0x0 LR is at clk_enable+0x40/0x58 pc : [<00000000>] lr : [<c021b178>] psr: 600000d3 sp : c0641f60 ip : c0641f4c fp : c0641f74 r10: c1ffc7a0 r9 : 6901b118 r8 : 00000001 r7 : c0639a34 r6 : 0000001b r5 : a00000d3 r4 : c0645d70 r3 : c0645d78 r2 : 00000001 r1 : c0641ef0 r0 : c0645d70 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: c020717f Table: c020717f DAC: 00000053 Process swapper (pid: 0, stack limit = 0xc0640188) Stack: (0xc0641f60 to 0xc0642000) 1f60: 00384000 c08762e4 c0641f98 c0641f78 c063308c c021b144 00000000 00000000 1f80: 00000000 c0660b20 ffffffff c0641fa8 c0641f9c c06220ec c0633058 c0641fb8 1fa0: c0641fac c061f114 c06220dc c0641ff4 c0641fbc c061bb68 c061f0fc ffffffff 1fc0: ffffffff 00000000 c061b6cc c0639a34 c0660cd4 c0642038 c0639a30 c0645434 1fe0: c0204000 c06380f8 00000000 c0641ff8 c0208048 c061b954 00000000 00000000 Backtrace: [<c021b138>] (clk_enable) from [<c063308c>] (pxa_timer_nodt_init+0x40/0x120) r5:c08762e4 r4:00384000 [<c063304c>] (pxa_timer_nodt_init) from [<c06220ec>] (sa1100_timer_init+0x1c/0x20) r6:ffffffff r5:c0660b20 r4:00000000 [<c06220d0>] (sa1100_timer_init) from [<c061f114>] (time_init+0x24/0x2c) [<c061f0f0>] (time_init) from [<c061bb68>] (start_kernel+0x220/0x42c) [<c061b948>] (start_kernel) from [<c0208048>] (0xc0208048) r10:c06380f8 r8:c0204000 r7:c0645434 r6:c0639a30 r5:c0642038 r4:c0660cd4 Code: bad PC value ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Fixes: ee3a4020 ("ARM: 8250/1: sa1100: provide OSTIMER0 clock for pxa_timer") Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Russell King authored
commit 198b51e8 upstream. Since we switched to use pxa_timer, we need to provide the OSTIMER0 clock. However, as the clock is initialised early, we need to provide the clock early as well, so that pxa_timer can find it. Adding the clock to the clkdev table at core_initcall() time is way too late. Move the initialisation earlier. Fixes: ee3a4020 ("ARM: 8250/1: sa1100: provide OSTIMER0 clock for pxa_timer") Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hugo Grostabussiat authored
commit 539d5c48 upstream. Set cpu_alert0 temperature to 85°C instead of 850°C. Fixes: 32a5d2d1 ("ARM: dts: sun5i: Add cpu thermal zones to dtsi") Signed-off-by: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andreas Färber authored
commit b9700be5 upstream. In commit 99fc5ba0 ("ARM: dts: imx6sx: add i.mx6sx sabreauto board support") it should've been enable-sdio-wakeup (not -wakup). But that is now considered a legacy name for wakeup-source, so directly use the new name instead, as done in commit 26cefdd1 for the other occurrence. Fixes: 26cefdd1 ("ARM: dts: imx: replace legacy wakeup property with 'wakeup-source'") Signed-off-by: Andreas Färber <afaerber@suse.de> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
commit c488f007 upstream. The voltage ranges listed here are wrong. The pma8084 pldo supports three different overlapping voltage ranges with differing step sizes and the pma8084 ftsmps supports two. These ranges can be seen in the "native" spmi regulator driver (qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[] respectively. Port these ranges over to the RPM SMD regulator driver so that we list the appropriate set of supported voltages on these types of regulators. Fixes: ee01d0c9 ("regulator: qcom-smd: Add support for PMA8084") Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
commit 29028477 upstream. The voltage ranges listed here are wrong. The correct ranges can be seen in the "native" spmi regulator driver qcom_spmi-regulator.c at pldo_ranges[], ftsmps_ranges[] and boost_ranges[] for the pldo, ftsmps, and boost type regulators. Port these ranges over to the RPM SMD regulator driver so that we list the appropriate set of supported voltages on pldos. Doing this allows us to specify a voltage like 3075000 for l24, whereas before that wasn't a supported voltage. Fixes: da65e367 ("regulator: Regulator driver for the Qualcomm RPM") Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
commit 93bfe79b upstream. The mvs1 and mvs2 switches are actually called 5vs1 and 5vs2 on some datasheets. Let's rename them to match the datasheets and also match the RPM based regulator driver which calls these by their 5vs names (see qcom_smd-regulator.c). There aren't any users of these regulators so far, so there aren't any concerns of DT ABI breakage here. While we're here making updates to the switches, also mandate usage of the OCP irq for these switches too. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047 ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
commit 919163f6 upstream. The voltage switches support mode switching, so add support for these ops to those types of regulators. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047 ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
commit c333dfe8 upstream. The S4 supply is sometimes called the boost regulator because it outputs 5V. Typically it's connected to the 5vs1 and 5vs2 switches for use in USB OTG and HDMI applications. Add support for this regulator which was mistakenly left out from the initial submission of this driver. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: e92a4047 ("regulator: Add QCOM SPMI regulator driver") Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Douglas Anderson authored
commit c2588393 upstream. The original commit adding support for continuous voltage mode didn't handle the regulator ramp delay properly. It treated the delay as a fixed delay in uS despite the property being defined as uV / uS. Let's adjust it. Luckily there appear to be no users of this ramp delay for PWM regulators (as per grepping through device trees in linuxnext). Note also that the upper bound of usleep_range probably shouldn't be a full 1 ms longer than the lower bound since I've seen plenty of hardware with a ramp rate of ~5000 uS / uV and for small jumps the total delays are in the tens of uS. 1000 is way too much. We'll try to be dynamic and use 10%. NOTE: This commit doesn't add support for regulator-enable-ramp-delay. That could be done in a future patch when someone has a user of that featre. Though this patch is shows as "fixing" a bug, there are no actual known users of continuous mode PWM regulator w/ ramp delay in mainline and so this likely won't have any effect on anyone unless they are working out-of-tree with private patches. For anyone in this state, it is highly encouraged to also pick Boris Brezillon's WIP patches to get yourself a reliable and glitch-free regulator. Fixes: 4773be18 ("regulator: pwm-regulator: Add support for continuous-voltage") Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
apronin@chromium.org authored
commit 1b0612b0 upstream. The result must be converted from BE byte order, which is used by the TPM2 protocol. This has not popped out because tpm2_get_tpm_pt() has been only used for probing. Fixes: 7a1d7e6d ("tpm: TPM 2.0 baseline support") Change-Id: I7d71cd379b1a3b7659d20a1b6008216762596590 Signed-off-by: Andrey Pronin <apronin@chromium.org> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Geert Uytterhoeven authored
commit ed76b7a1 upstream. lib/test_hash.c: In function 'test_hash_init': lib/test_hash.c:146:2: warning: missing braces around initializer [-Wmissing-braces] Fixes: 468a9428 ("<linux/hash.h>: Add support for architecture-specific functions") Link: http://lkml.kernel.org/r/20160829214952.1334674-3-arnd@arndb.deSigned-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: George Spelvin <linux@sciencehorizons.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Borkmann authored
commit dbb50887 upstream. During an audit for sk_filter(), we found that rx_busy_skb handling in l2cap_sock_recv_cb() and l2cap_sock_recvmsg() looks not quite as intended. The assumption from commit e328140f ("Bluetooth: Use event-driven approach for handling ERTM receive buffer") is that errors returned from sock_queue_rcv_skb() are due to receive buffer shortage. However, nothing should prevent doing a setsockopt() with SO_ATTACH_FILTER on the socket, that could drop some of the incoming skbs when handled in sock_queue_rcv_skb(). In that case sock_queue_rcv_skb() will return with -EPERM, propagated from sk_filter() and if in L2CAP_MODE_ERTM mode, wrong assumption was that we failed due to receive buffer being full. From that point onwards, due to the to-be-dropped skb being held in rx_busy_skb, we cannot make any forward progress as rx_busy_skb is never cleared from l2cap_sock_recvmsg(), due to the filter drop verdict over and over coming from sk_filter(). Meanwhile, in l2cap_sock_recv_cb() all new incoming skbs are being dropped due to rx_busy_skb being occupied. Instead, just use __sock_queue_rcv_skb() where an error really tells that there's a receive buffer issue. Split the sk_filter() and enable it for non-segmented modes at queuing time since at this point in time the skb has already been through the ERTM state machine and it has been acked, so dropping is not allowed. Instead, for ERTM and streaming mode, call sk_filter() in l2cap_data_rcv() so the packet can be dropped before the state machine sees it. Fixes: e328140f ("Bluetooth: Use event-driven approach for handling ERTM receive buffer") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nicolas Iooss authored
commit ae6c33ba upstream. Commit bbeddf52 ("printk: move braille console support into separate braille.[ch] files") moved the parsing of braille-related options into _braille_console_setup(), changing the type of variable str from char* to char**. In this commit, memcmp(str, "brl,", 4) was correctly updated to memcmp(*str, "brl,", 4) but not memcmp(str, "brl=", 4). Update the code to make "brl=" option work again and replace memcmp() with strncmp() to make the compiler able to detect such an issue. Fixes: bbeddf52 ("printk: move braille console support into separate braille.[ch] files") Link: http://lkml.kernel.org/r/20160823165700.28952-1-nicolas.iooss_linux@m4x.orgSigned-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marcin Nowakowski authored
commit ca86c9ef upstream. arch_uprobe_pre_xol needs to emulate a branch if a branch instruction has been replaced with a breakpoint, but in fact an uninitialised local variable was passed to the emulator routine instead of the original instruction Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com> Fixes: 40e084a5 ('MIPS: Add uprobes support.') Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14300/Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Burton authored
commit 305723ab upstream. Malta boards used with CPU emulators feature a switch to disable use of an IOCU. Software has to check this switch & ignore any present IOCU if the switch is closed. The read used to do this was unsafe for 64 bit kernels, as it simply casted the address 0xbf403000 to a pointer & dereferenced it. Whilst in a 32 bit kernel this would access kseg1, in a 64 bit kernel this attempts to access xuseg & results in an address error exception. Fix by accessing a correctly formed ckseg1 address generated using the CKSEG1ADDR macro. Whilst modifying this code, define the name of the register and the bit we care about within it, which indicates whether PCI DMA is routed to the IOCU or straight to DRAM. The code previously checked that bit 0 was also set, but the least significant 7 bits of the CONFIG_GEN0 register contain the value of the MReqInfo signal provided to the IOCU OCP bus, so singling out bit 0 makes little sense & that part of the check is dropped. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Fixes: b6d92b4a ("MIPS: Add option to disable software I/O coherency.") Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Kees Cook <keescook@chromium.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14187/Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marcin Nowakowski authored
commit db06068a upstream. arch_uretprobe_hijack_return_addr should replace the return address for a call with a trampoline address. Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com> Fixes: 40e084a5 ('MIPS: Add uprobes support.') Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14298/Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marcin Nowakowski authored
commit ddabfa5c upstream. Generic kernel code implements a weak version of set_orig_insn that moves cached 'insn' from arch_uprobe to the original code location when the trap is removed. MIPS variant used arch_uprobe->orig_inst which was never initialised properly, so this code only inserted a nop instead of the original instruction. With that change orig_inst can also be safely removed. Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com> Fixes: 40e084a5 ('MIPS: Add uprobes support.') Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14299/Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit 3a402a70 upstream. When TIF_SINGLESTEP is set for a task, the single-step state machine is enabled and we must take care not to reset it to the active-not-pending state if it is already in the active-pending state. Unfortunately, that's exactly what user_enable_single_step does, by unconditionally setting the SS bit in the SPSR for the current task. This causes failures in the GDB testsuite, where GDB ends up missing expected step traps if the instruction being stepped generates another trap, e.g. PTRACE_EVENT_FORK from an SVC instruction. This patch fixes the problem by preserving the current state of the stepping state machine when TIF_SINGLESTEP is set on the current thread. Cc: <stable@vger.kernel.org> Reported-by: Yao Qi <yao.qi@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Srinivas Ramana authored
commit 117e5e9c upstream. If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Srinivas Ramana <sramana@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
James Morse authored
commit 727653d6 upstream. gic_raise_softirq() walks the list of cpus using for_each_cpu(), it calls gic_compute_target_list() which advances the iterator by the number of CPUs in the cluster. If gic_compute_target_list() reaches the last CPU it leaves the iterator pointing at the last CPU. This means the next time round the for_each_cpu() loop cpumask_next() will be called with an invalid CPU. This triggers a warning when built with CONFIG_DEBUG_PER_CPU_MAPS: [ 3.077738] GICv3: CPU1: found redistributor 1 region 0:0x000000002f120000 [ 3.077943] CPU1: Booted secondary processor [410fd0f0] [ 3.078542] ------------[ cut here ]------------ [ 3.078746] WARNING: CPU: 1 PID: 0 at ../include/linux/cpumask.h:121 gic_raise_softirq+0x12c/0x170 [ 3.078812] Modules linked in: [ 3.078869] [ 3.078930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc5+ #5188 [ 3.078994] Hardware name: Foundation-v8A (DT) [ 3.079059] task: ffff80087a1a0080 task.stack: ffff80087a19c000 [ 3.079145] PC is at gic_raise_softirq+0x12c/0x170 [ 3.079226] LR is at gic_raise_softirq+0xa4/0x170 [ 3.079296] pc : [<ffff0000083ead24>] lr : [<ffff0000083eac9c>] pstate: 200001c9 [ 3.081139] Call trace: [ 3.081202] Exception stack(0xffff80087a19fbe0 to 0xffff80087a19fd10) [ 3.082269] [<ffff0000083ead24>] gic_raise_softirq+0x12c/0x170 [ 3.082354] [<ffff00000808e614>] smp_send_reschedule+0x34/0x40 [ 3.082433] [<ffff0000080e80a0>] resched_curr+0x50/0x88 [ 3.082512] [<ffff0000080e89d0>] check_preempt_curr+0x60/0xd0 [ 3.082593] [<ffff0000080e8a60>] ttwu_do_wakeup+0x20/0xe8 [ 3.082672] [<ffff0000080e8bb8>] ttwu_do_activate+0x90/0xc0 [ 3.082753] [<ffff0000080ea9a4>] try_to_wake_up+0x224/0x370 [ 3.082836] [<ffff0000080eabc8>] default_wake_function+0x10/0x18 [ 3.082920] [<ffff000008103134>] __wake_up_common+0x5c/0xa0 [ 3.083003] [<ffff0000081031f4>] __wake_up_locked+0x14/0x20 [ 3.083086] [<ffff000008103f80>] complete+0x40/0x60 [ 3.083168] [<ffff00000808df7c>] secondary_start_kernel+0x15c/0x1d0 [ 3.083240] [<00000000808911a4>] 0x808911a4 [ 3.113401] Detected PIPT I-cache on CPU2 Avoid updating the iterator if the next call to cpumask_next() would cause the for_each_cpu() loop to exit. There is no change to gic_raise_softirq()'s behaviour, (cpumask_next()s eventual call to _find_next_bit() will return early as start >= nbits), this patch just silences the warning. Fixes: 021f6537 ("irqchip: gic-v3: Initial support for GICv3") Signed-off-by: James Morse <james.morse@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1474306155-3303-1-git-send-email-james.morse@arm.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Lüssing authored
commit 1e5d343b upstream. The skb_reserve() call only reserved headroom for the mac header, but not the elp packet header itself. Fixing this by using skb_put()'ing towards the skb tail instead of skb_push()'ing towards the skb head. Fixes: d6f94d91 ("batman-adv: ELP - adding basic infrastructure") Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sven Eckelmann authored
commit 93652344 upstream. batadv_find_router dereferences last_bonding_candidate from orig_node without making sure that it has a valid reference. This reference has to be retrieved by increasing the reference counter while holding neigh_list_lock. The lock is required to avoid that batadv_last_bonding_replace removes the current last_bonding_candidate, reduces the reference counter and maybe destroys the object in this process. Fixes: f3b3d901 ("batman-adv: add bonding again") Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Shiraz Saleem authored
commit b71121b4 upstream. Device notifications are not received after the first interface is closed; since there is an unregister for notifications on every interface close. Correct this by unregistering for device notifications only when the last interface is closed. Also, make all operations on the i40iw_notifiers_registered atomic as it can be read/modified concurrently. Fixes: 8e06af71 ("i40iw: add main, hdr, status") Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mustafa Ismail authored
commit 866e0f4d upstream. Update iwqp->hw_iwarp_state to reflect the new state of the CQP modify QP operation. This avoids reissuing a CQP operation to modify a QP to a state that it is already in. Fixes: 4e9042e6 ("i40iw: add hw and utils files") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tatyana Nikolova authored
commit 07c72d7d upstream. Send a zero length last streaming mode message for loopback connections to synchronize between accepting QP and connecting QP. This avoids data transfer to start on the accepting QP before the connecting QP is in RTS. Also remove function i40iw_loopback_nop() as it is no longer used. Fixes: f27b4746 ("i40iw: add connection management code") Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Shiraz Saleem authored
commit 5dfd5e5e upstream. Add NULL check for pdata and pdata->addr before the memcpy in i40iw_form_cm_frame(). This fixes a NULL pointer de-reference which occurs when the MPA private data pointer is NULL. Also only copy pdata->size bytes in the memcpy to prevent reading past the length of the private data buffer provided by upper layer. Fixes: f27b4746 ("i40iw: add connection management code") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mustafa Ismail authored
commit 433c5813 upstream. iwpbl->iwmr points to the structure that contains iwpbl, which is iwmr. Setting this to NULL would result in writing to freed memory. So just free iwmr, and return. Fixes: d3749841 ("i40iw: add files for iwarp interface") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mustafa Ismail authored
commit 7eaf8313 upstream. In i40iw_free_virt_mem(), do not set mem->va to NULL after freeing it as mem->va is a self-referencing pointer to mem. Fixes: 4e9042e6 ("i40iw: add hw and utils files") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mustafa Ismail authored
commit d41d0910 upstream. Memory allocated for iwqp; iwqp->allocated_buffer is freed twice in the create_qp error path. Correct this by having it freed only once in i40iw_free_qp_resources(). Fixes: d3749841 ("i40iw: add files for iwarp interface") Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Shiraz Saleem authored
commit 6c7d46fd upstream. iwdev->mem_resources is incorrectly defined as an unsigned long instead of u8. As a result, the offset into the dynamic allocated structures in i40iw_initialize_hw_resources() is incorrectly calculated and would lead to writing of memory regions outside of the allocated buffer. Fixes: 8e06af71 ("i40iw: add main, hdr, status") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mustafa Ismail authored
commit faa739fb upstream. In i40iw_open(), check if interface is already open and return success if it is. Fixes: 8e06af71 ("i40iw: add main, hdr, status") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mustafa Ismail authored
commit 44856be3 upstream. In i40iw_alloc_resource(), ensure that the update to req_resource_num is protected by the lock. Fixes: 8e06af71 ("i40iw: add main, hdr, status") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johannes Berg authored
commit 0b97a484 upstream. The A-MSDU TX code (within TXQs) didn't always check the return value of skb_linearize() properly, resulting in potentially passing a frag- list SKB down to the driver even when it said it can't handle it. Fix that. Fixes: 6e0456b5 ("mac80211: add A-MSDU tx support") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Russell King authored
commit 56beac95 upstream. ucb1x00 has used IRQ probing since it's dawn to find the GPIO interrupt that it's connected to. However, commit 23393d49 ("gpio: kill off set_irq_flags usage") broke this by disabling IRQ probing on GPIO interrupts. Fix this. Fixes: 23393d49 ("gpio: kill off set_irq_flags usage") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
commit f4693b08 upstream. We can't assign -EINVAL to a u16. Fixes: 3948f0e0 ('usb: add Freescale QE/CPM USB peripheral controller driver') Acked-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Emmanuel Grumbach authored
commit ff6e58e6 upstream. fw-dbg code return ret but that variable was either 0 or not initialised. Return 0 always. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: 6a951267 ("iwlwifi: mvm: send dbg config hcmds to fw if set in tlv") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
commit 5a7d87da upstream. gcc is apparently unablel to track the state of the local 'resp_v2' variable across the kzalloc() function, and warns about the response variable being used without an initialization: drivers/net/wireless/intel/iwlwifi/mvm/nvm.c: In function ‘iwl_mvm_update_mcc’: drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:727:36: warning: ‘mcc_resp_v1’ may be used uninitialized in this function [-Wmaybe-uninitialized] resp_cp->n_channels = mcc_resp_v1->n_channels; drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:721:3: warning: ‘mcc_resp’ may be used uninitialized in this function [-Wmaybe-uninitialized] memcpy(resp_cp, mcc_resp, resp_len); The warning showed up in x86 allmodconfig after my patch to unhide -Wmaybe-uninitialized warnings by default was merged, though it always existed in randconfig builds. I did not catch the warning earlier because I was testing on ARM, which never produced the warning. This rearranges the code in a way that improves readability for both humans and the compiler, and that avoids the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 6fa52430 ("iwlwifi: mvm: change mcc update API") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sara Sharon authored
commit 60dec523 upstream. Restart flow zeroes the rx_ba_sessions counter. Mac80211 asks driver to tear down of the session only afterwards, and as a result driver didn't free the data. Fix it. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Fixes: 10b2b201 ("iwlwifi: mvm: add infrastructure for tracking BA session in driver") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sara Sharon authored
commit d5d0689a upstream. This fixes a pretty ancient bug that hasn't manifested itself until now. The scratchbuf for command queue is allocated only for 32 slots but is accessed with the queue write pointer - which can be up to 256. Since the scratch buf size was 16 and there are up to 256 TFDs we never passed a page boundary when accessing the scratch buffer, but when attempting to increase the size of the scratch buffer a panic was quick to follow when trying to access the address resulted in a page boundary. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Fixes: 38c0f334 ("iwlwifi: use coherent DMA memory for command header") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-