- 14 May, 2020 40 commits
-
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 44361a2c upstream. MTD flash stores u-boot and u-boot environment on linkstation lswtgl. The latter one can be easily read/write by u-boot-tools package in Debian. Fixes: dc57844a ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl") Signed-off-by:
Roger Shimizu <rogershimizu@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ff61ee84 upstream. Here're a few gpio pin related fixes: - remove pinctrl-0 definition from pinctrl, since those pins are used in other places such as gpio-fan and regulators. - keep initial state of power led - fix for alarm pin of gpio-fan. Fixes: dc57844a ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl") Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0418138e upstream. The GPIOs controlling the LEDs, listed below, are active high, not low: - gpio-leds: "lswvl:red:alarm" pin - gpio-leds: "lswvl:red:func" pin - gpio-leds: "lswvl:amber:info" pin - gpio-leds: "lswvl:blue:func" pin - gpio-leds: "lswvl:red:hdderr{0,1}" pin Fixes: c43379e1 ("ARM: dts: add buffalo linkstation ls-wvl/vl") Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e98bd707 upstream. The GPIOs controlling the LEDs, listed below, are active high, not low: - gpio-leds: "lswxl:blue:power" pin - gpio-leds: "lswxl:red:func" pin - gpio-leds: "lswxl:red:hdderr{0,1}" pin Fixes: e54e4b1b ("ARM: dts: add buffalo linkstation ls-wxl/wsxl") Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6f86e9ad upstream. For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be converted to "gpio1 <pin minus 32>" in dts file. e.g. gpio 40 should be "gpio1 8" The pin/bank issue was found when discussing Debian Bug #810894 [https://bugs.debian.org/810894#47] Fixes: c43379e1 ("ARM: dts: add buffalo linkstation ls-wvl/vl") Reported-by:
Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 144e08ab upstream. For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be converted to "gpio1 <pin minus 32>" in dts file. e.g. gpio 40 should be "gpio1 8" Besides, a few other pin fixes for ls-wxl/wsxl, to match with mpp pin definition: - gpio-leds: "lswxl:blue:power" pin - gpio-leds: "lswxl:red:func" pin - gpio-leds: "lswxl:red:hdderr0" pin - gpio-leds: "lswxl:red:hdderr1" pin - gpio-fan: low/high/alarm pin The pin/bank issue was found when discussing Debian Bug #810894 [https://bugs.debian.org/810894#47] Fixes: e54e4b1b ("ARM: dts: add buffalo linkstation ls-wxl/wsxl") Reported-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f1858b0e upstream. The i.MX7 Kconfig option had a couple of missing select lines that I fixed already, but I missed HAVE_IMX_SRC: arch/arm/mach-imx/built-in.o: In function `imx7d_init_irq': platform-spi_imx.c:(.init.text+0x25a8): undefined reference to `imx_src_init' This adds that one as well. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 0be5da9d ("ARM: imx: imx7d requires anatop") Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c61f30a2 upstream. On r8a7740/armadillo, actual clock rates are ca. 4% lower than reported by /sys/kernel/debug/clk/clk_summary. Correct the extal1 frequency from 25 MHz to 24 MHz to fix this. This matches the Armadillo-800 EVA Product Manual, which claims the main crystal runs at 24 MHz, and the old legacy/reference board code. Fixes: 25aa7ba3 ("ARM: shmobile: armadillo800eva: Sync DTS") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Hidehiro Kawai authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 54c721b8 upstream. Daniel Walker reported problems which happens when crash_kexec_post_notifiers kernel option is enabled (https://lkml.org/lkml/2015/6/24/44). In that case, smp_send_stop() is called before entering kdump routines which assume other CPUs are still online. As the result, kdump routines fail to save other CPUs' registers. Additionally for MIPS OCTEON, it misses to stop the watchdog timer. To fix this problem, call a new kdump friendly function, crash_smp_send_stop(), instead of the smp_send_stop() when crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a weak function, and it just call smp_send_stop(). Architecture codes should override it so that kdump can work appropriately. This patch provides MIPS version. Fixes: f06e5153 (kernel/panic.c: add "crash_kexec_post_notifiers" option) Link: http://lkml.kernel.org/r/20160810080950.11028.28000.stgit@sysi4-13.yrl.intra.hitachi.co.jpSigned-off-by:
Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Reported-by:
Daniel Walker <dwalker@fifo99.com> Cc: Dave Young <dyoung@redhat.com> Cc: Baoquan He <bhe@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Daniel Walker <dwalker@fifo99.com> Cc: Xunlei Pang <xpang@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Toshi Kani <toshi.kani@hpe.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Daney <david.daney@cavium.com> Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: "Steven J. Hill" <steven.hill@cavium.com> Cc: Corey Minyard <cminyard@mvista.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 233b2ca1 upstream. AT_VECTOR_SIZE_ARCH should be defined with the maximum number of NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined for MIPS at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for the VDSO address. This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for AT_BASE_PLATFORM which MIPS doesn't use, but lets define it now and add the comment above ARCH_DLINFO as found in several other architectures to remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to date. Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13823/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 58a7e1c1 upstream. We obviously intended to enable IRQs again at the end. Fixes: 745aef5d ('MIPS: RM7000: Add support for tertiary cache') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: kernel-janitors@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13815/Signed-off-by:
-
Daniel Borkmann authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b4e76f7e upstream. Dan Carpenter reported [1] a static checker warning that ctx->offsets[] may be accessed off by one from build_body(), since it's allocated with fp->len * sizeof(*ctx.offsets) as length. The cBPF arm and ppc code doesn't have this issue as claimed, so only mips seems to be affected and should like most other JITs allocate with fp->len + 1. A few number of JITs (x86, sparc, arm64) handle this differently, where they only require fp->len array elements. [1] http://www.spinics.net/lists/mips/msg64193.html Fixes: c6610de3 ("MIPS: net: Add BPF JIT") Reported-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@kernel.org> Cc: ast@kernel.org Cc: linux-mips@linux-mips.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13814/Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 008d0cf1 upstream. It should be >= ARRAY_SIZE() instead of > ARRAY_SIZE(). Fixes: 64b139f9 ('MIPS: OCTEON: irq: add CIB and other fixes') Signed-off-by:
David Daney <david.daney@cavium.com> Cc: Rob Herring <robh@kernel.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-mips@linux-mips.org Cc: kernel-janitors@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13813/Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0758b116 upstream. The protected_writeback_scache_line() function is used by local_r4k_flush_cache_sigtramp() to flush an FPU delay slot emulation trampoline on the userland stack from the caches so it is visible to subsequent instruction fetches. Commit de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions") updated some protected_ cache flush functions to use EVA CACHEE instructions via protected_cachee_op(), and commit 83fd4344 ("MIPS: r4kcache: Add EVA case for protected_writeback_dcache_line") did the same thing for protected_writeback_dcache_line(), but protected_writeback_scache_line() never got updated. Lets fix that now to flush the right user address from the secondary cache rather than some arbitrary kernel unmapped address. This issue was spotted through code inspection, and it seems unlikely to be possible to hit this in practice. It theoretically affect EVA kernels on EVA capable cores with an L2 cache, where the icache fetches straight from RAM (cpu_icache_snoops_remote_store == 0), running a hard float userland with FPU disabled (nofpu). That both Malta and Boston platforms override cpu_icache_snoops_remote_store to 1 suggests that all MIPS cores fetch instructions into icache straight from L2 rather than RAM. Fixes: de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions") Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 826e99be upstream. When a CPU is disabled via CPU hotplug, cpu_foreign_map is not updated. This could result in cache management SMP calls being sent to offline CPUs instead of online siblings in the same core. Add a call to calculate_cpu_foreign_map() in the various MIPS cpu disable callbacks after set_cpu_online(). All cases are updated for consistency and to keep cpu_foreign_map strictly up to date, not just those which may support hardware multithreading. Fixes: cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores") Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 66ffc50c upstream. The MIPS KVM dynamic translation is meant to translate "MFC0 rt, ErrCtl" instructions into "ADD rt, zero, zero" to zero the destination register, however the rt register number was copied into rt of the ADD instruction encoding, which is the 2nd source operand. This results in "ADD zero, zero, rt" which is a no-op, so only the first execution of each such MFC0 from ErrCtl will actually read 0. Fix the shift to put the rt from the MFC0 encoding into the rd field of the ADD. Fixes: 50c83085 ("KVM/MIPS32: Binary patching of select privileged instructions.") Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit fd716fca upstream. Fix perf hardware performance counter event numbers for I6400. This core does not follow the performance event numbering scheme of previous MIPS cores. All performance counters (both odd and even) are capable of counting any of the available events. Fixes: 4e88a862 ("MIPS: Add cases for CPU_I6400") Signed-off-by:
-
Paul Burton authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ac149698 upstream. The conditions for branching when emulating the BC1EQZ & BC1NEZ instructions were backwards, leading to each of those instructions being treated as the other. Fix this by reversing the conditions, and clear up the code a little for readability & checkpatch. Fixes: c8a34581 ("MIPS: Emulate the BC1{EQ,NE}Z FPU instructions") Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Reviewed-by:
-
Paul Burton authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 93583e17 upstream. The conditions for branching when emulating the BC1EQZ & BC1NEZ instructions were backwards, leading to each of those instructions being treated as the other. Fix this by reversing the conditions, and clear up the code a little for readability & checkpatch. Fixes: c909ca71 ("MIPS: math-emu: Emulate missing BC1{EQ,NE}Z instructions") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 80fa40ac upstream. The CPU actually runs at 1405Mhz which gives us a 175625000 Hz MIPS timer frequency (CPU frequency / 8). Fixes: e4c7d009 ("MIPS: BMIPS: Add BCM7435 dtsi") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: linux-mips@linux-mips.org Cc: john@phrozen.org Cc: cernekee@gmail.com Cc: jaedon.shin@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/13132/Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 14bc2414 upstream. The hardware page table walker (HTW) configuration is broken on XPA kernels where XPA couldn't be enabled (either nohtw or the hardware doesn't support it). This is because the PWSize.PTEW field (PTE width) was only set to 8 bytes (an extra shift of 1) in config_htw_params() if PageGrain.ELPA (enable large physical addressing) is set. On an XPA kernel though the size of PTEs is fixed at 8 bytes regardless of whether XPA could actually be enabled. Fix the initialisation of this field based on sizeof(pte_t) instead. Fixes: c5b36783 ("MIPS: Add support for XPA.") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 37808d62 upstream. Just to ease debugging of multiplatform kernel, make sure we print "Broadcom BMIPS5200" for the BMIPS5200 implementation instead of Broadcom BMIPS5000. Fixes: 68e6a783 ("MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f675843d upstream. local_r4k___flush_cache_all() is missing a special check for BMIPS5000 processors, we need to blast the S-cache, just like other MTI processors since we have an inclusive cache. We also need an additional __sync() to make sure this is completed. Fixes: d74b0172 ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 73c4ca04 upstream. BMIPS5000 and BMIPS5200 processor have no D cache aliases, and this is properly handled by the per-CPU override added at the end of r4k_cache_init(), the problem is that the output of probe_pcache() disagrees with that, since this is too late: Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes With the change moved earlier, we now have a consistent output with the settings we are intending to have: Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes. Primary data cache 32kB, 4-way, VIPT, no aliases, linesize 32 bytes Fixes: d74b0172 ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c130d2fd upstream. BMIPS5000 and BMIPS52000 processors have their I-cache filling from the D-cache. Since BMIPS_GENERIC does not provide (yet) a cpu-feature-overrides.h file, this was not set anywhere, so make sure the R4K cache detection takes care of that. Fixes: d74b0172 ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by:
-
Matt Redfearn authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a400bed6 upstream. Commit d218af78 ("MIPS: scall: Always run the seccomp syscall filters") modified the syscall code to always call the seccomp filters, but missed the case where a filter may redirect the syscall, as revealed by the seccomp_bpf self test. The syscall path now restores the syscall from the stack after the filter rather than saving it locally. Syscall number checking and syscall function table lookup is done after the filter may have run such that redirected syscalls are also checked, and executed. The regular path of syscall number checking and pointer lookup is also made more consistent between ABIs with scall64-64.S being the reference. With this patch in place, the seccomp_bpf self test now passes TRACE_syscall.syscall_redirected and TRACE_syscall.syscall_dropped on all MIPS ABIs. Fixes: d218af78 ("MIPS: scall: Always run the seccomp syscall filters") Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Eric B Munson <emunson@akamai.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: IMG-MIPSLinuxKerneldevelopers@imgtec.com Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12916/Signed-off-by:
-
Paul Burton authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6609ccdc upstream. When CONFIG_MIPS_CPS_NS16550 is enabled, some register state is dumped to the UART when an exception is taken via the BEV on secondary cores. EJTAG exceptions are architecturally expected to be handled by the BEV even when Status.BEV is 0. This effectively means that if userland executes an sdbbp instruction on a secondary core then the kernel dumps register state to the UART even though the exception is perfectly normal & expected. Prevent this by simply not dumping information to the UART for EJTAG exceptions. Fixes: 609cf6f2 ("MIPS: CPS: Early debug using an ns16550-compatible UART") Signed-off-by:
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit cbbda6e7 upstream. BMIPS5000 have a PrID value of 0x5A00 and BMIPS5200 have a PrID value of 0x5B00, which, masked with 0x5A00, returns 0x5A00. Update all conditionals on the PrID to cover both variants since we are going to need this to enable BMIPS5200 SMP. The existing check, masking with 0xFF00 would not cover BMIPS5200 at all. Fixes: 68e6a783 ("MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)") Fixes: 6465460c ("MIPS: BMIPS: change compile time checks to runtime checks") Signed-off-by:
-
James Hogan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 555fae60 upstream. The cp0_tcstatus member of struct pt_regs was removed along with the rest of SMTC in v3.16, commit b633648c ("MIPS: MT: Remove SMTC support"), however recent uprobes support in v4.3 added back a reference to it in the regoffset_table[] in ptrace.c. Remove it. Signed-off-by:
-
Jaedon Shin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2549cc96 upstream. Change the CONFIG_MIPS_CMDLINE_EXTEND to CONFIG_MIPS_CMDLINE_DTB_EXTEND to resolve the EXTEND_WITH_PROM macro. Signed-off-by:
Jaedon Shin <jaedon.shin@gmail.com> Fixes: 2024972e ("MIPS: Make the kernel arguments from dtb available") Reviewed-by:
Alexander Sverdlin <alexander.svedlin@gmail.com> Cc: Jonas Gorski <jogo@openwrt.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Aaro Koskinen <aaro.koskinen@nokia.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11909/Signed-off-by:
-
Felipe Balbi authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 23fd537c upstream. Always unmap all SG entries as required by DMA API Fixes: a698908d ("usb: gadget: add generic map/unmap request utilities") Cc: <stable@vger.kernel.org> # v3.4+ Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Iago Abal authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 1d23d16a upstream. The above commit reordered spin_lock/unlock and now `&dev->lock' is acquired (rather than released) before calling `dev->driver->disconnect', `dev->driver->setup', `dev->driver->suspend', `usb_gadget_giveback_request', and `usb_gadget_udc_reset'. But this *may* not be the right way to fix the problem pointed by d3cb25a1. Note that the other usb/gadget/udc drivers do release the lock before calling these functions. There are also inconsistencies within pch_udc.c, where `dev->driver->disconnect' is called while holding `&dev->lock' in lines 613 and 1184, but not in line 2739. Finally, commit d3cb25a1 may have introduced several potential deadlocks. For instance, EBA (https://github.com/models-team/eba) reports: Double lock in drivers/usb/gadget/udc/pch_udc.c first at 2791: spin_lock(& dev->lock); [pch_udc_isr] second at 2694: spin_lock(& dev->lock); [pch_udc_svc_cfg_interrupt] after calling from 2793: pch_udc_dev_isr(dev, dev_intr); after calling from 2724: pch_udc_svc_cfg_interrupt(dev); Similarly, other potential deadlocks are 2791 -> 2793 -> 2721 -> 2657; and 2791 -> 2793 -> 2711 -> 2573 -> 1499 -> 1480. Fixes: d3cb25a1 ("usb: gadget: udc: fix spin_lock in pch_udc") Signed-off-by:
Iago Abal <mail@iagoabal.eu> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b968737 upstream. It seems there are leftovers of some assignments which are not used anymore. Compiler even warns us about: drivers/usb/gadget/udc/pch_udc.c:2022:22: warning: variable ‘dev’ set \ but not used [-Wunused-but-set-variable] drivers/usb/gadget/udc/pch_udc.c:2639:9: warning: variable ‘ret’ set \ but not used [-Wunused-but-set-variable] Remove them and shut compiler about. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Krzysztof Opasiak authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0561f77e upstream. Correct attribute name is port_num not num. Fixes: ea6bd6b1 ("usb-gadget/f_acm: use per-attribute show and store methods") Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Ben Hutchings authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c3f46348 upstream. There's no net_device stashed in skb->cb, there's a net_device * there. To make it *really* clear, also change the write of the dev pointer into skb->cb from a memcpy() to an assignment. Fixes: 3fe56324 ("staging: rtl8192u: r8192U_core.c: Cleaning up ...") Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 85e9b88a upstream. ret should be changed to release allocated struct qxl_release Cc: stable@vger.kernel.org Fixes: 8002db63 ("qxl: convert qxl driver to proper use for reservations") Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Link: http://patchwork.freedesktop.org/patch/msgid/22cfd55f-07c8-95d0-a2f7-191b7153c3d4@virtuozzo.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 933db733 upstream. qxl_release should not be accesses after qxl_push_*_ring_release() calls: userspace driver can process submitted command quickly, move qxl_release into release_ring, generate interrupt and trigger garbage collector. It can lead to crashes in qxl driver or trigger memory corruption in some kmalloc-192 slab object Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() + qxl_push_{cursor,command}_ring_release() calls to close that race window. cc: stable@vger.kernel.org Fixes: f64122c1 ("drm: add new QXL driver. (v1.4)") Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ce0c58d9 upstream. This patch corrects some information in mwifiex_pcie_card_reg() structure for 8997 chipset Fixes: 6d85ef00 ("mwifiex: add support for 8997 chipset") Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Shengzhen Li <szli@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1878246Signed-off-by:
-
Paul Moore authored
BugLink: https://bugs.launchpad.net/bugs/1878246 commit fb739741 upstream. Fix the SELinux netlink_send hook to properly handle multiple netlink messages in a single sk_buff; each message is parsed and subject to SELinux access control. Prior to this patch, SELinux only inspected the first message in the sk_buff. Cc: stable@vger.kernel.org Reported-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
