commit 3b89848d107602239a74825d1506a7a1c5556e6a Author: Jiri Slaby Date: Wed Sep 3 11:17:32 2014 +0200 Linux 3.12.28 commit 085f71743c871963d8c80129c086eb7a9d55e311 Author: Stephen M. Cameron Date: Thu Jul 3 10:18:03 2014 -0500 hpsa: fix bad -ENOMEM return value in hpsa_big_passthru_ioctl commit 0758f4f732b08b6ef07f2e5f735655cf69fea477 upstream. When copy_from_user fails, return -EFAULT, not -ENOMEM Signed-off-by: Stephen M. Cameron Reported-by: Robert Elliott Reviewed-by: Joe Handzik Reviewed-by: Scott Teel Reviewed by: Mike MIller Signed-off-by: Christoph Hellwig Signed-off-by: Jiri Slaby commit 82908a4acc2143da630162c5bebf381c6c166d45 Author: David Vrabel Date: Thu Aug 7 17:06:06 2014 +0100 x86/xen: resume timer irqs early commit 8d5999df35314607c38fbd6bdd709e25c3a4eeab upstream. If the timer irqs are resumed during device resume it is possible in certain circumstances for the resume to hang early on, before device interrupts are resumed. For an Ubuntu 14.04 PVHVM guest this would occur in ~0.5% of resume attempts. It is not entirely clear what is occuring the point of the hang but I think a task necessary for the resume calls schedule_timeout(), waiting for a timer interrupt (which never arrives). This failure may require specific tasks to be running on the other VCPUs to trigger (processes are not frozen during a suspend/resume if PREEMPT is disabled). Add IRQF_EARLY_RESUME to the timer interrupts so they are resumed in syscore_resume(). Signed-off-by: David Vrabel Reviewed-by: Boris Ostrovsky Signed-off-by: Jiri Slaby commit 465502e733e8b8f5cf09caf5427ce75d73f59276 Author: Matt Fleming Date: Fri Jul 11 08:45:25 2014 +0100 x86/efi: Enforce CONFIG_RELOCATABLE for EFI boot stub commit 7b2a583afb4ab894f78bc0f8bd136e96b6499a7e upstream. Without CONFIG_RELOCATABLE the early boot code will decompress the kernel to LOAD_PHYSICAL_ADDR. While this may have been fine in the BIOS days, that isn't going to fly with UEFI since parts of the firmware code/data may be located at LOAD_PHYSICAL_ADDR. Straying outside of the bounds of the regions we've explicitly requested from the firmware will cause all sorts of trouble. Bruno reports that his machine resets while trying to decompress the kernel image. We already go to great pains to ensure the kernel is loaded into a suitably aligned buffer, it's just that the address isn't necessarily LOAD_PHYSICAL_ADDR, because we can't guarantee that address isn't in-use by the firmware. Explicitly enforce CONFIG_RELOCATABLE for the EFI boot stub, so that we can load the kernel at any address with the correct alignment. Reported-by: Bruno Prémont Tested-by: Bruno Prémont Cc: H. Peter Anvin Signed-off-by: Matt Fleming Signed-off-by: Jiri Slaby commit de17f3c902e67f9a5363b4d7558968f6aafeea3f Author: Andy Lutomirski Date: Fri Jul 25 16:30:27 2014 -0700 x86_64/vsyscall: Fix warn_bad_vsyscall log output commit 53b884ac3745353de220d92ef792515c3ae692f0 upstream. This commit in Linux 3.6: commit c767a54ba0657e52e6edaa97cbe0b0a8bf1c1655 Author: Joe Perches Date: Mon May 21 19:50:07 2012 -0700 x86/debug: Add KERN_ to bare printks, convert printks to pr_ caused warn_bad_vsyscall to output garbage in the middle of the line. Revert the bad part of it. The printk in question isn't actually bare; the level is "%s". The bug this fixes is purely cosmetic; backports are optional. Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/03eac1f24110bbe496ecc12a4df467e0d88466d4.1406330947.git.luto@amacapital.net Signed-off-by: H. Peter Anvin Signed-off-by: Jiri Slaby commit 4804ca792a7b13ab2bc9dd2ccf2a7ae590bbe3d2 Author: Christoph Schulz Date: Wed Jul 16 10:00:57 2014 +0200 x86: don't exclude low BIOS area when allocating address space for non-PCI cards commit cbace46a9710a480cae51e4611697df5de41713e upstream. Commit 30919b0bf356 ("x86: avoid low BIOS area when allocating address space") moved the test for resource allocations that fall within the first 1MB of address space from the PCI-specific path to a generic path, such that all resource allocations will avoid this area. However, this breaks ISA cards which need to allocate a memory region within the first 1MB. An example is the i82365 PCMCIA controller and derivatives like the Ricoh RF5C296/396 which map part of the PCMCIA socket memory address space into the first 1MB of system memory address space. They do not work anymore as no usable memory region exists due to this change: Intel ISA PCIC probe: Ricoh RF5C296/396 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets host opts [0]: none host opts [1]: none ISA irqs (scanned) = 3,4,5,9,10 status change on irq 10 pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean. pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0d0000-0x0dffff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0x0e0000-0x0effff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: clean. pcmcia_socket pcmcia_socket1: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff pcmcia_socket pcmcia_socket1: cs: IO port probe 0xa00-0xaff: clean. pcmcia_socket pcmcia_socket1: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0d0000-0x0dffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x0e0000-0x0effff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x60000000-0x60ffffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0xa0000000-0xa0ffffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x0cc000-0x0effff: excluding 0xe0000-0xeffff pcmcia_socket pcmcia_socket1: cs: unable to map card memory! If filtering out the first 1MB is reverted, everything works as expected. Tested-by: Robert Resch Signed-off-by: Christoph Schulz Signed-off-by: Bjorn Helgaas Signed-off-by: Jiri Slaby commit b7be971e466034b42a972094293c90efb931a989 Author: Vidya Sagar Date: Wed Jul 16 15:33:42 2014 +0530 PCI: Configure ASPM when enabling device commit 1f6ae47ecff7f23da73417e068018b311f3b5583 upstream. We can't do ASPM configuration at enumeration-time because enabling it makes some defective hardware unresponsive, even if ASPM is disabled later (see 41cd766b0659 ("PCI: Don't enable aspm before drivers have had a chance to veto it"). Therefore, we have to do it after a driver claims the device. We previously configured ASPM in pci_set_power_state(), but that's not a very good place because it's not really related to setting the PCI device power state, and doing it there means: - We incorrectly skipped ASPM config when setting a device that's already in D0 to D0. - We unnecessarily configured ASPM when setting a device to a low-power state (the ASPM feature only applies when the device is in D0). - We unnecessarily configured ASPM when called from a .resume() method (ASPM configuration needs to be restored during resume, but pci_restore_pcie_state() should already do this). Move ASPM configuration from pci_set_power_state() to do_pci_enable_device() so we do it when a driver enables a device. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=79621 Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()") Suggested-by: Bjorn Helgaas Signed-off-by: Vidya Sagar Signed-off-by: Bjorn Helgaas Signed-off-by: Jiri Slaby commit 0d99de503fc0227467bcf18b3660b455e854a51c Author: Alex Deucher Date: Thu Aug 21 10:55:07 2014 -0400 drm/radeon: add additional SI pci ids commit 37dbeab788a8f23fd946c0be083e5484d6f929a1 upstream. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 77b2045e257494e474e03bcb0823fc4e2e522002 Author: Alex Deucher Date: Thu Aug 21 10:48:11 2014 -0400 drm/radeon: add new bonaire pci ids commit 5fc540edc8ea1297c76685f74bc82a2107fe6731 upstream. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 6eaabaa625c4571581a38c5459ef9cb0b23f7df2 Author: Alex Deucher Date: Thu Aug 21 10:41:42 2014 -0400 drm/radeon: add new KV pci id commit 6dc14baf4ced769017c7a7045019c7a19f373865 upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=82912 Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit e35b1e9f17e0567f96502f3a2a31dace727ed3da Author: Michael S. Tsirkin Date: Tue Aug 19 19:14:50 2014 +0800 kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-3601) commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream. The third parameter of kvm_iommu_put_pages is wrong, It should be 'gfn - slot->base_gfn'. By making gfn very large, malicious guest or userspace can cause kvm to go to this error path, and subsequently to pass a huge value as size. Alternatively if gfn is small, then pages would be pinned but never unpinned, causing host memory leak and local DOS. Passing a reasonable but large value could be the most dangerous case, because it would unpin a page that should have stayed pinned, and thus allow the device to DMA into arbitrary memory. However, this cannot happen because of the condition that can trigger the error: - out of memory (where you can't allocate even a single page) should not be possible for the attacker to trigger - when exceeding the iommu's address space, guest pages after gfn will also exceed the iommu's address space, and inside kvm_iommu_put_pages() the iommu_iova_to_phys() will fail. The page thus would not be unpinned at all. Reported-by: Jack Morgenstein Signed-off-by: Michael S. Tsirkin Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 1cd31e1b556e977a1bc229ed2545151bf9269ea3 Author: Paolo Bonzini Date: Mon Aug 18 16:39:48 2014 +0200 Revert "KVM: x86: Increase the number of fixed MTRR regs to 10" commit 0d234daf7e0a3290a3a20c8087eefbd6335a5bd4 upstream. This reverts commit 682367c494869008eb89ef733f196e99415ae862, which causes 32-bit SMP Windows 7 guests to panic. SeaBIOS has a limit on the number of MTRRs that it can handle, and this patch exceeded the limit. Better revert it. Thanks to Nadav Amit for debugging the cause. Reported-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 6c9866eef41246035b7bccd3a45ed4be8cedd413 Author: Paolo Bonzini Date: Wed Jul 30 18:07:24 2014 +0200 KVM: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table commit 0f6c0a740b7d3e1f3697395922d674000f83d060 upstream. Currently, the EOI exit bitmap (used for APICv) does not include interrupts that are masked. However, this can cause a bug that manifests as an interrupt storm inside the guest. Alex Williamson reported the bug and is the one who really debugged this; I only wrote the patch. :) The scenario involves a multi-function PCI device with OHCI and EHCI USB functions and an audio function, all assigned to the guest, where both USB functions use legacy INTx interrupts. As soon as the guest boots, interrupts for these devices turn into an interrupt storm in the guest; the host does not see the interrupt storm. Basically the EOI path does not work, and the guest continues to see the interrupt over and over, even after it attempts to mask it at the APIC. The bug is only visible with older kernels (RHEL6.5, based on 2.6.32 with not many changes in the area of APIC/IOAPIC handling). Alex then tried forcing bit 59 (corresponding to the USB functions' IRQ) on in the eoi_exit_bitmap and TMR, and things then work. What happens is that VFIO asserts IRQ11, then KVM recomputes the EOI exit bitmap. It does not have set bit 59 because the RTE was masked, so the IOAPIC never sees the EOI and the interrupt continues to fire in the guest. My guess was that the guest is masking the interrupt in the redirection table in the interrupt routine, i.e. while the interrupt is set in a LAPIC's ISR, The simplest fix is to ignore the masking state, we would rather have an unnecessary exit rather than a missed IRQ ACK and anyway IOAPIC interrupts are not as performance-sensitive as for example MSIs. Alex tested this patch and it fixed his bug. [Thanks to Alex for his precise description of the problem and initial debugging effort. A lot of the text above is based on emails exchanged with him.] Reported-by: Alex Williamson Tested-by: Alex Williamson Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 06508c9b0d906d158bf6023feee57e617cefac32 Author: Nadav Amit Date: Sun Jun 15 16:12:59 2014 +0300 KVM: x86: Inter-privilege level ret emulation is not implemeneted commit 9e8919ae793f4edfaa29694a70f71a515ae9942a upstream. Return unhandlable error on inter-privilege level ret instruction. This is since the current emulation does not check the privilege level correctly when loading the CS, and does not pop RSP/SS as needed. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 3501de9d423faad2a8b94606a962a90050127b19 Author: Steven Rostedt Date: Mon Jun 9 14:06:07 2014 -0400 debugfs: Fix corrupted loop in debugfs_remove_recursive commit 485d44022a152c0254dd63445fdb81c4194cbf0e upstream. [ I'm currently running my tests on it now, and so far, after a few hours it has yet to blow up. I'll run it for 24 hours which it never succeeded in the past. ] The tracing code has a way to make directories within the debugfs file system as well as deleting them using mkdir/rmdir in the instance directory. This is very limited in functionality, such as there is no renames, and the parent directory "instance" can not be modified. The tracing code creates the instance directory from the debugfs code and then replaces the dentry->d_inode->i_op with its own to allow for mkdir/rmdir to work. When these are called, the d_entry and inode locks need to be released to call the instance creation and deletion code. That code has its own accounting and locking to serialize everything to prevent multiple users from causing harm. As the parent "instance" directory can not be modified this simplifies things. I created a stress test that creates several threads that randomly creates and deletes directories thousands of times a second. The code stood up to this test and I submitted it a while ago. Recently I added a new test that adds readers to the mix. While the instance directories were being added and deleted, readers would read from these directories and even enable tracing within them. This test was able to trigger a bug: general protection fault: 0000 [#1] PREEMPT SMP Modules linked in: ... CPU: 3 PID: 17789 Comm: rmdir Tainted: G W 3.15.0-rc2-test+ #41 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000 RIP: 0010:[] [] debugfs_remove_recursive+0x1bd/0x367 RSP: 0018:ffff880077019df8 EFLAGS: 00010246 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7 FS: 00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0 Stack: ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640 0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000 00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28 Call Trace: [] ? instance_rmdir+0x15b/0x1de [] ? vfs_rmdir+0x80/0xd3 [] ? do_rmdir+0xd1/0x139 [] ? trace_hardirqs_on_thunk+0x3a/0x3c [] ? system_call_fastpath+0x16/0x1b Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08 RIP [] debugfs_remove_recursive+0x1bd/0x367 RSP It took a while, but every time it triggered, it was always in the same place: list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) { Where the child->d_u.d_child seemed to be corrupted. I added lots of trace_printk()s to see what was wrong, and sure enough, it was always the child's d_u.d_child field. I looked around to see what touches it and noticed that in __dentry_kill() which calls dentry_free(): static void dentry_free(struct dentry *dentry) { /* if dentry was never visible to RCU, immediate free is OK */ if (!(dentry->d_flags & DCACHE_RCUACCESS)) __d_free(&dentry->d_u.d_rcu); else call_rcu(&dentry->d_u.d_rcu, __d_free); } I also noticed that __dentry_kill() unlinks the child->d_u.child under the parent->d_lock spin_lock. Looking back at the loop in debugfs_remove_recursive() it never takes the parent->d_lock to do the list walk. Adding more tracing, I was able to prove this was the issue: ftrace-t-15385 1.... 246662024us : dentry_kill : free ffff88006d573600 rmdir-15409 2.... 246662024us : debugfs_remove_recursive : child=ffff88006d573600 next=dead000000100058 The dentry_kill freed ffff88006d573600 just as the remove recursive was walking it. In order to fix this, the list walk needs to be modified a bit to take the parent->d_lock. The safe version is no longer necessary, as every time we remove a child, the parent->d_lock must be released and the list walk must start over. Each time a child is removed, even though it may still be on the list, it should be skipped by the first check in the loop: if (!debugfs_positive(child)) continue; Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit 9cf85b64836c89aea19de2c65954388d180bd56a Author: Arnd Bergmann Date: Thu Jun 26 13:43:02 2014 +0200 crypto: ux500 - make interrupt mode plausible commit e1f8859ee265fc89bd21b4dca79e8e983a044892 upstream. The interrupt handler in the ux500 crypto driver has an obviously incorrect way to access the data buffer, which for a while has caused this build warning: ../ux500/cryp/cryp_core.c: In function 'cryp_interrupt_handler': ../ux500/cryp/cryp_core.c:234:5: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast [enabled by default] writel_relaxed(ctx->indata, ^ In file included from ../include/linux/swab.h:4:0, from ../include/uapi/linux/byteorder/big_endian.h:12, from ../include/linux/byteorder/big_endian.h:4, from ../arch/arm/include/uapi/asm/byteorder.h:19, from ../include/asm-generic/bitops/le.h:5, from ../arch/arm/include/asm/bitops.h:340, from ../include/linux/bitops.h:33, from ../include/linux/kernel.h:10, from ../include/linux/clk.h:16, from ../drivers/crypto/ux500/cryp/cryp_core.c:12: ../include/uapi/linux/swab.h:57:119: note: expected '__u32' but argument is of type 'const u8 *' static inline __attribute_const__ __u32 __fswab32(__u32 val) There are at least two, possibly three problems here: a) when writing into the FIFO, we copy the pointer rather than the actual data we want to give to the hardware b) the data pointer is an array of 8-bit values, while the FIFO is 32-bit wide, so both the read and write access fail to do a proper type conversion c) This seems incorrect for big-endian kernels, on which we need to byte-swap any register access, but not normally FIFO accesses, at least the DMA case doesn't do it either. This converts the bogus loop to use the same readsl/writesl pair that we use for the two other modes (DMA and polling). This is more efficient and consistent, and probably correct for endianess. The bug has existed since the driver was first merged, and was probably never detected because nobody tried to use interrupt mode. It might make sense to backport this fix to stable kernels, depending on how the crypto maintainers feel about that. Signed-off-by: Arnd Bergmann Cc: linux-crypto@vger.kernel.org Cc: Fabio Baltieri Cc: Linus Walleij Cc: Herbert Xu Cc: "David S. Miller" Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby commit c2a167948273d25a531024d67a86b55c4e38d487 Author: Peter Hurley Date: Wed Jul 9 09:21:14 2014 -0400 serial: core: Preserve termios c_cflag for console resume commit ae84db9661cafc63d179e1d985a2c5b841ff0ac4 upstream. When a tty is opened for the serial console, the termios c_cflag settings are inherited from the console line settings. However, if the tty is subsequently closed, the termios settings are lost. This results in a garbled console if the console is later suspended and resumed. Preserve the termios c_cflag for the serial console when the tty is shutdown; this reflects the most recent line settings. Fixes: Bugzilla #69751, 'serial console does not wake from S3' Reported-by: Valerio Vanni Acked-by: Alan Cox Signed-off-by: Peter Hurley Signed-off-by: Jiri Slaby commit 7b641785cfa68f6668aad6bc036450827916ec46 Author: Theodore Ts'o Date: Wed Jul 30 22:17:17 2014 -0400 ext4: fix ext4_discard_allocated_blocks() if we can't allocate the pa struct commit 86f0afd463215fc3e58020493482faa4ac3a4d69 upstream. If there is a failure while allocating the preallocation structure, a number of blocks can end up getting marked in the in-memory buddy bitmap, and then not getting released. This can result in the following corruption getting reported by the kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 1126, 12793 clusters in bitmap, 12729 in gd In that case, we need to release the blocks using mb_free_blocks(). Tested: fs smoke test; also demonstrated that with injected errors, the file system is no longer getting corrupted Google-Bug-Id: 16657874 Signed-off-by: "Theodore Ts'o" Signed-off-by: Jiri Slaby commit bbe7db75199a90395de72f55f3086d8df6982378 Author: Wolfram Sang Date: Mon Jul 21 11:42:03 2014 +0200 drivers/i2c/busses: use correct type for dma_map/unmap commit 28772ac8711e4d7268c06e765887dd8cb6924f98 upstream. dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'. Signed-off-by: Wolfram Sang Acked-by: Ludovic Desroches Signed-off-by: Jiri Slaby commit f735c9db755564483480fe43a420ad7a252d2317 Author: Jason Gunthorpe Date: Sat Nov 9 11:17:00 2013 -0700 tpm: Add missing tpm_do_selftest to ST33 I2C driver commit f07a5e9a331045e976a3d317ba43d14859d9407c upstream. Most device drivers do call 'tpm_do_selftest' which executes a TPM_ContinueSelfTest. tpm_i2c_stm_st33 is just pointlessly different, I think it is bug. These days we have the general assumption that the TPM is usable by the kernel immediately after the driver is finished, so we can no longer defer the mandatory self test to userspace. Reported-by: Richard Marciel Signed-off-by: Jason Gunthorpe Signed-off-by: Peter Huewe Signed-off-by: Jiri Slaby commit f5962d663d3db76705e52b463a3b175efe2a75d6 Author: Axel Lin Date: Wed Aug 6 08:02:44 2014 +0800 hwmon: (dme1737) Prevent overflow problem when writing large limits commit d58e47d787c09fe5c61af3c6ce7d784762f29c3d upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Voltage limits, fan minimum speed, pwm frequency, pwm ramp rate, and other attributes have the same problem, fix them as well. Zone temperature limits are signed, but were cached as u8, causing unepected values to be reported for negative temperatures. Cache as s8 to fix the problem. vrm is an u8, so the written value needs to be limited to [0, 255]. Signed-off-by: Axel Lin [Guenter Roeck: Fix zone temperature cache] Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 64e6fad527f5b9f345f5c4029fc5233855c8440b Author: Axel Lin Date: Tue Aug 5 09:59:49 2014 +0800 hwmon: (ads1015) Fix out-of-bounds array access commit e981429557cbe10c780fab1c1a237cb832757652 upstream. Current code uses data_rate as array index in ads1015_read_adc() and uses pga as array index in ads1015_reg_to_mv, so we must make sure both data_rate and pga settings are in valid value range. Return -EINVAL if the setting is out-of-range. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit cd072b3e9ba4497380c5e6d27b7f16f7d78a9c7c Author: Guenter Roeck Date: Tue Jul 29 22:23:12 2014 -0700 hwmon: (lm85) Fix various errors on attribute writes commit 3248c3b771ddd9d31695da17ba350eb6e1b80a53 upstream. Temperature limit register writes did not account for negative numbers. As a result, writing -127000 resulted in -126000 written into the temperature limit register. This problem affected temp[1-3]_min, temp[1-3]_max, temp[1-3]_auto_temp_crit, and temp[1-3]_auto_temp_min. When writing pwm[1-3]_freq, a long variable was auto-converted into an int without range check. Wiring values larger than MAXINT resulted in unexpected register values. When writing temp[1-3]_auto_temp_max, an unsigned long variable was auto-converted into an int without range check. Writing values larger than MAXINT resulted in unexpected register values. vrm is an u8, so the written value needs to be limited to [0, 255]. Cc: Axel Lin Reviewed-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 497bba1cc4a309d7fd44defaedfdbc1de8a471a2 Author: Axel Lin Date: Wed Jul 30 11:13:52 2014 +0800 hwmon: (ads1015) Fix off-by-one for valid channel index checking commit 56de1377ad92f72ee4e5cb0faf7a9b6048fdf0bf upstream. Current code uses channel as array index, so the valid channel value is 0 .. ADS1015_CHANNELS - 1. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit b800e2f89990e68cba2ce8f6fe07b9c39af8f2f1 Author: Axel Lin Date: Sat Aug 2 13:36:38 2014 +0800 hwmon: (gpio-fan) Prevent overflow problem when writing large limits commit 2565fb05d1e9fc0831f7b1c083bcfcb1cba1f020 upstream. On platforms with sizeof(int) < sizeof(unsigned long), writing a rpm value larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from unsigned long to int to fix the problem. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 80dc972c163e1638012e5b8f6adac0745cc53678 Author: Guenter Roeck Date: Tue Jul 29 20:48:59 2014 -0700 hwmon: (lm78) Fix overflow problems seen when writing large temperature limits commit 1074d683a51f1aded3562add9ef313e75d557327 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Cc: Axel Lin Reviewed-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 801d26bb1bbb5e90a07df19cc0f4900573f7cd3d Author: Axel Lin Date: Thu Jul 31 09:43:19 2014 +0800 hwmon: (amc6821) Fix possible race condition bug commit cf44819c98db11163f58f08b822d626c7a8f5188 upstream. Ensure mutex lock protects the read-modify-write period to prevent possible race condition bug. In additional, update data->valid should also be protected by the mutex lock. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit a59185ae2b87fa290f9ee11bc234022f23820833 Author: Axel Lin Date: Thu Jul 31 22:27:04 2014 +0800 hwmon: (sis5595) Prevent overflow problem when writing large limits commit cc336546ddca8c22de83720632431c16a5f9fe9a upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 568cf27ec77cacee9b88fcff260ce67ede12df62 Author: Russell King Date: Sat Jul 12 10:53:41 2014 +0100 drm: omapdrm: fix compiler errors commit 2d31ca3ad7d5d44c8adc7f253c96ce33f3a2e931 upstream. Regular randconfig nightly testing has detected problems with omapdrm. omapdrm fails to build when the kernel is built to support 64-bit DMA addresses and/or 64-bit physical addresses due to an assumption about the width of these types. Use %pad to print DMA addresses, rather than %x or %Zx (which is even more wrong than %x). Avoid passing a uint32_t pointer into a function which expects dma_addr_t pointer. drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply': drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Werror=format] make[5]: *** [drivers/gpu/drm/omapdrm/omap_plane.o] Error 1 drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_get_paddr': drivers/gpu/drm/omapdrm/omap_gem.c:794:4: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_describe': drivers/gpu/drm/omapdrm/omap_gem.c:991:4: error: format '%Zx' expects argument of type 'size_t', but argument 7 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_init': drivers/gpu/drm/omapdrm/omap_gem.c:1470:4: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Werror=format] make[5]: *** [drivers/gpu/drm/omapdrm/omap_gem.o] Error 1 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append': drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of 'alloc_dma' from incompatible pointer type [-Werror] make[5]: *** [drivers/gpu/drm/omapdrm/omap_dmm_tiler.o] Error 1 make[5]: Target `__build' not remade because of errors. make[4]: *** [drivers/gpu/drm/omapdrm] Error 2 Signed-off-by: Russell King Signed-off-by: Dave Airlie Signed-off-by: Jiri Slaby commit c24a47e83fb8ff3d108e63b5c1997be9cc58ae99 Author: Jeremy Vial Date: Thu Jul 31 15:10:33 2014 +0200 ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX rev3.1.2 case. commit 9b5f7428f8b16bd8980213f2b70baf1dd0b9e36c upstream. According to the comment “restore_es3: applies to 34xx >= ES3.0" in "arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used if the revision of an OMAP34xx is ES3.1.2. Signed-off-by: Jeremy Vial Signed-off-by: Tony Lindgren Signed-off-by: Jiri Slaby commit 9e46dda13a8b240725143a9c42de7088abfc775f Author: Alexander Usyskin Date: Thu Jul 17 10:53:35 2014 +0300 mei: start disconnect request timer consistently commit 22b987a325701223f9a37db700c6eb20b9924c6f upstream. Link must be reset in case the fw doesn't respond to client disconnect request. We did charge the timer only in irq path from mei_cl_irq_close and not in mei_cl_disconnect Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Jiri Slaby commit ac9bb39df0806acc6f62e8099184a233a4757d3a Author: Takashi Iwai Date: Fri Aug 15 17:35:00 2014 +0200 ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 & co commit f3ee07d8b6e061bf34a7167c3f564e8da4360a99 upstream. ALC269 & co have many vendor-specific setups with COEF verbs. However, some verbs seem specific to some codec versions and they result in the codec stalling. Typically, such a case can be avoided by checking the return value from reading a COEF. If the return value is -1, it implies that the COEF is invalid, thus it shouldn't be written. This patch adds the invalid COEF checks in appropriate places accessing ALC269 and its variants. The patch actually fixes the resume problem on Acer AO725 laptop. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181 Tested-by: Francesco Muzio Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit de2a8e4ab77592a1012455e8849cb2cf2330fb6b Author: Hui Wang Date: Tue Aug 19 12:07:03 2014 +0800 ALSA: hda - restore the gpio led after resume commit f475371aa65de84fa483a998ab7594531026b9d9 upstream. On some HP laptops, the mute led is controlled by codec gpio. When some machine resume from s3/s4, the codec gpio data will be cleared to 0 by BIOS: Before suspend: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 After resume: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 To skip the AFG node to enter D3 can't fix this problem. A workaround is to restore the gpio data when the system resume back from s3/s4. It is safe even on the machines without this problem. BugLink: https://bugs.launchpad.net/bugs/1358116 Tested-by: Franz Hsieh Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit d5c6f748ee38014886168c85814b142bba5f605f Author: Clemens Ladisch Date: Sat Aug 9 17:19:41 2014 +0200 ALSA: usb-audio: fix BOSS ME-25 MIDI regression commit 53da5ebfef66ea6e478ad9c6add3781472b79475 upstream. The BOSS ME-25 turns out not to have any useful descriptors in its MIDI interface, so its needs a quirk entry after all. Reported-and-tested-by: Kees van Veen Fixes: 8e5ced83dd1c ("ALSA: usb-audio: remove superfluous Roland quirks") Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 921ff19a5af1c64dc021982b4c1db017eb194523 Author: Takashi Iwai Date: Sun Aug 10 13:30:08 2014 +0200 ALSA: hda/ca0132 - Don't try loading firmware at resume when already failed commit e24aa0a4c5ac92a171d9dd74a8d3dbf652990d36 upstream. CA0132 driver tries to reload the firmware at resume. Usually this works since the firmware loader core caches the firmware contents by itself. However, if the driver failed to load the firmwares (e.g. missing files), reloading the firmware at resume goes through the actual file loading code path, and triggers a kernel WARNING like: WARNING: CPU: 10 PID:11371 at drivers/base/firmware_class.c:1105 _request_firmware+0x9ab/0x9d0() For avoiding this situation, this patch makes CA0132 skipping the f/w loading at resume when it failed at probe time. Reported-and-tested-by: Janek Kozicki Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b5f979ef90afe42cdebf64c8c69ac3fdc8da18d8 Author: Clemens Ladisch Date: Mon Aug 4 15:17:55 2014 +0200 ALSA: virtuoso: add Xonar Essence STX II support commit f42bb22243d2ae264d721b055f836059fe35321f upstream. Just add the PCI ID for the STX II. It appears to work the same as the STX, except for the addition of the not-yet-supported daughterboard. Tested-by: Mario Tested-by: corubba Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 21a8990039d80fd84efcb64e8e1df63a82089b72 Author: Hui Wang Date: Wed Jul 30 11:11:48 2014 +0800 ALSA: hda - fix an external mic jack problem on a HP machine commit 7440850c20b69658f322119d20a94dc914127cc7 upstream. ON the machine, two pin complex (0xb and 0xe) are both routed to the same external right-side mic jack, this makes the jack can't work. To fix this problem, set the 0xe to "not connected". BugLink: https://bugs.launchpad.net/bugs/1350148 Tested-by: Franz Hsieh Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 438430f7025f4a08ad3836970b0c5bf6c7bd68ae Author: Pratyush Anand Date: Fri Jul 18 12:37:10 2014 +0530 USB: Fix persist resume of some SS USB devices commit a40178b2fa6ad87670fb1e5fa4024db00c149629 upstream. Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Signed-off-by: Pratyush Anand Acked-by: Alan Stern Signed-off-by: Jiri Slaby commit 7d8de293bdafe301e84025fe84aed350afbb1241 Author: Bryan O'Donoghue Date: Wed Jul 2 01:58:18 2014 -0700 USB: ehci-pci: USB host controller support for Intel Quark X1000 commit 6e693739e9b603b3ca9ce0d4f4178f0633458465 upstream. The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000 USB host controller, and the default value is 0x20 dwords. The in/out threshold can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance, but only when isochronous/interrupt transactions are not initiated by the USB host controller. This patch is to reconfigure the packet buffer in/out threshold as maximal as possible to maximize the performance, and 0x7F dwords (508 Bytes) should be used because the USB host controller initiates isochronous/interrupt transactions. Signed-off-by: Bryan O'Donoghue Signed-off-by: Alvin (Weike) Chen Acked-by: Alan Stern Reviewed-by: Jingoo Han Signed-off-by: Jiri Slaby commit 5dbc2ae5f9d5d112a73f414281e05f2382ce644f Author: Patrick Riphagen Date: Thu Jul 24 09:09:50 2014 +0200 USB: serial: ftdi_sio: Add support for new Xsens devices commit 4bdcde358b4bda74e356841d351945ca3f2245dd upstream. This adds support for new Xsens devices, using Xsens' own Vendor ID. Signed-off-by: Patrick Riphagen Signed-off-by: Frans Klaver Cc: Johan Hovold Signed-off-by: Jiri Slaby commit 04bd57fa10413f327c865b8bc88b19f8a54240aa Author: Patrick Riphagen Date: Thu Jul 24 09:12:52 2014 +0200 USB: serial: ftdi_sio: Annotate the current Xsens PID assignments commit 9273b8a270878906540349422ab24558b9d65716 upstream. The converters are used in specific products. It can be useful to know which they are exactly. Signed-off-by: Patrick Riphagen Signed-off-by: Frans Klaver Cc: Johan Hovold Signed-off-by: Jiri Slaby commit 2ecbdb1518adcfe4885627f78215ef2783cd5ac1 Author: Oliver Neukum Date: Fri Aug 1 09:55:20 2014 +0200 USB: devio: fix issue with log flooding commit d310d05f1225d1f6f2bf505255fdf593bfbb3051 upstream. usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085 Signed-off-by: Oliver Neukum Acked-by: Alan Stern Signed-off-by: Jiri Slaby commit bdd2e3436f70f8665a95da66768408e1a33f8aa2 Author: Alan Stern Date: Thu Jul 17 16:34:29 2014 -0400 USB: OHCI: don't lose track of EDs when a controller dies commit 977dcfdc60311e7aa571cabf6f39c36dde13339e upstream. This patch fixes a bug in ohci-hcd. When an URB is unlinked, the corresponding Endpoint Descriptor is added to the ed_rm_list and taken off the hardware schedule. Once the ED is no longer visible to the hardware, finish_unlinks() handles the URBs that were unlinked or have completed. If any URBs remain attached to the ED, the ED is added back to the hardware schedule -- but only if the controller is running. This fails when a controller dies. A non-empty ED does not get added back to the hardware schedule and does not remain on the ed_rm_list; ohci-hcd loses track of it. The remaining URBs cannot be unlinked, which causes the USB stack to hang. The patch changes finish_unlinks() so that non-empty EDs remain on the ed_rm_list if the controller isn't running. This requires moving some of the existing code around, to avoid modifying the ED's hardware fields more than once. Signed-off-by: Alan Stern Signed-off-by: Jiri Slaby commit 6a04d05acfb51355443d2c895b4591d7f5cfd751 Author: Alan Stern Date: Thu Jul 17 16:32:26 2014 -0400 USB: OHCI: fix bugs in debug routines commit 256dbcd80f1ccf8abf421c1d72ba79a4e29941dd upstream. The debug routine fill_async_buffer() in ohci-hcd is buggy: It never produces any output because it forgets to initialize the output buffer size. Also, the debug routine ohci_dump() has an unused argument. This patch adds the correct initialization and removes the unused argument. Signed-off-by: Alan Stern Signed-off-by: Jiri Slaby commit e4ca8b780c82c04ec03fcd05d9e3f92fc6de6347 Author: Jan Kara Date: Sun Aug 17 11:49:57 2014 +0200 isofs: Fix unbounded recursion when processing relocated directories commit 410dd3cf4c9b36f27ed4542ee18b1af5e68645a4 upstream. We did not check relocated directory in any way when processing Rock Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL entry pointing to another CL entry leading to possibly unbounded recursion in kernel code and thus stack overflow or deadlocks (if there is a loop created from CL entries). Fix the problem by not allowing CL entry to point to a directory entry with CL entry (such use makes no good sense anyway) and by checking whether CL entry doesn't point to itself. Reported-by: Chris Evans Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby commit 1f78f21b43f2c69f2ea06ed35b77759d000dd2b4 Author: Jiri Kosina Date: Thu Aug 21 09:57:48 2014 -0500 HID: fix a couple of off-by-ones commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream. There are a few very theoretical off-by-one bugs in report descriptor size checking when performing a pre-parsing fixup. Fix those. Reported-by: Ben Hawkes Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit 2ae8a66674a4cd7f2cfee757ee29cb63dce755fe Author: Jiri Kosina Date: Thu Aug 21 09:57:17 2014 -0500 HID: logitech: perform bounds checking on device_id early enough commit ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 upstream. device_index is a char type and the size of paired_dj_deivces is 7 elements, therefore proper bounds checking has to be applied to device_index before it is used. We are currently performing the bounds checking in logi_dj_recv_add_djhid_device(), which is too late, as malicious device could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the problem in one of the report forwarding functions called from logi_dj_raw_event(). Fix this by performing the check at the earliest possible ocasion in logi_dj_raw_event(). Reported-by: Ben Hawkes Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit 5d1ab637d00b258f7852c963771ed4f1fd0b2de3 Author: Bjorn Helgaas Date: Wed Nov 6 10:11:48 2013 -0700 PCI: Add pci_upstream_bridge() commit c6bde215acfd637708142ae671843b6f0eadbc6d upstream. This adds a pci_upstream_bridge() interface to find the PCI-to-PCI bridge upstream from a device. This is typically just "dev->bus->self", but in the case of a VF on a virtual bus, we have to start from the corresponding PF. Returns NULL if there is no upstream PCI bridge, i.e., if the device is on a root bus. Signed-off-by: Bjorn Helgaas Acked-by: Yinghai Lu Signed-off-by: Jiri Slaby commit c27a4fe151abf351665639eef0ee2fef7e6fb4f9 Author: Gu Zheng Date: Tue Jul 1 10:36:47 2014 -0600 bio-integrity: add "bip_max_vcnt" into struct bio_integrity_payload commit cbcd1054a1fd2aa980fc11ff28e436fc4aaa2d54 upstream. Commit 08778795 ("block: Fix nr_vecs for inline integrity vectors") from Martin introduces the function bip_integrity_vecs(get the useful vectors) to fix the issue about nr_vecs for inline integrity vectors that reported by David Milburn. But it seems that bip_integrity_vecs() will return the wrong number if the bio is not based on any bio_set for some reason(bio->bi_pool == NULL), because in that case, the bip_inline_vecs[0] is malloced directly. So here we add the bip_max_vcnt to record the count of vector slots, and cleanup the function bip_integrity_vecs(). Signed-off-by: Gu Zheng Cc: Martin K. Petersen Cc: Kent Overstreet Signed-off-by: Jens Axboe commit ab73940ae61dd855de2965f0d728b803e9ff0546 Author: Lee, Chun-Yi Date: Mon Aug 4 23:23:21 2014 +0800 PM / hibernate: avoid unsafe pages in e820 reserved regions commit 84c91b7ae07c62cf6dee7fde3277f4be21331f85 upstream. When the machine doesn't well handle the e820 persistent when hibernate resuming, then it may cause page fault when writing image to snapshot buffer: [ 17.929495] BUG: unable to handle kernel paging request at ffff880069d4f000 [ 17.933469] IP: [] load_image_lzo+0x810/0xe40 [ 17.933469] PGD 2194067 PUD 77ffff067 PMD 2197067 PTE 0 [ 17.933469] Oops: 0002 [#1] SMP ... The ffff880069d4f000 page is in e820 reserved region of resume boot kernel: [ 0.000000] BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved ... [ 0.000000] PM: Registered nosave memory: [mem 0x69d4f000-0x69e12fff] So snapshot.c mark the pfn to forbidden pages map. But, this page is also in the memory bitmap in snapshot image because it's an original page used by image kernel, so it will also mark as an unsafe(free) page in prepare_image(). That means the page in e820 when resuming mark as "forbidden" and "free", it causes get_buffer() treat it as an allocated unsafe page. Then snapshot_write_next() return this page to load_image, load_image writing content to this address, but this page didn't really allocated . So, we got page fault. Although the root cause is from BIOS, I think aggressive check and significant message in kernel will better then a page fault for issue tracking, especially when serial console unavailable. This patch adds code in mark_unsafe_pages() for check does free pages in nosave region. If so, then it print message and return fault to stop whole S4 resume process: [ 8.166004] PM: Image loading progress: 0% [ 8.658717] PM: 0x6796c000 in e820 nosave region: [mem 0x6796c000-0x6796cfff] [ 8.918737] PM: Read 2511940 kbytes in 1.04 seconds (2415.32 MB/s) [ 8.926633] PM: Error -14 resuming [ 8.933534] PM: Failed to load hibernation image, recovering. Reviewed-by: Takashi Iwai Acked-by: Pavel Machek Signed-off-by: Lee, Chun-Yi [rjw: Subject] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 0325fb03fe49b37dfb9a66be6083ce4aebe17df9 Author: Wangzhao Cai Date: Mon Jul 14 09:13:32 2014 +0800 HID: add quirk for 0x04d9:0xa096 device commit 30c6fd4277ebab2a32ae5635d34283354b1bc8f2 upstream. I am using a USB keyborad that give me "usb_submit_urb(ctrl) failed: -1" error when I plugin it. and I need to wait for 10s for this device to be ready. By adding this quirks, the usb keyborad is usable right after plugin Signed-off-by: Wangzhao Cai Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit e5063845457f8a8c7fdb49bb9338a3af1a362714 Author: Jiang Liu Date: Mon Jul 21 10:17:44 2014 +0800 USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down commit c5946f9d286ad368329c79107fdf4d825d2091bd upstream. The assigned IRQ should be freed before calling pci_disable_device() when shutting down system, otherwise it will cause following warning. [ 568.879482] ------------[ cut here ]------------ [ 568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170() [ 568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4' [ 568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq [ 568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G W 3.16.0-rc5upstream-01651-g03b9189 #1 [ 568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015 04/01/2010 [ 568.956008] 00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c [ 568.964068] 00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d [ 568.972128] ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5 [ 568.980194] Call Trace: [ 568.982715] [] dump_stack+0x48/0x60 [ 568.987294] [] warn_slowpath_common+0x7f/0xa0 [ 569.003887] [] warn_slowpath_fmt+0x2e/0x30 [ 569.009092] [] remove_proc_entry+0x165/0x170 [ 569.014476] [] unregister_irq_proc+0xaa/0xc0 [ 569.019858] [] free_desc+0x1f/0x60 [ 569.024346] [] irq_free_descs+0x3a/0x80 [ 569.029283] [] irq_dispose_mapping+0x2d/0x50 [ 569.034666] [] mp_unmap_irq+0x73/0xa0 [ 569.039423] [] acpi_unregister_gsi_ioapic+0x2b/0x40 [ 569.045431] [] acpi_unregister_gsi+0xf/0x20 [ 569.050725] [] acpi_pci_irq_disable+0x4b/0x50 [ 569.056196] [] pcibios_disable_device+0x18/0x20 [ 569.061848] [] do_pci_disable_device+0x4d/0x60 [ 569.067410] [] pci_disable_device+0x47/0xb0 [ 569.077814] [] usb_hcd_pci_shutdown+0x31/0x40 [ 569.083285] [] pci_device_shutdown+0x19/0x50 [ 569.088667] [] device_shutdown+0x14/0x120 [ 569.093777] [] kernel_restart_prepare+0x2d/0x30 [ 569.099429] [] kernel_restart+0xe/0x60 [ 569.109028] [] SYSC_reboot+0x191/0x220 [ 569.159269] [] SyS_reboot+0x1a/0x20 [ 569.163843] [] sysenter_do_call+0x12/0x16 [ 569.168951] ---[ end trace ccc1ec4471c289c9 ]--- Tested-by: Aaron Lu Signed-off-by: Jiang Liu Reviewed-by: Huang Rui Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit c877de31fe78ee82855a2c1049c7b755128f481c Author: James P Michels III Date: Sun Jul 27 13:28:04 2014 -0400 usb-core bInterval quirk commit cd83ce9e6195aa3ea15ab4db92892802c20df5d0 upstream. This patch adds a usb quirk to support devices with interupt endpoints and bInterval values expressed as microframes. The quirk causes the parse endpoint function to modify the reported bInterval to a standards conforming value. There is currently code in the endpoint parser that checks for bIntervals that are outside of the valid range (1-16 for USB 2+ high speed and super speed interupt endpoints). In this case, the code assumes the bInterval is being reported in 1ms frames. As well, the correction is only applied if the original bInterval value is out of the 1-16 range. With this quirk applied to the device, the bInterval will be accurately adjusted from microframes to an exponent. Signed-off-by: James P Michels III Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 0003ed46b16d2dd12b5f95d6dd6d2b3b1d43166d Author: Joonyoung Shim Date: Thu Jul 10 14:22:35 2014 +0900 USB: add reset resume quirk for usb3503 commit 526a4045c60fbaede88ec95a69a73059dff02160 upstream. The usb device will autoresume from choose_wakeup() if it is autosuspended with the wrong wakeup setting, but below errors occur because usb3503 misc driver will switch to standby mode when suspended. As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from autosuspend_check(). [ 7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 7.854658] usb 1-3: device descriptor read/64, error -71 [ 8.079657] usb 1-3: device descriptor read/64, error -71 [ 8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 8.414658] usb 1-3: device descriptor read/64, error -71 [ 8.639657] usb 1-3: device descriptor read/64, error -71 [ 8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 9.264598] usb 1-3: device not accepting address 3, error -71 [ 9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 9.784601] usb 1-3: device not accepting address 3, error -71 [ 9.784838] usb usb1-port3: device 1-3 not suspended yet Signed-off-by: Joonyoung Shim Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 664dc48e6aaa67b14a4742d1bf77bde15b1603e6 Author: Preston Fick Date: Wed Jul 16 14:31:30 2014 -0500 USB: serial: cp210x: Removing unncessary `usb_reset_device` on startup commit 934ef5aca9daea10507eebcbd0fb8f6d57d55359 upstream. This `usb_reset_device` command has been around since the driver was originally reverse engineered. It doesn't cause much issue on single interface CP210x devices, but on the CP2105 and CP2108 with 2 and 4 interfaces respectively it will cause instability on enumeration and delays enumeration noticably. There should be no reason to reset a device at startup, per the CP210x AN571 spec. Signed-off-by: Preston Fick Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit bd78518ba277b4f768941f80c5e7b6f0c3c8ccf5 Author: Daniel Mack Date: Fri Jun 20 00:20:44 2014 +0200 usb: musb: cppi41: fire hrtimer according to programmed channel length commit 50aea6fca771d6daf3ec24f771da866f7fd836e4 upstream. The musb/cppi41 code installs a hrtimer to work around DMA completion interrupts that have fired too early on AM335x hardware. This timer is currently programmed to first fire 140 microseconds after the DMA completion callback. According to the commit which introduced it (a655f481d83, "usb: musb: musb_cppi41: handle pre-mature TX complete interrupt"), that value is is considered a 'rule of thumb' that worked well with the test case described in the commit log. Test show, however, that for USB audio devices and much smaller packet sizes, the timer has to fire earlier in order to correctly handle the audio stream. The original test case had output transfer sizes of 1514 bytes, and a delay of 140 microseconds. For audio devices with 24 bytes channel size, 3 microseconds seem to work well. Hence, let's assume that the time it takes to clear the bit correlates with the number of bytes transferred. The referenced commit log mentions such a suspicion as well. Let the timer fire in cppi41_channel->total_len/10 microseconds to correctly handle both cases. Also, shorten the interval in which the timer fires again in case of a non-empty early_tx list. With these changes in place, both FS and HS audio devices appear to work well on AM335x hardware. Signed-off-by: Daniel Mack Reported-by: Sebastian Reimers Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit b4839e6cd4a236a81725e422b2e05c26fe36048a Author: Kent Overstreet Date: Mon Aug 5 14:04:06 2013 -0700 bcache: Minor journal fix commit b3fa7e77e67e647db3db2166b65083a427d84ed3 upstream. The real fix is where we check the bytes we need against how much is remaining - we also need to check for a journal entry bigger than our buffer, we'll never write those and it would be bad if we tried to read one. Also improve the diagnostic messages. Signed-off-by: Kent Overstreet Signed-off-by: Jiri Slaby