commit cac65253a9c5a30d4c8d7bc4c60197935f9e2e70 Author: Greg Kroah-Hartman Date: Sat Oct 5 07:13:21 2013 -0700 Linux 3.10.15 commit 5ffe7285aa50470853f2a06188b5578c4397c7c2 Author: Daniel Vetter Date: Fri Jul 26 11:27:49 2013 +0200 drm/i915: fix gen4 digital port hotplug definitions commit 0ce99f749b3834edeb500e17d6ad17e86b60ff83 upstream. Apparently Bspec is wrong in this case here even for gm45. Note that Bspec is horribly misguided on i965g/gm, so we don't have any other data points besides that it seems to make machines work better. With this changes all the bits in PORT_HOTPLUG_STAT for the digital ports are ordered the same way. This seems to agree with what register dumps from the hpd storm handling code shows, where the LIVE bit and the short/long pulse STATUS bits light up at the same time with this enumeration (but no with the one from Bspec). Also tested on my gm45 which has two DP+ ports, and everything seems to still work as expected. References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html Cc: Egbert Eich Cc: Jan Niggemann Tested-by: Jan Niggemann [danvet: Add a big warning that Bspec seems to be wrong for these bits, suggested by Jani.] Acked-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1aff4161cc9ed30b6842030ec1b91b4cdca1a811 Author: Liam Girdwood Date: Fri Sep 13 17:43:17 2013 +0100 ALSA: compress: Fix compress device unregister. commit 4028b6c4c03f213260e9290ff3a6b5439aad07ce upstream. snd_unregister_device() should return the device type and not stream direction. Signed-off-by: Liam Girdwood Acked-by: Vinod Koul Tested-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 332769e13b075c82ae7b9f79be29506f8c6aceb2 Author: Henrik Rydberg Date: Thu Sep 26 08:33:16 2013 +0200 hwmon: (applesmc) Check key count before proceeding commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream. After reports from Chris and Josh Boyer of a rare crash in applesmc, Guenter pointed at the initialization problem fixed below. The patch has not been verified to fix the crash, but should be applied regardless. Reported-by: Suggested-by: Guenter Roeck Signed-off-by: Henrik Rydberg Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 37482f9cfb0269e082a817f31ad2a5f0204163f9 Author: Arnd Bergmann Date: Mon Jun 3 16:00:22 2013 +0200 ARM: mxs: stub out mxs_pm_init for !CONFIG_PM commit 7a9caf59f60e55a8caf96f856713bd0ef0cc25a7 upstream. When building a kernel without CONFIG_PM, we get a link error from referencing mxs_pm_init in the machine descriptor. This defines a macro to NULL for that case. Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit ddcca42fb47e59b1655d866b364c3dac4ba3f135 Author: Alex Deucher Date: Wed Sep 25 12:04:37 2013 -0400 drm/radeon: fix hdmi audio on DCE3.0/3.1 asics commit 58d327da9721f7a0f6e46c8dfa5cc5546fd7078a upstream. These asics seem to use a mix of the DCE2.x and DCE3.2 audio interfaces despite what the register spec says. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69729 https://bugs.freedesktop.org/show_bug.cgi?id=69671 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b2a9484006875ecd7d94582e7bcb72a02682be92 Author: Alex Deucher Date: Mon Sep 23 15:47:08 2013 -0400 drm/radeon: add missing hdmi callbacks for rv6xx commit 99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 upstream. When dpm was merged, I added a new asic struct for rv6xx, but it never got properly updated when the hdmi callbacks were added due to the two patch sets being developed in parallel. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69729 Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 05e1be66ed3e42ea63a30771531af4d9146efe3c Author: Alex Deucher Date: Mon Sep 23 10:38:26 2013 -0400 drm/radeon: disable tests/benchmarks if accel is disabled commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream. The tests are only usable if the acceleration engines have been successfully initialized. Based on an initial patch from: Alex Ivanov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f329055796c2c2d4d0a6fe4691755213cfef6187 Author: Alex Ivanov Date: Fri Sep 20 17:36:06 2013 +0400 drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2) commit 0eb3448aa6b31fbf24c31756aba7940cac5ad6b8 upstream. Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job. Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a KP if ring buffer was deallocated, e.g. on failed ring test. Seen on PA-RISC machine having "radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)" issue. v2: agd5f: add some parens around ring->ready check Signed-off-by: Alex Ivanov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6452230ccfffec35fc7ee2e5f3e3bb6f8ab6570d Author: Alex Deucher Date: Sun Sep 15 23:23:07 2013 -0400 drm/radeon: avoid UVD corruption on AGP cards using GPU gart commit 4ca5a6cba53e13b8fd153b0762b4128fab6a3cfb upstream. If the user has forced the driver to use the internal GPU gart rather than AGP on an AGP card, force the buffers to vram as well. Signed-off-by: Alex Deucher Reviewed-by: Christian König Tested-by: Dieter Nützel Signed-off-by: Greg Kroah-Hartman commit d113feebb1081c4baa720c5fc99c984fb4e2e598 Author: Jani Nikula Date: Fri Sep 20 16:42:15 2013 +0300 drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream. There is no clear cut rules or specs for the retry interval, as there are many factors that affect overall response time. Increase the interval, and even more so on branch devices which may have limited i2c bit rates. Signed-off-by: Jani Nikula Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263 Tested-by: Nicolas Suzor Reviewed-by: Todd Previte Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 3ef7d935f87406489889c792ebc1218feaeaab44 Author: Daniel Vetter Date: Tue Sep 24 11:46:14 2013 +0200 drm/i915: preserve pipe A quirk in i9xx_set_pipeconf commit 67c72a12254101d4e8d9b9f3a02646ba0be84a2d upstream. This regression has been introduced in commit 9f11a9e4e50006b615ba94722dfc33ced89664cf Author: Daniel Vetter Date: Thu Jun 13 00:54:58 2013 +0200 drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms Ville brough up the idea that this is just the pipe A quirk gone wrong. Note that after resume the bios might or might not have enabled pipe A already. We have a bit of magic to make sure that on resume we set up a decent mode for pipe A, but I fear if I just smash pipe A to always on we'd enable it in a bogus state and hang the hw. Hence the readback. v2: Clarify the logic a bit as suggested by Chris. Also amend the commit message to clarify why we don't unconditionally enable the pipe. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462 References: https://lkml.org/lkml/2013/8/26/238 Cc: Meelis Roos Cc: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Chris Wilson [danvet: Use |= instead of = as suggested by Chris.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit f38af5d3f6aa1186b0ac9a1ef021d425550b479b Author: NeilBrown Date: Thu May 9 10:27:49 2013 +1000 dm-raid: silence compiler warning on rebuilds_per_group. commit 3f6bbd3ffd7b733dd705e494663e5761aa2cb9c1 upstream. This doesn't really need to be initialised, but it doesn't hurt, silences the compiler, and as it is a counter it makes sense for it to start at zero. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit e9d60f699108682bad9c4604feb408ac9198b232 Author: Mike Snitzer Date: Thu Sep 19 12:13:58 2013 -0400 dm mpath: disable WRITE SAME if it fails commit f84cb8a46a771f36a04a02c61ea635c968ed5f6a upstream. Workaround the SCSI layer's problematic WRITE SAME heuristics by disabling WRITE SAME in the DM multipath device's queue_limits if an underlying device disabled it. The WRITE SAME heuristics, with both the original commit 5db44863b6eb ("[SCSI] sd: Implement support for WRITE SAME") and the updated commit 66c28f971 ("[SCSI] sd: Update WRITE SAME heuristics"), default to enabling WRITE SAME(10) even without successfully determining it is supported. After the first failed WRITE SAME the SCSI layer will disable WRITE SAME for the device (by setting sdkp->device->no_write_same which results in 'max_write_same_sectors' in device's queue_limits to be set to 0). When a device is stacked ontop of such a SCSI device any changes to that SCSI device's queue_limits do not automatically propagate up the stack. As such, a DM multipath device will not have its WRITE SAME support disabled. This causes the block layer to continue to issue WRITE SAME requests to the mpath device which causes paths to fail and (if mpath IO isn't configured to queue when no paths are available) it will result in actual IO errors to the upper layers. This fix doesn't help configurations that have additional devices stacked ontop of the mpath device (e.g. LVM created linear DM devices ontop). A proper fix that restacks all the queue_limits from the bottom of the device stack up will need to be explored if SCSI will continue to use this model of optimistically allowing op codes and then disabling them after they fail for the first time. Before this patch: EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null) device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121) device-mapper: multipath: XXX snitm debugging: failing WRITE SAME IO with error=-121 end_request: critical target error, dev dm-6, sector 528 dm-6: WRITE SAME failed. Manually zeroing. device-mapper: multipath: Failing path 8:112. end_request: I/O error, dev dm-6, sector 4616 dm-6: WRITE SAME failed. Manually zeroing. end_request: I/O error, dev dm-6, sector 4616 end_request: I/O error, dev dm-6, sector 5640 end_request: I/O error, dev dm-6, sector 6664 end_request: I/O error, dev dm-6, sector 7688 end_request: I/O error, dev dm-6, sector 524288 Buffer I/O error on device dm-6, logical block 65536 lost page write due to I/O error on dm-6 JBD2: Error -5 detected when updating journal superblock for dm-6-8. end_request: I/O error, dev dm-6, sector 524296 Aborting journal on device dm-6-8. end_request: I/O error, dev dm-6, sector 524288 Buffer I/O error on device dm-6, logical block 65536 lost page write due to I/O error on dm-6 JBD2: Error -5 detected when updating journal superblock for dm-6-8. # cat /sys/block/sdh/queue/write_same_max_bytes 0 # cat /sys/block/dm-6/queue/write_same_max_bytes 33553920 After this patch: EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null) device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121) device-mapper: multipath: XXX snitm debugging: WRITE SAME I/O failed with error=-121 end_request: critical target error, dev dm-6, sector 528 dm-6: WRITE SAME failed. Manually zeroing. # cat /sys/block/sdh/queue/write_same_max_bytes 0 # cat /sys/block/dm-6/queue/write_same_max_bytes 0 It should be noted that WRITE SAME support wasn't enabled in DM multipath until v3.10. Signed-off-by: Mike Snitzer Cc: Martin K. Petersen Cc: Hannes Reinecke Signed-off-by: Greg Kroah-Hartman commit 0f64fad39c9577f3eaa26b45a9ad774c415c19ff Author: Mikulas Patocka Date: Wed Sep 18 19:40:42 2013 -0400 dm-snapshot: fix performance degradation due to small hash size commit 60e356f381954d79088d0455e357db48cfdd6857 upstream. LVM2, since version 2.02.96, creates origin with zero size, then loads the snapshot driver and then loads the origin. Consequently, the snapshot driver sees the origin size zero and sets the hash size to the lower bound 64. Such small hash table causes performance degradation. This patch changes it so that the hash size is determined by the size of snapshot volume, not minimum of origin and snapshot size. It doesn't make sense to set the snapshot size significantly larger than the origin size, so we do not need to take origin size into account when calculating the hash size. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4541f4e356fe1d9d47165a041f85235e394b0d61 Author: Mikulas Patocka Date: Wed Sep 18 19:14:22 2013 -0400 dm snapshot: workaround for a false positive lockdep warning commit 5ea330a75bd86b2b2a01d7b85c516983238306fb upstream. The kernel reports a lockdep warning if a snapshot is invalidated because it runs out of space. The lockdep warning was triggered by commit 0976dfc1d0cd80a4e9dfaf87bd87 ("workqueue: Catch more locking problems with flush_work()") in v3.5. The warning is false positive. The real cause for the warning is that the lockdep engine treats different instances of md->lock as a single lock. This patch is a workaround - we use flush_workqueue instead of flush_work. This code path is not performance sensitive (it is called only on initialization or invalidation), thus it doesn't matter that we flush the whole workqueue. The real fix for the problem would be to teach the lockdep engine to treat different instances of md->lock as separate locks. Signed-off-by: Mikulas Patocka Acked-by: Alasdair G Kergon Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 78421afdbf0ac17baee98a9caed80c8141a121d3 Author: Benson Leung Date: Tue Sep 24 20:05:11 2013 -0700 driver core : Fix use after free of dev->parent in device_shutdown commit f123db8e9d6c84c863cb3c44d17e61995dc984fb upstream. The put_device(dev) at the bottom of the loop of device_shutdown may result in the dev being cleaned up. In device_create_release, the dev is kfreed. However, device_shutdown attempts to use the dev pointer again after put_device by referring to dev->parent. Copy the parent pointer instead to avoid this condition. This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11. See bug report : https://code.google.com/p/chromium/issues/detail?id=297842 This can easily be reproduced when shutting down with hidraw devices that report battery condition. Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse. For example, with the magic mouse : The dev in question is "hidraw0" dev->parent is "magicmouse" In the course of the shutdown for this device, the input event cleanup calls a put on hidraw0, decrementing its reference count. When we finally get to put_device(dev) in device_shutdown, kobject_cleanup is called and device_create_release does kfree(dev). dev->parent is no longer valid, and we may crash in put_device(dev->parent). This change should be applied on any kernel with this change : d1c6c030fcec6f860d9bb6c632a3ebe62e28440b Signed-off-by: Benson Leung Reviewed-by: Ming Lei Signed-off-by: Greg Kroah-Hartman commit 0ce8614959e1630ed3ce1fd36a689e80ca945f94 Author: Kurt Garloff Date: Tue Sep 24 14:13:48 2013 +0200 usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream. Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101) [1] with the Windows App (EasyNote) works natively but fails when Windows is running under KVM (and the USB device handed to KVM). The reason is a USB control message usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008 This goes to endpoint address 0x01 (wIndex); however, endpoint address 0x01 does not exist. There is an endpoint 0x81 though (same number, but other direction); the app may have meant that endpoint instead. The kernel thus rejects the IO and thus we see the failure. Apparently, Linux is more strict here than Windows ... we can't change the Win app easily, so that's a problem. It seems that the Win app/driver is buggy here and the driver does not behave fully according to the USB HID class spec that it claims to belong to. The device seems to happily deal with that though (and seems to not really care about this value much). So the question is whether the Linux kernel should filter here. Rejecting has the risk that somewhat non-compliant userspace apps/ drivers (most likely in a virtual machine) are prevented from working. Not rejecting has the risk of confusing an overly sensitive device with such a transfer. Given the fact that Windows does not filter it makes this risk rather small though. The patch makes the kernel more tolerant: If the endpoint address in wIndex does not exist, but an endpoint with toggled direction bit does, it will let the transfer through. (It does NOT change the message.) With attached patch, the app in Windows in KVM works. usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81 I suspect this will mostly affect apps in virtual environments; as on Linux the apps would have been adapted to the stricter handling of the kernel. I have done that for mine[2]. [1] http://www.pegatech.com/ [2] https://sourceforge.net/projects/notetakerpen/ Signed-off-by: Kurt Garloff Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 3dbfe91ab236d6edd20c52d87b99c5de8b85429d Author: David Cohen Date: Thu Sep 26 13:01:44 2013 -0700 usb: dwc3: add support for Merrifield commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream. Add PCI id for Intel Merrifield Signed-off-by: David Cohen Signed-off-by: Greg Kroah-Hartman commit 85f78609d213684c3079a0e1716ee6082868814d Author: Heikki Krogerus Date: Tue Sep 17 10:38:13 2013 +0300 usb: dwc3: pci: add support for BayTrail commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream. Add PCI id for Intel BayTrail. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 07fa74e048755aa8ff07a513e2362722a1c282e7 Author: Ramneek Mehresh Date: Mon Sep 16 15:11:33 2013 +0530 fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy commit ad1260e9fbf768d6bed227d9604ebee76a84aae3 upstream. For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL bit when USB_EN bit is already set causes instability issues with PHY_CLK_VLD bit. So USB_EN is set only for IP controller version below 1.6 before setting ULPI_PHY_CLK_SEL bit Signed-off-by: Ramneek Mehresh Signed-off-by: Greg Kroah-Hartman commit 88b1befdb45f9f5aee5d00a22c4c06bdf5193d4e Author: Al Viro Date: Fri Sep 20 17:14:21 2013 +0100 USB: Fix breakage in ffs_fs_mount() commit 2606b28aabd7dea1766c23a105e1124c95409c96 upstream. There's a bunch of failure exits in ffs_fs_mount() with seriously broken recovery logics. Most of that appears to stem from misunderstanding of the ->kill_sb() semantics; unlike ->put_super() it is called for *all* superblocks of given type, no matter how (in)complete the setup had been. ->put_super() is called only if ->s_root is not NULL; any failure prior to setting ->s_root will have the call of ->put_super() skipped. ->kill_sb(), OTOH, awaits every superblock that has come from sget(). Current behaviour of ffs_fs_mount(): We have struct ffs_sb_fill_data data on stack there. We do ffs_dev = functionfs_acquire_dev_callback(dev_name); and store that in data.private_data. Then we call mount_nodev(), passing it ffs_sb_fill() as a callback. That will either fail outright, or manage to call ffs_sb_fill(). There we allocate an instance of struct ffs_data, slap the value of ffs_dev (picked from data.private_data) into ffs->private_data and overwrite data.private_data by storing ffs into an overlapping member (data.ffs_data). Then we store ffs into sb->s_fs_info and attempt to set the rest of the things up (root inode, root dentry, then create /ep0 there). Any of those might fail. Should that happen, we get ffs_fs_kill_sb() called before mount_nodev() returns. If mount_nodev() fails for any reason whatsoever, we proceed to functionfs_release_dev_callback(data.ffs_data); That's broken in a lot of ways. Suppose the thing has failed in allocation of e.g. root inode or dentry. We have functionfs_release_dev_callback(ffs); ffs_data_put(ffs); done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by functionfs_release_dev_callback(ffs); from ffs_fs_mount() (via data.ffs_data). Note that the second functionfs_release_dev_callback() has every chance to be done to freed memory. Suppose we fail *before* root inode allocation. What happens then? ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all, or it doesn't have a pointer to ffs stored in sb->s_fs_info). And functionfs_release_dev_callback(data.ffs_data); is called by ffs_fs_mount(), but here we are in nasal daemon country - we are reading from a member of union we'd never stored into. In practice, we'll get what we used to store into the overlapping field, i.e. ffs_dev. And then we get screwed, since we treat it (struct gfs_ffs_obj * in disguise, returned by functionfs_acquire_dev_callback()) as struct ffs_data *, pick what would've been ffs_data ->private_data from it (*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data is much bigger) and poke in whatever it points to. FWIW, there's a minor leak on top of all that in case if ffs_sb_fill() fails on kstrdup() - ffs is obviously forgotten. The thing is, there is no point in playing all those games with union. Just allocate and initialize ffs_data *before* calling mount_nodev() and pass a pointer to it via data.ffs_data. And once it's stored in sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that it doesn't need to kill the sucker manually - from that point on we'll have it done by ->kill_sb(). Signed-off-by: Al Viro Acked-by: Michal Nazarewicz Signed-off-by: Greg Kroah-Hartman commit 01ec662c0cfe0304b583ab5b8a6aa8797f4c9828 Author: Alan Stern Date: Tue Sep 24 15:47:20 2013 -0400 USB: UHCI: accept very late isochronous URBs commit bef073b067a7b1874a6b381e0035bb0516d71a77 upstream. Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs) changed the isochronous API provided by ehci-hcd. URBs submitted too late, so that the time slots for all their packets have already expired, are no longer rejected outright. Instead the submission is accepted, and the URB completes normally with a -EXDEV error for each packet. This is what client drivers expect. This patch implements the same policy in uhci-hcd. It should be applied to all kernels containing commit c44b225077bb (UHCI: implement new semantics for URB_ISO_ASAP). Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 7ca9229cd69ae54e9e124c6643e26c977dd82a6f Author: Alan Stern Date: Tue Sep 24 15:46:45 2013 -0400 USB: OHCI: accept very late isochronous URBs commit a8693424c751b8247ee19bd8b857f1d4f432b972 upstream. Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs) changed the isochronous API provided by ehci-hcd. URBs submitted too late, so that the time slots for all their packets have already expired, are no longer rejected outright. Instead the submission is accepted, and the URB completes normally with a -EXDEV error for each packet. This is what client drivers expect. This patch implements the same policy in ohci-hcd. The change is more complicated than it was in ehci-hcd, because ohci-hcd doesn't scan for isochronous completions in the same way as ehci-hcd does. Rather, it depends on the hardware adding completed TDs to a "done queue". Some OHCI controller don't handle this properly when a TD's time slot has already expired, so we have to avoid adding such TDs to the schedule in the first place. As a result, if the URB was submitted too late then none of its TDs will get put on the schedule, so none of them will end up on the done queue, so the driver will never realize that the URB should be completed. To solve this problem, the patch adds one to urb_priv->td_cnt for such URBs, making it larger than urb_priv->length (td_cnt already gets set to the number of TD's that had to be skipped because their slots have expired). Each time an URB is given back, the finish_urb() routine looks to see if urb_priv->td_cnt for the next URB on the same endpoint is marked in this way. If so, it gives back the next URB right away. This should be applied to all kernels containing commit 815fa7b91761 (USB: OHCI: fix logic for scheduling isochronous URBs). Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 27e08a9885a9dab816af72f86b92f2f3513e8314 Author: Florian Wolter Date: Wed Aug 14 10:33:16 2013 +0200 xhci: Fix race between ep halt and URB cancellation commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream. The halted state of a endpoint cannot be cleared over CLEAR_HALT from a user process, because the stopped_td variable was overwritten in the handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will refuse the reset and communication with device can not run over this endpoint. https://bugzilla.kernel.org/show_bug.cgi?id=60699 Signed-off-by: Florian Wolter Signed-off-by: Sarah Sharp Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit c9dd3462b3f99a4a397b7d90265c2e21831ed3a0 Author: Alan Stern Date: Tue Sep 24 15:45:25 2013 -0400 USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd commit f875fdbf344b9fde207f66b392c40845dd7e5aa6 upstream. Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm field in their pci_driver structures should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. The corresponding change has already been made for ohci-hcd. Without this change, controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by: Alan Stern CC: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit a9b9047e6dcdfa8472b39d5a3c374d74d89a7f4d Author: Mathias Nyman Date: Thu Sep 5 11:01:20 2013 +0300 xhci: Fix oops happening after address device timeout commit 284d20552461466b04d6bfeafeb1c47a8891b591 upstream. When a command times out, the command ring is first aborted, and then stopped. If the command ring is empty when it is stopped the stop event will point to next command which is not yet set. xHCI tries to handle this next event often causing an oops. Don't handle command completion events on stopped cmd ring if ring is empty. This patch should be backported to kernels as old as 3.7, that contain the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting command ring function" Signed-off-by: Mathias Nyman Reported-by: Giovanni Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 57ad776884c52610af5e00d53e9755f2a8d50bbd Author: Mathias Nyman Date: Fri Aug 30 18:25:49 2013 +0300 xhci: Ensure a command structure points to the correct trb on the command ring commit ec7e43e2d98173483866fe2e4e690143626b659c upstream. If a command on the command ring needs to be cancelled before it is handled it can be turned to a no-op operation when the ring is stopped. We want to store the command ring enqueue pointer in the command structure when the command in enqueued for the cancellation case. Some commands used to store the command ring dequeue pointers instead of enqueue (these often worked because enqueue happends to equal dequeue quite often) Other commands correctly used the enqueue pointer but did not check if it pointed to a valid trb or a link trb, this caused for example stop endpoint command to timeout in xhci_stop_device() in about 2% of suspend/resume cases. This should also solve some weird behavior happening in command cancellation cases. This patch is based on a patch submitted by Sarah Sharp to linux-usb, but then forgotten: http://marc.info/?l=linux-usb&m=136269803207465&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting command ring function" Signed-off-by: Mathias Nyman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 4bc8e1356cf9c7c2dbff522671a5d6d33d49c2ba Author: Daniel Vetter Date: Tue Sep 10 11:44:30 2013 +0200 drm/i915/tv: clear adjusted_mode.flags commit 1062b81598bc00e2f6620e6f3788f8f8df2f01e7 upstream. The native TV encoder has it's own flags to adjust sync modes and enabled interlaced modes which are totally irrelevant for the adjusted mode. This worked out nicely since the input modes used by both the load detect code and reported in the ->get_modes callbacks all have no flags set, and we also don't fill out any of them in the ->get_config callback. This changed with the additional sanitation done with commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0 Author: Imre Deak Date: Tue Jul 30 13:36:32 2013 +0300 drm/i915: make user mode sync polarity setting explicit sinc now the "no flags at all" state wouldn't fit through core code any more. So fix this up again by explicitly clearing the flags in the ->compute_config callback. Aside: We have zero checking in place to make sure that the requested mode is indeed the right input mode we want for the selected TV mode. So we'll happily fall over if userspace tries to pull us. But that's definitely work for a different patch series. So just add a FIXME comment for now. Reported-by: Knut Petersen Cc: Knut Petersen Cc: Imre Deak Cc: Chris Wilson Tested-by: Knut Petersen Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 54cff964637d840e7860afa49a369c84c8cfbf61 Author: Malcolm Priestley Date: Mon Sep 23 20:30:42 2013 +0100 staging: vt6656: [BUG] iwctl_siwencodeext return if device not open commit 5e8c3d3e41b0bf241e830a1ee0752405adecc050 upstream. Don't allow entry to iwctl_siwencodeext if device not open. This fixes a race condition where wpa supplicant/network manager enters the function when the device is already closed. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit d66aed99301eb9dd6a6e71f73081057480369ab4 Author: Malcolm Priestley Date: Sun Sep 22 19:48:54 2013 +0100 staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier. commit e3eb270fab7734427dd8171a93e4946fe28674bc upstream. The vt6656 is prone to resetting on the usb bus. It seems there is a race condition and wpa supplicant is trying to open the device via iw_handlers before its actually closed at a stage that the buffers are being removed. The device is longer considered open when the buffers are being removed. So move ~DEVICE_FLAGS_OPENED flag to before freeing the device buffers. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit ace53ef6a91d0afcb4f45fa06d162fe45c7c3b2f Author: Ard Biesheuvel Date: Sat Sep 21 11:23:50 2013 +0100 ARM: 7837/3: fix Thumb-2 bug in AES assembler code commit 40190c85f427dcfdbab5dbef4ffd2510d649da1f upstream. Patch 638591c enabled building the AES assembler code in Thumb2 mode. However, this code used arithmetic involving PC rather than adr{l} instructions to generate PC-relative references to the lookup tables, and this needs to take into account the different PC offset when running in Thumb mode. Signed-off-by: Ard Biesheuvel Acked-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 20d7e144c93a9f06224fc983cb5b248bb5bc87fb Author: Johan Hovold Date: Tue Sep 10 12:50:50 2013 +0200 serial: pch_uart: fix tty-kref leak in dma-rx path commit 19b85cfb190eb9980eaf416bff96aef4159a430e upstream. Fix tty_kref leak when tty_buffer_request room fails in dma-rx path. Note that the tty ref isn't really needed anymore, but as the leak has always been there, fixing it before removing should makes it easier to backport the fix. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b0a382b5a35e306362cde912bff18a42cc00b0f5 Author: Johan Hovold Date: Tue Sep 10 12:50:49 2013 +0200 serial: pch_uart: fix tty-kref leak in rx-error path commit fc0919c68cb2f75bb1af759315f9d7e2a9443c28 upstream. Fix tty-kref leak introduced by commit 384e301e ("pch_uart: fix a deadlock when pch_uart as console") which never put its tty reference. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 64dc8de491ef490e979fe65d83daaadf32c83633 Author: Johan Hovold Date: Tue Sep 10 12:50:48 2013 +0200 serial: tegra: fix tty-kref leak commit cfd29aa0e81b791985e8428e6507e80e074e6730 upstream. Fix potential tty-kref leak in stop_rx path. Signed-off-by: Johan Hovold Tested-by: Stephen Warren Signed-off-by: Greg Kroah-Hartman commit fe0da74501e9eb204dc1b8167708bd9273f4277f Author: Peter Hurley Date: Wed Sep 25 20:13:04 2013 -0400 tty: Fix SIGTTOU not sent with tcflush() commit 5cec7bf699c61d14f0538345076480bb8c8ebfbb upstream. Commit 'e7f3880cd9b98c5bf9391ae7acdec82b75403776' tty: Fix recursive deadlock in tty_perform_flush() introduced a regression where tcflush() does not generate SIGTTOU for background process groups. Make sure ioctl(TCFLSH) calls tty_check_change() when invoked from the line discipline. Reported-by: Oleg Nesterov Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 51d4e0771c3c69bb021d3052433e49effa6e4f65 Author: Alexander Usyskin Date: Mon Sep 2 13:29:47 2013 +0300 mei: cancel stall timers in mei_reset commit 4a704575cc1afb3b848f096778fa9b8d7b3d5813 upstream. Unset init_clients_timer and amthif_stall_timers in mei_reset in order to cancel timer ticking and hence avoid recursive reset calls. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 18f48d9e784339c954eb1641fef600e00c7a53c0 Author: Tomas Winkler Date: Mon Sep 2 13:29:46 2013 +0300 mei: bus: stop wait for read during cl state transition commit e2b31644e999e8bfe3efce880fb32840299abf41 upstream. Bus layer omitted check for client state transition while waiting for read completion The client state transition may occur for example as result of firmware initiated reset Add mei_cl_is_transitioning wrapper to reduce the code repetition.: Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit cb4af713f95f049056c25e0c18f652c3338c2bc7 Author: Tomas Winkler Date: Mon Sep 2 13:29:45 2013 +0300 mei: make me client counters less error prone commit 1aee351a739153529fbb98ee461777b2abd5e1c9 upstream. 1. u8 counters are prone to hard to detect overflow: make them unsigned long to match bit_ functions argument type 2. don't check me_clients_num for negativity, it is unsigned. 3. init all the me client counters from one place Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 81fbb94d1fbdad184ca4091da4cae87a92dbf3c7 Author: Josh Boyer Date: Thu Apr 18 07:51:34 2013 -0700 x86, efi: Don't map Boot Services on i386 commit 700870119f49084da004ab588ea2b799689efaf7 upstream. Add patch to fix 32bit EFI service mapping (rhbz 726701) Multiple people are reporting hitting the following WARNING on i386, WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440() Modules linked in: Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95 Call Trace: [] warn_slowpath_common+0x5f/0x80 [] ? __ioremap_caller+0x3d3/0x440 [] ? __ioremap_caller+0x3d3/0x440 [] warn_slowpath_null+0x1d/0x20 [] __ioremap_caller+0x3d3/0x440 [] ? get_usage_chars+0xfb/0x110 [] ? vprintk_emit+0x147/0x480 [] ? efi_enter_virtual_mode+0x1e4/0x3de [] ioremap_cache+0x1a/0x20 [] ? efi_enter_virtual_mode+0x1e4/0x3de [] efi_enter_virtual_mode+0x1e4/0x3de [] start_kernel+0x286/0x2f4 [] ? repair_env_string+0x51/0x51 [] i386_start_kernel+0x12c/0x12f Due to the workaround described in commit 916f676f8 ("x86, efi: Retain boot service code until after switching to virtual mode") EFI Boot Service regions are mapped for a period during boot. Unfortunately, with the limited size of the i386 direct kernel map it's possible that some of the Boot Service regions will not be directly accessible, which causes them to be ioremap()'d, triggering the above warning as the regions are marked as E820_RAM in the e820 memmap. There are currently only two situations where we need to map EFI Boot Service regions, 1. To workaround the firmware bug described in 916f676f8 2. To access the ACPI BGRT image but since we haven't seen an i386 implementation that requires either, this simple fix should suffice for now. [ Added to changelog - Matt ] Reported-by: Bryan O'Donoghue Acked-by: Tom Zanussi Acked-by: Darren Hart Cc: Josh Triplett Cc: Matthew Garrett Cc: H. Peter Anvin Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Signed-off-by: Josh Boyer Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 655325c7e4f62ece9bea61e5b24d8118d6e09ef1 Author: Vinson Lee Date: Wed Sep 18 16:16:40 2013 -0700 tools lib lk: Uninclude linux/magic.h in debugfs.c commit ce7eebe5c3deef8e19c177c24ee75843256e69ca upstream. The compilation only looks for linux/magic.h from the default include paths, which does not include the source tree. This results in a build error if linux/magic.h is not available or not installed. For example, this build error occurs on CentOS 5. $ make -C tools/lib/lk V=1 [...] gcc -o debugfs.o -c -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-aliasing=3 -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -fPIC -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 debugfs.c debugfs.c:8:25: error: linux/magic.h: No such file or directory The only symbol from linux/magic.h needed by debugfs.c is DEBUGFS_MAGIC, and that is already defined in debugfs.h. linux/magic.h isn't providing any extra symbols and can unincluded. This is similar to the approach by perf, which has its own magic.h wrapper at tools/perf/util/include/linux/magic.h Signed-off-by: Vinson Lee Acked-by: Borislav Petkov Cc: Borislav Petkov Cc: Vinson Lee Link: http://lkml.kernel.org/r/1379546200-17028-1-git-send-email-vlee@freedesktop.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit fdc43786ed80ac4d85fb82ed3e37a5143721b50b Author: Masoud Sharbiani Date: Fri Sep 20 15:59:07 2013 -0700 x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream. Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time. Signed-off-by: Masoud Sharbiani Signed-off-by: Vinson Lee Cc: Robin Holt Cc: Russell King Cc: Guan Xuetao Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 30d0e7953b17462b8e42ad374ace70c76e31d410 Author: Kent Overstreet Date: Mon Sep 23 23:17:36 2013 -0700 bcache: Fix flushes in writeback mode commit c0f04d88e46d14de51f4baebb6efafb7d59e9f96 upstream. In writeback mode, when we get a cache flush we need to make sure we issue a flush to the backing device. The code for sending down an extra flush was wrong - by cloning the bio we were probably getting flags that didn't make sense for a bare flush, and also the old code was firing for FUA bios, for which we don't need to send a flush to the backing device. This was causing data corruption somehow - the mechanism was never determined, but this patch fixes it for the users that were seeing it. Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit df8b0d944cae63df86dba0edaa8fa8f5efaa7e03 Author: Kent Overstreet Date: Mon Sep 23 23:17:35 2013 -0700 bcache: Fix for handling overlapping extents when reading in a btree node commit 84786438ed17978d72eeced580ab757e4da8830b upstream. btree_sort_fixup() was overly clever, because it was trying to avoid pulling a key off the btree iterator in more than one place. This led to a really obscure bug where we'd break early from the loop in btree_sort_fixup() if the current key overlapped with keys in more than one older set, and the next key it overlapped with was zero size. Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7866bece346caecd88c53c6603e178ce4ebda87b Author: Kent Overstreet Date: Mon Sep 23 23:17:34 2013 -0700 bcache: Fix a shrinker deadlock commit a698e08c82dfb9771e0bac12c7337c706d729b6d upstream. GFP_NOIO means we could be getting called recursively - mca_alloc() -> mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then. Whoops. Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ff1a51b9bf5808f2d40b8e605ff7f7cdc7973b3e Author: Kent Overstreet Date: Mon Sep 23 23:17:33 2013 -0700 bcache: Fix a dumb CPU spinning bug in writeback commit 79e3dab90d9f826ceca67c7890e048ac9169de49 upstream. schedule_timeout() != schedule_timeout_uninterruptible() Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 77dbabefd61a7db6dad630d59823dd610ac6692d Author: Kent Overstreet Date: Mon Sep 23 23:17:32 2013 -0700 bcache: Fix a flush/fua performance bug commit 1394d6761b6e9e15ee7c632a6d48791188727b40 upstream. bch_journal_meta() was missing the flush to make the journal write actually go down (instead of waiting up to journal_delay_ms)... Whoops Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 48c4100e10b75152098675d534d8a6109b28f1bf Author: Kent Overstreet Date: Mon Sep 23 23:17:31 2013 -0700 bcache: Fix a writeback performance regression commit c2a4f3183a1248f615a695fbd8905da55ad11bba upstream. Background writeback works by scanning the btree for dirty data and adding those keys into a fixed size buffer, then for each dirty key in the keybuf writing it to the backing device. When read_dirty() finishes and it's time to scan for more dirty data, we need to wait for the outstanding writeback IO to finish - they still take up slots in the keybuf (so that foreground writes can check for them to avoid races) - without that wait, we'll continually rescan when we'll be able to add at most a key or two to the keybuf, and that takes locks that starves foreground IO. Doh. Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 808eea9d2912e4a3fb8cd45e3e3da94d114757fb Author: Kent Overstreet Date: Mon Sep 23 23:17:29 2013 -0700 bcache: Fix for when no journal entries are found commit c426c4fd46f709ade2bddd51c5738729c7ae1db5 upstream. The journal replay code didn't handle this case, causing it to go into an infinite loop... Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bb343115253500dcee63ea78d765e4c2f2a57fc4 Author: Gabriel de Perthuis Date: Mon Sep 23 23:17:28 2013 -0700 bcache: Strip endline when writing the label through sysfs commit aee6f1cfff3ce240eb4b43b41ca466b907acbd2e upstream. sysfs attributes with unusual characters have crappy failure modes in Squeeze (udev 164); later versions of udev are unaffected. This should make these characters more unusual. Signed-off-by: Gabriel de Perthuis Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0a22f485eee6ae8da77c3e37c8856e025678cdb0 Author: Kent Overstreet Date: Mon Sep 23 23:17:27 2013 -0700 bcache: Fix a dumb journal discard bug commit 6d9d21e35fbfa2934339e96934f862d118abac23 upstream. That switch statement was obviously wrong, leading to some sort of weird spinning on rare occasion with discards enabled... Signed-off-by: Kent Overstreet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d8a1cf0bdbf668951b3ad4dfea4cde19c3fbe432 Author: Lubomir Rintel Date: Wed Sep 18 12:39:16 2013 +0200 sysv: Add forgotten superblock lock init for v7 fs commit 49475555848d396a0c78fb2f8ecceb3f3f263ef1 upstream. Superblock lock was replaced with (un)lock_super() removal, but left uninitialized for Seventh Edition UNIX filesystem in the following commit (3.7): c07cb01 sysv: drop lock/unlock super Signed-off-by: Lubomir Rintel Signed-off-by: Christoph Hellwig Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 9204e9dd40ce207074419e60f66922ce47bb1b79 Author: Kent Overstreet Date: Mon Sep 23 23:17:26 2013 -0700 block: Fix bio_copy_data() commit 2f6cf0de0281d210061ce976f2d42d246adc75bb upstream. The memcpy() in bio_copy_data() was using the wrong offset vars, leading to data corruption in weird unusual setups. Signed-off-by: Kent Overstreet Cc: Jens Axboe Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman