- 08 Nov, 2016 40 commits
-
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code. Link: http://lkml.kernel.org/r/1470092390-25451-3-git-send-email-mauricfo@linux.vnet.ibm.comSigned-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: Keith Busch <keith.busch@intel.com> Cc: Jens Axboe <axboe@fb.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (back ported from commit af8a2498) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> (rtg - Use dma_get_attr()) Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com>
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Introduce the DMA_ATTR_NO_WARN attribute, and document it. Link: http://lkml.kernel.org/r/1470092390-25451-2-git-send-email-mauricfo@linux.vnet.ibm.comSigned-off-by:
-
Arend Van Spriel authored
User-space can choose to omit NL80211_ATTR_SSID and only provide raw IE TLV data. When doing so it can provide SSID IE with length exceeding the allowed size. The driver further processes this IE copying it into a local variable without checking the length. Hence stack can be corrupted and used as exploit. Cc: stable@vger.kernel.org # v4.7 Reported-by:
Daxing Guo <freener.gdx@gmail.com> Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> CVE-2016-8658 (backported from commit ded89912) [ luis: file rename: - drivers/net/wireless/{ => broadcom}/brcm80211/brcmfmac/cfg80211.c Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1620979 It turns out that for north and southwest communities, they can only generate GPIO interrupts for lower 8 interrupts (IntSel value). The upper part (8-15) can only generate GPEs (General Purpose Events). Now the reason why EC events such as pressing hotkeys does not work if we mask all the interrupts is that in order to generate either interrupts or GPEs the INTMASK register must have that particular interrupt unmasked. In case of GPEs the CPU does not trigger normal interrupt (and thus the GPIO driver does not see it) but instead it causes SCI (System Control Interrupt) to be triggered with the GPE in question set. To make this all work as expected we only add those GPIOs to the IRQ domain that can actually generate interrupts (IntSel value 0-7) and skip others. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> (cherry picked from commit 47c950d1) Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Acked-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1620979 The Cherryview GPIO controller has 8 or 16 wires connected to the I/O-APIC which can be used directly by the platform/BIOS or drivers. One such wire is used as SCI (System Control Interrupt) which ACPI depends on to be able to trigger GPEs (General Purpose Events). The pinctrl driver itself uses another IRQ resource which is wire OR of all the 8 (or 16) wires and follows what BIOS has programmed to the IntSel register of each pin. Currently the driver masks all interrupts at probe time and this prevents these direct interrupts from working as expected. The reason for this is that some early stage prototypes had some pins misconfigured causing lots of spurious interrupts. We fix this by leaving the interrupt mask untouched. This allows SCI and other direct interrupts work properly. What comes to the possible spurious interrupts we switch the default handler to be handle_bad_irq() instead of handle_simple_irq() (which was not correct anyway). Reported-by:
Yu C Chen <yu.c.chen@intel.com> Reported-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1620979 When using GPIO irqchip helpers to setup irqchip for a gpiolib based driver, it is not possible to select which GPIOs to add to the IRQ domain. Instead it just adds all GPIOs which is not always desired. For example there might be GPIOs that for some reason cannot generated normal interrupts at all. To support this we add a flag irq_need_valid_mask to struct gpio_chip. When this flag is set the core allocates irq_valid_mask that holds one bit for each GPIO the chip has. By default all bits are set but drivers can manipulate this using set_bit() and clear_bit() accordingly. Then when gpiochip_irqchip_add() is called, this mask is checked and all GPIOs with bit is set are added to the IRQ domain created for the GPIO chip. Suggested-by:
-
Gerald Schaefer authored
When interrupting an application which was allocating DMAable memory, it was possible, that the DMA memory was deallocated twice, leading to the error symptoms below. BugLink: http://bugs.launchpad.net/bugs/1559194 Thanks to Gerald, who analyzed the problem and provided this patch. I agree with his analysis of the problem: ddcb_cmd_fixups() -> genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() -> genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and f/lpage maybe also != NULL) In this scenario we would have exactly the kind of double free that would explain the WARNING / Bad page state, and as expected it is caused by broken error handling (cleanup). Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce the "Bad page state" issue, and with the patch on top he could not reproduce it any more. ------------[ cut here ]------------ WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141 Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000 Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3 Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400 0000000000000400 0000000000001fff 0000000000000400 0000000116853000 07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001 0000000000001000 0000000116854000 0000000000156402 00000000324e7a38 Krnl Code: 000000000015633a: 95001000 cli 0(%r1),0 000000000015633e: a774ffc3 brc 7,1562c4 #0000000000156342: a7f40001 brc 15,156344 >0000000000156346: 92011000 mvi 0(%r1),1 000000000015634a: a7f4ffbd brc 15,1562c4 000000000015634e: 0707 bcr 0,%r7 0000000000156350: c00400000000 brcl 0,156350 0000000000156356: eb7ff0500024 stmg %r7,%r15,80(%r15) Call Trace: ([<00000000001563e0>] dma_update_trans+0x90/0x228) [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160 [<00000000001567c2>] s390_dma_free+0x62/0x98 [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card] [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card] [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card] [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card] [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card] [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518 [<0000000000325344>] SyS_ioctl+0xa4/0xb8 [<00000000007b86c6>] system_call+0xd6/0x264 [<000003ff9e8e520a>] 0x3ff9e8e520a Last Breaking-Event-Address: [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8 ---[ end trace 35996336235145c8 ]--- BUG: Bad page state in process jbd2/dasdb1-8 pfn:3215b page:000003d100c856c0 count:-1 mapcount:0 mapping: (null) index:0x0 flags: 0x3fffc0000000000() page dumped because: nonzero _count Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Frank Haverkamp <haver@linux.vnet.ibm.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Andy Whitcroft <andy.whitcroft@canonical.com>
-
Dan Carpenter authored
We need to put an upper bound on "user_len" so the memcpy() doesn't overflow. Cc: <stable@vger.kernel.org> Reported-by:
Marco Grassi <marco.gra@gmail.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> CVE-2016-7425 (cherry picked from commit 7bc2b55a) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1634705Signed-off-by:
Colin King <colin.king@canonical.com> Acked-by:
-
Alex Hung authored
Some system supports hybrid graphics and its discrete VGA does not have any connectors and therefore has no _DOD method. BugLink: http://bugs.launchpad.net/bugs/1634607Signed-off-by:
Alex Hung <alex.hung@canonical.com> Reviewed-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit e34fbbac) Signed-off-by:
-
Ethan Hsieh authored
BugLink: http://bugs.launchpad.net/bugs/1634380 Move usb_autopm_get_interface() ahead of setup_on_usb() to prevent device from sending usb control message in usb suspend mode. The error message is as below: [ 83.944103] btusb 1-2:1.1: usb_suspend_interface: status 0 [ 83.944107] btusb 1-2:1.0: usb_suspend_interface: status 0 [ 83.960132] usb 1-2: usb auto-suspend, wakeup 0 [ 83.976156] usb 1-2: usb_suspend_device: status 0 [ 83.976162] usb 1-2: usb_suspend_both: status 0 [ 298.689106] Bluetooth: hci0 [ 298.689399] Bluetooth: hci0: Failed to access otp area (-113) Signed-off-by:
Ethan Hsieh <ethan.hsieh@canonical.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> (cherry picked from commit c7e163fe) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Wang, Rui Y authored
BugLink: http://bugs.launchpad.net/bugs/1633058 cryptd_create_hash() fails by returning -EINVAL. It is because after 8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash drivers must have a non-zero statesize. This patch fixes the problem by properly assigning the statesize. Signed-off-by:
Rui Wang <rui.y.wang@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 1a078340) Signed-off-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Wang, Rui Y authored
BugLink: http://bugs.launchpad.net/bugs/1633058 ghash_clmulni_intel fails to load on Linux 4.3+ with the following message: "modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument" After 8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash drivers are required to implement import()/export(), and must have a non- zero statesize. This patch has been tested with the algif_hash interface. The calculated digest values, after several rounds of import()s and export()s, match those calculated by tcrypt. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1634153Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 72fd50e1 upstream. The req_canceled() callback is used by tpm_transmit() periodically to check whether the request has been canceled while it is receiving a response from the TPM. The TPM_CRB_CTRL_CANCEL register was cleared already in the crb_cancel callback, which has two consequences: * Cancel might not happen. * req_canceled() always returns zero. A better place to clear the register is when starting to send a new command. The behavior of TPM_CRB_CTRL_CANCEL is described in the section 5.5.3.6 of the PTP specification. Fixes: 30fc8d13 ("tpm: TPM 2.0 CRB Interface") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit d4816edf upstream. Unseal and load operations should be done as an atomic operation. This commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted() can do the locking by itself. Fixes: 0fe54803 ("keys, trusted: seal/unseal with TPM 2.0 chips") Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Miklos Szeredi authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit e71b9dff upstream. Ima tries to call ->setxattr() on overlayfs dentry after having locked underlying inode, which results in a deadlock. Reported-by:
Krisztian Litkey <kli@iki.fi> Fixes: 4bacc9c9 ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
-
Christophe Jaillet authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit af48d7bc upstream. We know that 'ret = 0' because it has been tested a few lines above. So, if 'kzalloc' fails, 0 will be returned instead of an error code. Return -ENOMEM instead. Fixes: a0d46a3d ("ARM: cpuidle: Register per cpuidle device") Signed-off-by:
Christophe Jaillet <christophe.jaillet@wanadoo.fr> Acked-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit ca88696e upstream. The Qualcomm PMIC GPIO and MPP lines are problematic: the are fetched from the main MFD driver with platform_get_irq() which means that at this point they will all be assigned the flags set up for the interrupts in the device tree. That is problematic since these are flagged as rising edge and an this point the interrupt descriptor is assigned a rising edge, while the only thing the GPIO/MPP drivers really do is issue irq_get_irqchip_state() on the line to read it out and to provide a .to_irq() helper for *other* IRQ consumers. If another device tree node tries to flag the same IRQ for use as something else than rising edge, the kernel irqdomain core will protest like this: type mismatch, failed to map hwirq-NN for <FOO>! Which is what happens when the device tree defines two contradictory flags for the same interrupt line. To work around this and alleviate the problem, assign 0 as flag for the interrupts taken by the PM GPIO and MPP drivers. This will lead to the flag being unset, and a second consumer requesting rising, falling, both or level interrupts will be respected. This is what the qcom-pm*.dtsi files already do. Switched to using the symbolic name IRQ_TYPE_NONE so that we get this more readable. Fixes: bce36046 ("ARM: dts: apq8064: add pm8921 mpp support") Fixes: 874443fe ("ARM: dts: apq8064: Add pm8921 mfd and its gpio node") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Björn Andersson <bjorn.andersson@linaro.org> Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Andy Gross <andy.gross@linaro.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Grzegorz Jaszczyk authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 061492cf upstream. The armada-390.dtsi was broken since the first patch which adds Device Tree files for Armada 39x SoC was introduced. Signed-off-by:
Grzegorz Jaszczyk <jaz@semihalf.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes 538da83d ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board") Signed-off-by:
-
Josh Poimboeuf authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 72b4f6a5 upstream. On x86_32, when an interrupt happens from kernel space, SS and SP aren't pushed and the existing stack is used. So pt_regs is effectively two words shorter, and the previous stack pointer is normally the memory after the shortened pt_regs, aka '®s->sp'. But in the rare case where the interrupt hits right after the stack pointer has been changed to point to an empty stack, like for example when call_on_stack() is used, the address immediately after the shortened pt_regs is no longer on the stack. In that case, instead of '®s->sp', the previous stack pointer should be retrieved from the beginning of the current stack page. kernel_stack_pointer() wants to do that, but it forgets to dereference the pointer. So instead of returning a pointer to the previous stack, it returns a pointer to the beginning of the current stack. Note that it's probably outside of kernel_stack_pointer()'s scope to be switching stacks at all. The x86_64 version of this function doesn't do it, and it would be better for the caller to do it if necessary. But that's a patch for another day. This just fixes the original intent. Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Byungchul Park <byungchul.park@lge.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nilay Vaish <nilayvaish@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 0788aa6a ("x86: Prepare removal of previous_esp from i386 thread_info structure") Link: http://lkml.kernel.org/r/472453d6e9f6a2d4ab16aaed4935f43117111566.1471535549.git.jpoimboe@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit db91aa79 upstream. When a CPU is about to be offlined we call fixup_irqs() that resets IRQ affinities related to the CPU in question. The same thing is also done when the system is suspended to S-states like S3 (mem). For each IRQ we try to complete any on-going move regardless whether the IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch its chip_data, assume it is of type struct apic_chip_data and manipulate it by clearing old_domain mask etc. For irq_chips that are not part of the x86_vector_domain, like those created by various GPIO drivers, will find their chip_data being changed unexpectly. Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets corrupted after resume: # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in hi # rtcwake -s10 -mmem <10 seconds passes> # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in ? Note '?' in the output. It means the struct gpio_chip ->get function is NULL whereas before suspend it was there. Fix this by first checking that the IRQ belongs to x86_vector_domain before we try to use the chip_data as struct apic_chip_data. Reported-and-tested-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Dan Williams authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 917db484 upstream. In commit: ec776ef6 ("x86/mm: Add support for the non-standard protected e820 type") Christoph references the original patch I wrote implementing pmem support. The intent of the 'max_pfn' changes in that commit were to enable persistent memory ranges to be covered by the struct page memmap by default. However, that approach was abandoned when Christoph ported the patches [1], and that functionality has since been replaced by devm_memremap_pages(). In the meantime, this max_pfn manipulation is confusing kdump [2] that assumes that everything covered by the max_pfn is "System RAM". This results in kdump hanging or crashing. [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000348.html [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1351098 So fix it. Reported-by:
Zhang Yi <yizhan@redhat.com> Reported-by:
Jeff Moyer <jmoyer@redhat.com> Tested-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit ac0e89bb upstream. We use logical negate where bitwise negate was intended. It means that we never return -EINVAL here. Fixes: ce11e48b ('KVM: PPC: E500: Add userspace debug stub support') Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 91e4f1b6 upstream. When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate TLB entries on the local CPU. This doesn't work correctly on an SMP host when the guest is migrated to a different physical CPU, as it could pick up stale TLB mappings from the last time the vCPU ran on that physical CPU. Therefore invalidate both user and kernel host ASIDs on other CPUs, which will cause new ASIDs to be generated when it next runs on those CPUs. We're careful only to do this if the TLB entry was already valid, and only for the kernel ASID where the virtual address it mapped is outside of the guest user address range. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by:
-
Thomas Huth authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit fa73c3b2 upstream. The MMCR2 register is available twice, one time with number 785 (privileged access), and one time with number 769 (unprivileged, but it can be disabled completely). In former times, the Linux kernel was using the unprivileged register 769 only, but since commit 8dd75ccb ("powerpc: Use privileged SPR number for MMCR2"), it uses the privileged register 785 instead. The KVM-PR code then of course also switched to use the SPR 785, but this is causing older guest kernels to crash, since these kernels still access 769 instead. So to support older kernels with KVM-PR again, we have to support register 769 in KVM-PR, too. Fixes: 8dd75ccbSigned-off-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 88003fb1 upstream. This fixes a compile failure: drivers/built-in.o: In function `wm8350_i2c_probe': core.c:(.text+0x828b0): undefined reference to `__devm_regmap_init_i2c' Makefile:953: recipe for target 'vmlinux' failed Fixes: 52b461b8 ("mfd: Add regmap cache support for wm8350") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 9a6dc644 upstream. set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4. Fixes: 70c6cce0 ('mfd: Support 88pm80x in 80x driver') Signed-off-by:
-
Boris Brezillon authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 2c2469bc upstream. readl_poll_timeout() calls usleep_range(), but regmap_atmel_hlcdc_reg_write() is called in atomic context (regmap spinlock held). Replace the readl_poll_timeout() call by readl_poll_timeout_atomic(). Fixes: ea31c0cf ("mfd: atmel-hlcdc: Implement config synchronization") Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Lu Baolu authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 8dcc5ff8 upstream. Member "status" of struct usb_sg_request is managed by usb core. A spin lock is used to serialize the change of it. The driver could check the value of req->status, but should avoid changing it without the hold of the spinlock. Otherwise, it could cause race or error in usb core. This patch could be backported to stable kernels with version later than v3.14. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Roger Tseng <rogerable@realtek.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
-
Takashi Sakamoto authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 8da08ca0 upstream. Currently, usb-line6 module exports an array of MIDI manufacturer ID and usb-pod module uses it. However, the declaration is not the definition in common header. The difference is explicit length of array. Although compiler calculates it and everything goes well, it's better to use the same representation between definition and declaration. This commit fills the length of array for usb-line6 module. As a small good sub-effect, this commit suppress below warnings from static analysis by sparse v0.5.0. sound/usb/line6/driver.c:274:43: error: cannot size expression sound/usb/line6/driver.c:275:16: error: cannot size expression sound/usb/line6/driver.c:276:16: error: cannot size expression sound/usb/line6/driver.c:277:16: error: cannot size expression Fixes: 705ececd ("Staging: add line6 usb driver") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Anssi Hannula authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit eb1a74b7 upstream. The DragonFly quirk added in 42e3121d ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly") applies a custom dB map on the volume control when its range is reported as 0..50 (0 .. 0.2dB). However, there exists at least one other variant (hw v1.0c, as opposed to the tested v1.2) which reports a different non-sensical volume range (0..53) and the custom map is therefore not applied for that device. This results in all of the volume change appearing close to 100% on mixer UIs that utilize the dB TLV information. Add a fallback case where no dB TLV is reported at all if the control range is not 0..50 but still 0..N where N <= 1000 (3.9 dB). Also restrict the quirk to only apply to the volume control as there is also a mute control which would match the check otherwise. Fixes: 42e3121d ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly") Signed-off-by:
Anssi Hannula <anssi.hannula@iki.fi> Reported-by:
David W <regulars@d-dub.org.uk> Tested-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit db685779 upstream. The pointer callbacks of ali5451 driver may return the value at the boundary occasionally, and it results in the kernel warning like snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024 It seems that folding the position offset is enough for fixing the warning and no ill-effect has been seen by that. Reported-by:
Enrico Mioso <mrkiko.rs@gmail.com> Tested-by:
-
John Stultz authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 58bfea95 upstream. In commit 27727df2 ("Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code the timekeeping_get_ns() function, but I forgot to include the unit conversion from cycles to nanoseconds, breaking the function's output, which impacts users like perf. This results in bogus perf timestamps like: swapper 0 [000] 253.427536: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426573: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426687: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426800: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426905: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427022: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427127: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427239: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427346: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427463: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 255.426572: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) Instead of more reasonable expected timestamps like: swapper 0 [000] 39.953768: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.064839: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.175956: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.287103: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.398217: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.509324: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.620437: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.731546: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.842654: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.953772: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 41.064881: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) Add the proper use of timekeeping_delta_to_ns() to convert the cycle delta to nanoseconds as needed. Thanks to Brendan and Alexei for finding this quickly after the v4.8 release. Unfortunately the problematic commit has landed in some -stable trees so they'll need this fix as well. Many apologies for this mistake. I'll be looking to add a perf-clock sanity test to the kselftest timers tests soon. Fixes: 27727df2 "timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING" Reported-by:
Brendan Gregg <bgregg@netflix.com> Reported-by:
Alexei Starovoitov <alexei.starovoitov@gmail.com> Tested-and-reviewed-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1633506 Enable module build of the Firmware Test Suite EFI test driver Signed-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1633506 This driver is used by the Firmware Test Suite (FWTS) for testing the UEFI runtime interfaces readiness of the firmware. This driver exports UEFI runtime service interfaces into userspace, which allows to use and test UEFI runtime services provided by the firmware. This driver uses the efi.<service> function pointers directly instead of going through the efivar API to allow for direct testing of the UEFI runtime service interfaces provided by the firmware. Details for FWTS are available from, <https://wiki.ubuntu.com/FirmwareTestSuite> Signed-off-by:
Ivan Hu <ivan.hu@canonical.com> Cc: joeyli <jlee@suse.com> Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> (backport from upstream commit ff6301da) Signed-off-by:
-
Masaki Ota authored
Issue reproduction procedure: 1. three or more fingers put on Touchpad. 2. release fingers from Touchpad. 3. move the cursor by one finger. 4. the cursor does not move. Cause: We do not notify multi fingers state correctly to input subsystem. For example, when three fingers release from Touchpad, fingers state is 3 -> 0. It needs to notify first, second and third finger's releasing state. Fix this by not breaking out on z axis and move x,y,z input handling code to the correct place so that it's in fact per-finger. BugLink: https://bugs.launchpad.net/bugs/1633321 [jkosina@suse.cz: reword changelog] Signed-off-by:
Masaki Ota <masaki.ota@jp.alps.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> (cherry picked from commit 9a54cf46) Signed-off-by:
Ying-Chun Liu (PaulLiu) <paul.liu@canonical.com> Acked-by:
-
Craig Magina authored
BugLink: https://launchpad.net/bugs/1632739Signed-off-by:
Craig Magina <craig.magina@canonical.com> Acked-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Added path to the MDIO driver and Documentation file. Signed-off-by:
Iyappan Subramanian <isubramanian@apm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 2efccc60 yakkety) Signed-off-by:
-
Iyappan Subramanian authored
BugLink: https://launchpad.net/bugs/1632739 Added mdio node for mdio driver. Also added phy-handle reference to the ethernet nodes. Removed unused clock node from storm sgenet1. Signed-off-by:
Fushen Chen <fchen@apm.com> Tested-by:
Toan Le <toanle@apm.com> Signed-off-by:
-
