commit a8d97b1bd0c91fbc1be54d068b5f051b4f70b4f7 Author: Greg Kroah-Hartman Date: Fri Sep 5 16:32:00 2014 -0700 Linux 3.10.54 commit 3d81c4733b6b25c0b99c3c3c16cfd93183c27b03 Author: Greg Kroah-Hartman Date: Wed Aug 27 16:55:29 2014 -0700 USB: fix build error with CONFIG_PM_RUNTIME disabled commit a9ef803d740bfadf5e505fbc57efa57692e27025 upstream. commit bdd405d2a528 ("usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is disabled. Fix that by doing a simple #ifdef guard around it. Reported-by: Stephen Rothwell Reported-by: kbuild test robot Cc: Roger Quadros Cc: Michael Welling Cc: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 569ae35a436502bf1aaaa7391b94e1d04b61ffca Author: Trond Myklebust Date: Mon Aug 25 22:33:12 2014 -0400 NFSv4: Fix problems with close in the presence of a delegation commit aee7af356e151494d5014f57b33460b162f181b5 upstream. In the presence of delegations, we can no longer assume that the state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open stateid share mode, and so we need to calculate the initial value for calldata->arg.fmode using the state->flags. Reported-by: James Drews Fixes: 88069f77e1ac5 (NFSv41: Fix a potential state leakage when...) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit b6f70b7027f157fbba45091518f34faf40ad81b8 Author: Trond Myklebust Date: Sun Aug 24 14:46:48 2014 -0400 NFSv3: Fix another acl regression commit f87d928f6d98644d39809a013a22f981d39017cf upstream. When creating a new object on the NFS server, we should not be sending posix setacl requests unless the preceding posix_acl_create returned a non-trivial acl. Doing so, causes Solaris servers in particular to return an EINVAL. Fixes: 013cdf1088d72 (nfs: use generic posix ACL infrastructure,,,) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1132786 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c73df6f73c8167b9ed68d653d1a5c761c209d2b5 Author: Chuck Lever Date: Wed Jul 16 15:38:32 2014 -0400 svcrdma: Select NFSv4.1 backchannel transport based on forward channel commit 3c45ddf823d679a820adddd53b52c6699c9a05ac upstream. The current code always selects XPRT_TRANSPORT_BC_TCP for the back channel, even when the forward channel was not TCP (eg, RDMA). When a 4.1 mount is attempted with RDMA, the server panics in the TCP BC code when trying to send CB_NULL. Instead, construct the transport protocol number from the forward channel transport or'd with XPRT_TRANSPORT_BC. Transports that do not support bi-directional RPC will not have registered a "BC" transport, causing create_backchannel_client() to fail immediately. Fixes: https://bugzilla.linux-nfs.org/show_bug.cgi?id=265 Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit caacbac7bf646a29049bec3d9f5fcc20c846b3b2 Author: Kinglong Mee Date: Wed Jul 30 21:26:05 2014 +0800 NFSD: Decrease nfsd_users in nfsd_startup_generic fail commit d9499a95716db0d4bc9b67e88fd162133e7d6b08 upstream. A memory allocation failure could cause nfsd_startup_generic to fail, in which case nfsd_users wouldn't be incorrectly left elevated. After nfsd restarts nfsd_startup_generic will then succeed without doing anything--the first consequence is likely nfs4_start_net finding a bad laundry_wq and crashing. Signed-off-by: Kinglong Mee Fixes: 4539f14981ce "nfsd: replace boolean nfsd_up flag by users counter" Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 6a5335b46b463c469ca03ddb706c0562e881d2ed Author: Roger Quadros Date: Mon Aug 4 12:44:46 2014 +0300 usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1 commit bdd405d2a5287bdb9b04670ea255e1f122138e66 upstream. If user specifies that USB autosuspend must be disabled by module parameter "usbcore.autosuspend=-1" then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0" Signed-off-by: Roger Quadros Tested-by: Michael Welling Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit d0e6e29e2c9820d39b83fa275bf68c7c8bc7935e Author: James Forshaw Date: Sat Aug 23 14:39:48 2014 -0700 USB: whiteheat: Added bounds checking for bulk command response commit 6817ae225cd650fb1c3295d769298c38b1eba818 upstream. This patch fixes a potential security issue in the whiteheat USB driver which might allow a local attacker to cause kernel memory corrpution. This is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On EHCI and XHCI busses it's possible to craft responses greater than 64 bytes leading a buffer overflow. Signed-off-by: James Forshaw Signed-off-by: Greg Kroah-Hartman commit 17912b6285ac739e9c461a3601a4a7c7eda7a5a8 Author: Jaša Bartelj Date: Sat Aug 16 12:44:27 2014 +0200 USB: ftdi_sio: Added PID for new ekey device commit 646907f5bfb0782c731ae9ff6fb63471a3566132 upstream. Added support to the ftdi_sio driver for ekey Converter USB which uses an FT232BM chip. Signed-off-by: Jaša Bartelj Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 22de64f496ee7a1fc6460d5131f6fc506a2f7305 Author: Johan Hovold Date: Wed Aug 13 17:56:52 2014 +0200 USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID commit 6552cc7f09261db2aeaae389aa2c05a74b3a93b4 upstream. Add device id for Basic Micro ATOM Nano USB2Serial adapters. Reported-by: Nicolas Alt Tested-by: Nicolas Alt Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4268973202c86b58348366fdf81117b04adcadfd Author: Tony Lindgren Date: Mon Aug 25 16:15:35 2014 -0700 ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled commit cc824534d4fef0e46e4486d5c1e10d3c6b1ebadc upstream. Looks like MUSB cable removal can cause wake-up interrupts to stop working for device tree based booting at least for UART3 even as nothing is dynamically remuxed. This can be fixed by calling reconfigure_io_chain() for device tree based booting in hwmod code. Note that we already do that for legacy booting if the legacy mux is configured. My guess is that this is related to UART3 and MUSB ULPI hsusb0_data0 and hsusb0_data1 support for Carkit mode that somehow affect the configured IO chain for UART3 and require rearming the wake-up interrupts. In general, for device tree based booting, pinctrl-single calls the rearm hook that in turn calls reconfigure_io_chain so calling reconfigure_io_chain should not be needed from the hwmod code for other events. So let's limit the hwmod rearming of iochain only to HWMOD_FORCE_MSTANDBY where MUSB is currently the only user of it. If we see other devices needing similar changes we can add more checks for it. Cc: Paul Walmsley Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 607a00ad38bb2bc7fe3e3aebc4e6a0fe17d8351e Author: Huang Rui Date: Tue Aug 19 15:17:57 2014 +0300 usb: xhci: amd chipset also needs short TX quirk commit 2597fe99bb0259387111d0431691f5daac84f5a5 upstream. AMD xHC also needs short tx quirk after tested on most of chipset generations. That's because there is the same incorrect behavior like Fresco Logic host. Please see below message with on USB webcam attached on xHC host: [ 139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Reported-by: Arindam Nath Tested-by: Shriraj-Rai P Signed-off-by: Huang Rui Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 512c454e2639148b2385468c894244d9d91570a5 Author: Hans de Goede Date: Tue Aug 19 15:17:56 2014 +0300 xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_STOP_INVAL commit 9a54886342e227433aebc9d374f8ae268a836475 upstream. When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a the integrated Intel xhci controller on a Haswell laptop: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) The following error gets logged to dmesg: xhci error: Transfer event TRB DMA ptr not part of current TD Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found fixes this. Signed-off-by: Hans de Goede Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit a4e85832884d8aaf26f0b7cfe152f144f92eb80c Author: Ben Hutchings Date: Mon May 19 01:03:06 2014 +0100 Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to match vt commit 28a821c306889b9f2c3fff49abedc9b2c743eb73 upstream. This function is largely a duplicate of paste_selection() in drivers/tty/vt/selection.c, but with its own selection state. The speakup selection mechanism should really be merged with vt. For now, apply the changes from 'TTY: vt, fix paste_selection ldisc handling', 'tty: Make ldisc input flow control concurrency-friendly', and 'tty: Fix unsafe vt paste_selection()'. References: https://bugs.debian.org/735202 References: https://bugs.debian.org/744015 Reported-by: Paul Gevers Reported-and-tested-by: Jarek Czekalski Signed-off-by: Ben Hutchings [bwh: Backported to 3.10: - Only apply the changes from 'TTY: vt, fix paste_selection ldisc handling' - Add the same FIXME comment as vt's paste_selection() has in this version] Signed-off-by: Greg Kroah-Hartman commit 666cec8db793a67bf9071b9f0fd96c8af424a9b9 Author: Darrick J. Wong Date: Wed Aug 27 18:40:05 2014 -0400 jbd2: fix infinite loop when recovering corrupt journal blocks commit 022eaa7517017efe4f6538750c2b59a804dc7df7 upstream. When recovering the journal, don't fall into an infinite loop if we encounter a corrupt journal block. Instead, just skip the block and return an error, which fails the mount and thus forces the user to run a full filesystem fsck. Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d9fab037c6646f853cc71c0d5c740bd2981c48a2 Author: Alexander Usyskin Date: Tue Aug 12 18:07:57 2014 +0300 mei: nfc: fix memory leak in error path commit 8e8248b1369c97c7bb6f8bcaee1f05deeabab8ef upstream. NFC will leak buffer if send failed. Use single exit point that does the freeing Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 5935bef5cd35378a1e58333b6472b687c1a8b9cb Author: Alexander Usyskin Date: Tue Aug 12 18:07:56 2014 +0300 mei: reset client state on queued connect request commit 73ab4232388b7a08f17c8d08141ff2099fa0b161 upstream. If connect request is queued (e.g. device in pg) set client state to initializing, thus avoid preliminary exit in wait if current state is disconnected. This is regression from: commit e4d8270e604c3202131bac607969605ac397b893 Author: Alexander Usyskin mei: set connecting state just upon connection request is sent to the fw Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit a9c37c8a72a50312a38bd846f7a944ea1a46a4f1 Author: Filipe Manana Date: Sat Aug 9 21:22:27 2014 +0100 Btrfs: fix csum tree corruption, duplicate and outdated checksums commit 27b9a8122ff71a8cadfbffb9c4f0694300464f3b upstream. Under rare circumstances we can end up leaving 2 versions of a checksum for the same file extent range. The reason for this is that after calling btrfs_next_leaf we process slot 0 of the leaf it returns, instead of processing the slot set in path->slots[0]. Most of the time (by far) path->slots[0] is 0, but after btrfs_next_leaf() releases the path and before it searches for the next leaf, another task might cause a split of the next leaf, which migrates some of its keys to the leaf we were processing before calling btrfs_next_leaf(). In this case btrfs_next_leaf() returns again the same leaf but with path->slots[0] having a slot number corresponding to the first new key it got, that is, a slot number that didn't exist before calling btrfs_next_leaf(), as the leaf now has more keys than it had before. So we must really process the returned leaf starting at path->slots[0] always, as it isn't always 0, and the key at slot 0 can have an offset much lower than our search offset/bytenr. For example, consider the following scenario, where we have: sums->bytenr: 40157184, sums->len: 16384, sums end: 40173568 four 4kb file data blocks with offsets 40157184, 40161280, 40165376, 40169472 Leaf N: slot = 0 slot = btrfs_header_nritems() - 1 |-------------------------------------------------------------------| | [(CSUM CSUM 39239680), size 8] ... [(CSUM CSUM 40116224), size 4] | |-------------------------------------------------------------------| Leaf N + 1: slot = 0 slot = btrfs_header_nritems() - 1 |--------------------------------------------------------------------| | [(CSUM CSUM 40161280), size 32] ... [((CSUM CSUM 40615936), size 8 | |--------------------------------------------------------------------| Because we are at the last slot of leaf N, we call btrfs_next_leaf() to find the next highest key, which releases the current path and then searches for that next key. However after releasing the path and before finding that next key, the item at slot 0 of leaf N + 1 gets moved to leaf N, due to a call to ctree.c:push_leaf_left() (via ctree.c:split_leaf()), and therefore btrfs_next_leaf() will returns us a path again with leaf N but with the slot pointing to its new last key (CSUM CSUM 40161280). This new version of leaf N is then: slot = 0 slot = btrfs_header_nritems() - 2 slot = btrfs_header_nritems() - 1 |----------------------------------------------------------------------------------------------------| | [(CSUM CSUM 39239680), size 8] ... [(CSUM CSUM 40116224), size 4] [(CSUM CSUM 40161280), size 32] | |----------------------------------------------------------------------------------------------------| And incorrecly using slot 0, makes us set next_offset to 39239680 and we jump into the "insert:" label, which will set tmp to: tmp = min((sums->len - total_bytes) >> blocksize_bits, (next_offset - file_key.offset) >> blocksize_bits) = min((16384 - 0) >> 12, (39239680 - 40157184) >> 12) = min(4, (u64)-917504 = 18446744073708634112 >> 12) = 4 and ins_size = csum_size * tmp = 4 * 4 = 16 bytes. In other words, we insert a new csum item in the tree with key (CSUM_OBJECTID CSUM_KEY 40157184 = sums->bytenr) that contains the checksums for all the data (4 blocks of 4096 bytes each = sums->len). Which is wrong, because the item with key (CSUM CSUM 40161280) (the one that was moved from leaf N + 1 to the end of leaf N) contains the old checksums of the last 12288 bytes of our data and won't get those old checksums removed. So this leaves us 2 different checksums for 3 4kb blocks of data in the tree, and breaks the logical rule: Key_N+1.offset >= Key_N.offset + length_of_data_its_checksums_cover An obvious bad effect of this is that a subsequent csum tree lookup to get the checksum of any of the blocks with logical offset of 40161280, 40165376 or 40169472 (the last 3 4kb blocks of file data), will get the old checksums. Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 1c2cdf1f81de70a91bca8f0c5c4a6ae0f852490d 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: Greg Kroah-Hartman commit 29571876956efa104778957519c23792c66d3140 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: Greg Kroah-Hartman commit 27cca923cd5ddcbb57262216b96ffb89ef7372e4 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: Greg Kroah-Hartman commit 6dc6da0cc9a64f26304f2589fbd262e5198e207d 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: Greg Kroah-Hartman commit db58c6f5ec4c48a6073c90a25495d290229ae17c 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: Greg Kroah-Hartman commit ccdbe7da071912c422eb71fbbb873f16fd666db8 Author: Theodore Ts'o Date: Sat Aug 23 17:47:28 2014 -0400 ext4: fix BUG_ON in mb_free_blocks() commit c99d1e6e83b06744c75d9f5e491ed495a7086b7b upstream. If we suffer a block allocation failure (for example due to a memory allocation failure), it's possible that we will call ext4_discard_allocated_blocks() before we've actually allocated any blocks. In that case, fe_len and fe_start in ac->ac_f_ex will still be zero, and this will result in mb_free_blocks(inode, e4b, 0, 0) triggering the BUG_ON on mb_free_blocks(): BUG_ON(last >= (sb->s_blocksize << 3)); Fix this by bailing out of ext4_discard_allocated_blocks() if fs_len is zero. Also fix a missing ext4_mb_unload_buddy() call in ext4_discard_allocated_blocks(). Google-Bug-Id: 16844242 Fixes: 86f0afd463215fc3e58020493482faa4ac3a4d69 Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6e0db2f1e545f8848220e8692e4d3485c845c9cb 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: Greg Kroah-Hartman commit d3cf5ab75bba12328cc3a3960ee1b2dff623960c 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: Greg Kroah-Hartman commit d175e30c03decba32c5373379f5bab065267a074 Author: Wanpeng Li Date: Tue Aug 5 12:42:24 2014 +0800 KVM: nVMX: fix "acknowledge interrupt on exit" when APICv is in use commit 56cc2406d68c0f09505c389e276f27a99f495cbd upstream. After commit 77b0f5d (KVM: nVMX: Ack and write vector info to intr_info if L1 asks us to), "Acknowledge interrupt on exit" behavior can be emulated. To do so, KVM will ask the APIC for the interrupt vector if during a nested vmexit if VM_EXIT_ACK_INTR_ON_EXIT is set. With APICv, kvm_get_apic_interrupt would return -1 and give the following WARNING: Call Trace: [] dump_stack+0x49/0x5e [] warn_slowpath_common+0x7c/0x96 [] ? nested_vmx_vmexit+0xa4/0x233 [kvm_intel] [] warn_slowpath_null+0x15/0x17 [] nested_vmx_vmexit+0xa4/0x233 [kvm_intel] [] ? nested_vmx_exit_handled+0x6a/0x39e [kvm_intel] [] ? kvm_apic_has_interrupt+0x80/0xd5 [kvm] [] vmx_check_nested_events+0xc3/0xd3 [kvm_intel] [] inject_pending_event+0xd0/0x16e [kvm] [] vcpu_enter_guest+0x319/0x704 [kvm] To fix this, we cannot rely on the processor's virtual interrupt delivery, because "acknowledge interrupt on exit" must only update the virtual ISR/PPR/IRR registers (and SVI, which is just a cache of the virtual ISR) but it should not deliver the interrupt through the IDT. Thus, KVM has to deliver the interrupt "by hand", similar to the treatment of EOI in commit fc57ac2c9ca8 (KVM: lapic: sync highest ISR to hardware apic on EOI, 2014-05-14). The patch modifies kvm_cpu_get_interrupt to always acknowledge an interrupt; there are only two callers, and the other is not affected because it is never reached with kvm_apic_vid_enabled() == true. Then it modifies apic_set_isr and apic_clear_irr to update SVI and RVI in addition to the registers. Suggested-by: Paolo Bonzini Suggested-by: "Zhang, Yang Z" Tested-by: Liu, RongrongX Tested-by: Felipe Reyes Fixes: 77b0f5d67ff2781f36831cba79674c3e97bd7acf Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1933d1c5482b928599eabd7032672b35a15df066 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: Greg Kroah-Hartman commit 8277c1d67e4c273858e5a423a9d091074056cc06 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: Greg Kroah-Hartman commit 68344064b7c978712e32448d03935ad1ac6d75cd 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: Greg Kroah-Hartman commit fca04198d5b8e48a535df52ada1b6b384474cacc 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: Greg Kroah-Hartman commit 0ec5ac16b3d5b70cd0b34249addea6fb104e4305 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: Greg Kroah-Hartman commit b3a80775fa94e2896ecbd6e591bb3c5ff79003c4 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: Greg Kroah-Hartman commit 30b72362ba1daff9c7f3b7c19a9c93ba03c4172d 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: Greg Kroah-Hartman commit f93978fdb50ffde874bd40d012e54ce0ad275ff3 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: Greg Kroah-Hartman commit 53f281f2b4288f7b5ebfff3d76629e96bdd07f28 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: Greg Kroah-Hartman commit 06f770aa658cef847c8022bdff436885bde3f7bf 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: Greg Kroah-Hartman commit 6dbbe154751f97308e0cd029f0b15f7685897ecf 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: Greg Kroah-Hartman commit 070d6526cc0b0402c44868b31957d39b5d40cdd2 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: Greg Kroah-Hartman commit 5fafb69d9854a1b38ff0fe1b0058544b94702871 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: Greg Kroah-Hartman commit 61d2b2bea78efae53eee7d47c20a0637a1099c26 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: Greg Kroah-Hartman commit 324b23e38db599cd1eb610fb92b0142d5c0be4a8 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: Greg Kroah-Hartman commit 2cffa7238a408b7ff5ce9a4352485ff035fb7b19 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: Greg Kroah-Hartman commit 8666dec8958fc91913fe398178d26f33c1ea5745 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: Greg Kroah-Hartman commit 65d6bdd5e4438a64d7806c22ba85bfa5f3a03f89 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: Greg Kroah-Hartman commit 07a0ed1d0e6b32747e7f4723966c54e2652e3c74 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: Greg Kroah-Hartman commit 159902f39c3b38b626a50ce46874b13ea8d68aa9 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: Greg Kroah-Hartman commit eee49a52d540423742ee28afb95a3610c7e954d1 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: Greg Kroah-Hartman commit f788fb41375b8b174551289bfef17680ecf2416b 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: Greg Kroah-Hartman commit e57bd1dc6328d63bd268b91ab01f742fd6994db2 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: Greg Kroah-Hartman commit fe0d903cb746d5caf776e40412418fa23b6efa97 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: Greg Kroah-Hartman commit e7b094f88420d840c65a7b5499e3000d2a4c00ec 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: Greg Kroah-Hartman commit d4be3e07222e7572df4af6c4dd91e4b569a3ce20 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: Greg Kroah-Hartman commit 0c9fdd4c5af24ea49424903296cb1f7420505e9e 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: Greg Kroah-Hartman commit 4292001d4de0681e2f1eb59d13511012369324e0 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: Greg Kroah-Hartman commit 38d467b3effd465be24a20e2d861b9049d4f333f Author: Dave Chiluk Date: Tue Jun 24 10:11:26 2014 -0500 stable_kernel_rules: Add pointer to netdev-FAQ for network patches commit b76fc285337b6b256e9ba20a40cfd043f70c27af upstream. Stable_kernel_rules should point submitters of network stable patches to the netdev_FAQ.txt as requests for stable network patches should go to netdev first. Signed-off-by: Dave Chiluk Signed-off-by: Greg Kroah-Hartman