- 03 Sep, 2014 40 commits
-
-
Alex Deucher authored
commit 5fc540ed upstream. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Alex Deucher authored
commit 6dc14baf upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=82912Signed-off-by:
-
Michael S. Tsirkin authored
commit 350b8bdd 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 <jackm@mellanox.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Paolo Bonzini authored
commit 0d234daf upstream. This reverts commit 682367c4, 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 <wanpeng.li@linux.intel.com> Signed-off-by:
-
Paolo Bonzini authored
commit 0f6c0a74 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 <alex.williamson@redhat.com> Tested-by:
-
Nadav Amit authored
commit 9e8919ae 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 <namit@cs.technion.ac.il> Signed-off-by:
-
Steven Rostedt authored
commit 485d4402 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:[<ffffffff811ed5eb>] [<ffffffff811ed5eb>] 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: [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3 [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139 [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c [<ffffffff814fea62>] ? 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 [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367 RSP <ffff880077019df8> 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 <ffffffff81138b91>: free ffff88006d573600 rmdir-15409 2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: 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 <rostedt@goodmis.org> Signed-off-by:
-
Arnd Bergmann authored
commit e1f8859e 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 <arnd@arndb.de> Cc: linux-crypto@vger.kernel.org Cc: Fabio Baltieri <fabio.baltieri@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Peter Hurley authored
commit ae84db96 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 <valerio.vanni@inwind.it> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Theodore Ts'o authored
commit 86f0afd4 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" <tytso@mit.edu> Signed-off-by:
-
Wolfram Sang authored
commit 28772ac8 upstream. dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Jason Gunthorpe authored
commit f07a5e9a 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 <rmaciel@linux.vnet.ibm.com> Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Axel Lin authored
commit d58e47d7 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 <axel.lin@ingics.com> [Guenter Roeck: Fix zone temperature cache] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Axel Lin authored
commit e9814295 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:
-
Guenter Roeck authored
commit 3248c3b7 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 <axel.lin@ingics.com> Reviewed-by:
-
Axel Lin authored
commit 56de1377 upstream. Current code uses channel as array index, so the valid channel value is 0 .. ADS1015_CHANNELS - 1. Signed-off-by:
-
Axel Lin authored
commit 2565fb05 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:
-
Guenter Roeck authored
commit 1074d683 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 <axel.lin@ingics.com> Reviewed-by:
-
Axel Lin authored
commit cf44819c 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 authored
commit cc336546 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:
-
Russell King authored
commit 2d31ca3a 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 <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Jeremy Vial authored
commit 9b5f7428 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 <jvial@adeneo-embedded.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Alexander Usyskin authored
commit 22b987a3 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 <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Takashi Iwai authored
commit f3ee07d8 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=52181Tested-by:
Francesco Muzio <muziofg@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hui Wang authored
commit f475371a 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/1358116Tested-by:
Franz Hsieh <franz.hsieh@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Clemens Ladisch authored
commit 53da5ebf 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 <kees.vanveen@gmail.com> Fixes: 8e5ced83 ("ALSA: usb-audio: remove superfluous Roland quirks") Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Takashi Iwai authored
commit e24aa0a4 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 <cosurgi@gmail.com> Signed-off-by:
-
Clemens Ladisch authored
commit f42bb222 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 <fugazzi99@gmail.com> Tested-by:
corubba <corubba@gmx.de> Signed-off-by:
-
Hui Wang authored
commit 7440850c 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/1350148Tested-by:
-
Pratyush Anand authored
commit a40178b2 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 <pratyush.anand@st.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Bryan O'Donoghue authored
commit 6e693739 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 <bryan.odonoghue@intel.com> Signed-off-by:
Alvin (Weike) Chen <alvin.chen@intel.com> Acked-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Patrick Riphagen authored
commit 4bdcde35 upstream. This adds support for new Xsens devices, using Xsens' own Vendor ID. Signed-off-by:
Patrick Riphagen <patrick.riphagen@xsens.com> Signed-off-by:
Frans Klaver <frans.klaver@xsens.com> Cc: Johan Hovold <johan@kernel.org> Signed-off-by:
-
Patrick Riphagen authored
commit 9273b8a2 upstream. The converters are used in specific products. It can be useful to know which they are exactly. Signed-off-by:
-
Oliver Neukum authored
commit d310d05f 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/13085Signed-off-by:
Oliver Neukum <oneukum@suse.de> Acked-by:
-
Alan Stern authored
commit 977dcfdc 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 authored
commit 256dbcd8 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:
-
Jan Kara authored
commit 410dd3cf 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 <cevans@google.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jiri Kosina authored
commit 4ab25786 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 <hawkes@google.com> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Jiri Kosina authored
commit ad3e14d7 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:
-
Bjorn Helgaas authored
commit c6bde215 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 <bhelgaas@google.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
