commit 4b73febd1ba302268aabe370de25601eaa884b25 Author: Greg Kroah-Hartman Date: Thu Jun 13 10:52:08 2013 -0700 Linux 3.9.6 commit e3a5271b41ebe36c06943c948b1eb8d0c6da30d5 Author: Ben Hutchings Date: Sun Jun 9 21:09:24 2013 +0100 s390: Add pgste to ptep_modify_prot_start() Commit 52f36be0f4e2 's390/pgtable: Fix check for pgste/storage key handling', which was commit b56433cb782d upstream, added a use of pgste to ptep_modify_prot_start(), but this variable does not exist. In mainline, pgste was added by commit d3383632d4e8 's390/mm: add pte invalidation notifier for kvm' and initialised to the return value of pgste_get_lock(ptep). Initialise it similarly here. Compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 054b50539d3dac99c5454e612e541c1f351a38b1 Author: Zoran Markovic Date: Fri May 17 11:24:05 2013 -0700 timekeeping: Correct run-time detection of persistent_clock. commit 0d6bd9953f739dad96d9a0de65383e479ab4e10d upstream. Since commit 31ade30692dc9680bfc95700d794818fa3f754ac, timekeeping_init() checks for presence of persistent clock by attempting to read a non-zero time value. This is an issue on platforms where persistent_clock (instead is implemented as a free-running counter (instead of an RTC) starting from zero on each boot and running during suspend. Examples are some ARM platforms (e.g. PandaBoard). An attempt to read such a clock during timekeeping_init() may return zero value and falsely declare persistent clock as missing. Additionally, in the above case suspend times may be accounted twice (once from timekeeping_resume() and once from rtc_resume()), resulting in a gradual drift of system time. This patch does a run-time correction of the issue by doing the same check during timekeeping_suspend(). A better long-term solution would have to return error when trying to read non-existing clock and zero when trying to read an uninitialized clock, but that would require changing all persistent_clock implementations. This patch addresses the immediate breakage, for now. Signed-off-by: Zoran Markovic Cc: John Stultz Cc: Thomas Gleixner Cc: Feng Tang [jstultz: Tweaked commit message and subject] Signed-off-by: John Stultz [zoran.markovic@linaro.org: reworked patch to fit 3.9-stable.] Signed-off-by: Zoran Markovic Signed-off-by: Greg Kroah-Hartman commit daa61456b3c3764704fe7f5ae616d6d02bdbaeef Author: Konrad Rzeszutek Wilk Date: Mon Jun 3 10:33:55 2013 -0400 xen/smp: Fixup NOHZ per cpu data when onlining an offline CPU. commit 466318a87f28cb3ba0d08a3b7ef1a37ae73d5aa7 upstream. The xen_play_dead is an undead function. When the vCPU is told to offline it ends up calling xen_play_dead wherin it calls the VCPUOP_down hypercall which offlines the vCPU. However, when the vCPU is onlined back, it resumes execution right after VCPUOP_down hypercall. That was OK (albeit the API for play_dead assumes that the CPU stays dead and never returns) but with commit 4b0c0f294 (tick: Cleanup NOHZ per cpu data on cpu down) that is no longer safe as said commit resets the ts->inidle which at the start of the cpu_idle loop was set. The net effect is that we get this warn: Broke affinity for irq 16 installing Xen timer for CPU 1 cpu 1 spinlock event irq 48 ------------[ cut here ]------------ WARNING: at /home/konrad/linux-linus/kernel/time/tick-sched.c:935 tick_nohz_idle_exit+0x195/0x1b0() Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.0-rc3upstream-00068-gdcdbe33 #1 Hardware name: BIOSTAR Group N61PB-M2S/N61PB-M2S, BIOS 6.00 PG 09/03/2009 ffffffff8193b448 ffff880039da5e60 ffffffff816707c8 ffff880039da5ea0 ffffffff8108ce8b ffff880039da4010 ffff88003fa8e500 ffff880039da4010 0000000000000001 ffff880039da4000 ffff880039da4010 ffff880039da5eb0 Call Trace: [] dump_stack+0x19/0x1b [] warn_slowpath_common+0x6b/0xa0 [] warn_slowpath_null+0x15/0x20 [] tick_nohz_idle_exit+0x195/0x1b0 [] cpu_startup_entry+0x205/0x250 [] cpu_bringup_and_idle+0x13/0x15 ---[ end trace 915c8c486004dda1 ]--- b/c ts_inidle is set to zero. Thomas suggested that we just add a workaround to call tick_nohz_idle_enter before returning from xen_play_dead() - and that is what this patch does and fixes the issue. We also add the stable part b/c git commit 4b0c0f294 is on the stable tree. Suggested-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Konrad Rzeszutek Wilk commit b30e8707b6a155d746aae308f5f3b4dee1e10e28 Author: Ben Greear Date: Thu Jun 6 14:29:49 2013 -0700 Fix lockup related to stop_machine being stuck in __do_softirq. commit 34376a50fb1fa095b9d0636fa41ed2e73125f214 upstream. The stop machine logic can lock up if all but one of the migration threads make it through the disable-irq step and the one remaining thread gets stuck in __do_softirq. The reason __do_softirq can hang is that it has a bail-out based on jiffies timeout, but in the lockup case, jiffies itself is not incremented. To work around this, re-add the max_restart counter in __do_irq and stop processing irqs after 10 restarts. Thanks to Tejun Heo and Rusty Russell and others for helping me track this down. This was introduced in 3.9 by commit c10d73671ad3 ("softirq: reduce latencies"). It may be worth looking into ath9k to see if it has issues with its irq handler at a later date. The hang stack traces look something like this: ------------[ cut here ]------------ WARNING: at kernel/watchdog.c:245 watchdog_overflow_callback+0x9c/0xa7() Watchdog detected hard LOCKUP on cpu 2 Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc] Pid: 23, comm: migration/2 Tainted: G C 3.9.4+ #11 Call Trace: warn_slowpath_common+0x85/0x9f warn_slowpath_fmt+0x46/0x48 watchdog_overflow_callback+0x9c/0xa7 __perf_event_overflow+0x137/0x1cb perf_event_overflow+0x14/0x16 intel_pmu_handle_irq+0x2dc/0x359 perf_event_nmi_handler+0x19/0x1b nmi_handle+0x7f/0xc2 do_nmi+0xbc/0x304 end_repeat_nmi+0x1e/0x2e <> cpu_stopper_thread+0xae/0x162 smpboot_thread_fn+0x258/0x260 kthread+0xc7/0xcf ret_from_fork+0x7c/0xb0 ---[ end trace 4947dfa9b0a4cec3 ]--- BUG: soft lockup - CPU#1 stuck for 22s! [migration/1:17] Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc] irq event stamp: 835637905 hardirqs last enabled at (835637904): __do_softirq+0x9f/0x257 hardirqs last disabled at (835637905): apic_timer_interrupt+0x6d/0x80 softirqs last enabled at (5654720): __do_softirq+0x1ff/0x257 softirqs last disabled at (5654725): irq_exit+0x5f/0xbb CPU 1 Pid: 17, comm: migration/1 Tainted: G WC 3.9.4+ #11 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M. RIP: tasklet_hi_action+0xf0/0xf0 Process migration/1 Call Trace: __do_softirq+0x117/0x257 irq_exit+0x5f/0xbb smp_apic_timer_interrupt+0x8a/0x98 apic_timer_interrupt+0x72/0x80 printk+0x4d/0x4f stop_machine_cpu_stop+0x22c/0x274 cpu_stopper_thread+0xae/0x162 smpboot_thread_fn+0x258/0x260 kthread+0xc7/0xcf ret_from_fork+0x7c/0xb0 Signed-off-by: Ben Greear Acked-by: Tejun Heo Acked-by: Pekka Riikonen Cc: Eric Dumazet Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0cbb8c818c051fc5a9aaa8327954e901f6b8a745 Author: Johan Hovold Date: Sun May 5 20:32:31 2013 +0200 USB: io_ti: fix chars_in_buffer overhead commit b16634adce951a7371be931487034f7365971ed0 upstream. Use the new generic usb-serial wait_until_sent implementation to wait for hardware buffers to drain. This removes the need to check the hardware buffers in chars_in_buffer and thus removes the overhead introduced by commit 263e1f9f ("USB: io_ti: query hardware-buffer status in chars_in_buffer") without breaking tty_wait_until_sent (used by, for example, tcdrain, tcsendbreak and close). Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 487bc65d5a0bba6dbc8f07c46734c90b500e4b64 Author: Johan Hovold Date: Sun May 5 20:32:30 2013 +0200 USB: ftdi_sio: fix chars_in_buffer overhead commit a37025b5c702aaf87191cd75fcc42c54454f16f5 upstream. Use the new generic usb-serial wait_until_sent implementation to wait for hardware buffers to drain. This removes the need to check the hardware buffers in chars_in_buffer and thus removes the overhead introduced by commit 6f602912 ("usb: serial: ftdi_sio: Add missing chars_in_buffer function") without breaking tty_wait_until_sent (used by, for example, tcdrain, tcsendbreak and close). Reported-by: Stas Sergeev Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2ee6eba44c93469e890498c46a1fb6a3b8ccfcc4 Author: Johan Hovold Date: Sun May 5 20:32:29 2013 +0200 USB: ftdi_sio: clean up get_modem_status commit c4133648bbce9e6b425a74cc890c8e4df51acaa9 upstream. Use usb-serial port rather than tty as argument to get_modem_status. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9e8b683555a45f4cc290c1ec7dc8ab059d8d111b Author: Johan Hovold Date: Wed May 8 17:51:43 2013 +0200 USB: serial: add generic wait_until_sent implementation commit dcf0105039660e951dfea348d317043d17988dfc upstream. Add generic wait_until_sent implementation which polls for empty hardware buffers using the new port-operation tx_empty. The generic implementation will be used for all sub-drivers that implement tx_empty but does not define wait_until_sent. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4d316eebd86e7745029e90a40311697a64c0f52c Author: Johan Hovold Date: Sun May 5 20:32:27 2013 +0200 USB: serial: add wait_until_sent operation commit 0693196fe7bbb5e6cafd255dfce91ff6d10bc18f upstream. Add wait_until_sent operation which can be used to wait for hardware buffers to drain. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 7ca18671cfdc3bac1212245b28cf3816d1dba74a Author: Imre Deak Date: Fri May 3 19:44:07 2013 +0200 drm/i915: force full modeset if the connector is in DPMS OFF mode commit e3de42b68478a8c95dd27520e9adead2af9477a5 upstream. Currently the driver's assumed behavior for a modeset with an attached FB is that the corresponding connector will be switched to DPMS ON mode if it happened to be in DPMS OFF (or another power save mode). This wasn't enforced though if only the FB changed, everything else (format, connector etc.) remaining the same. In this case we only set the new FB base and left the connector in the old power save mode. Fix this by forcing a full modeset whenever there is an attached FB and any affected connector is in a power save mode. V_2: Run the test for encoders in power save mode outside the the test for fb change: user space may have just disabled the encoders but left everything else in place. Make sure the connector list is not empty before running this test. Signed-off-by: Imre Deak Signed-off-by: Egbert Eich Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61642 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59834 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64178 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65559 Acked-by: Jesse Barnes [danvet: Apply Jani's s/connector_off/is_crtc_connector_off bikeshed.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1c3845c24c2cb1f53f0499c89947c455b2e31d83 Author: Michael Hennerich Date: Mon Jun 3 14:30:00 2013 +0100 iio: frequency: ad4350: Fix bug / typo in mask commit 2eb3a81eef0510511a3211bb3da560f446a8c8de upstream. Signed-off-by: Michael Hennerich Reviewed-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 10d3af905f9d3b0a93c70adc83c3dcf66690e6bb Author: Michael Hennerich Date: Mon Jun 3 09:04:00 2013 +0100 iio:inkern: Fix typo/bug in convert raw to processed. commit 6c5d4c96f979611f0165dc825af9e1cea8dd35b9 upstream. Signed-off-by: Michael Hennerich Signed-off-by: Jonathan Cameron Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 5435bb9911ca86e32a991b79e294472b82b37f0c Author: Kleber Sacilotto de Souza Date: Fri May 3 19:43:13 2013 -0300 radeon: use max_bus_speed to activate gen2 speeds commit 7e0e41963740525af702bb23edede8ae9afc4ac0 upstream. radeon currently uses a drm function to get the speed capabilities for the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard method of performing this detection and this patch changes it to use the max_bus_speed attribute. From: Lucas Kannebley Tavares Signed-off-by: Kleber Sacilotto de Souza Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c746f441666c4ad27800d5c3c8799c6135818071 Author: Kleber Sacilotto de Souza Date: Fri May 3 12:43:12 2013 +0000 powerpc/pseries: Perform proper max_bus_speed detection commit d82fb31abc46620b7c22758c75707069f2763646 upstream. On pseries machines the detection for max_bus_speed should be done through an OpenFirmware property. This patch adds a function to perform this detection and a hook to perform dynamic adding of the function only for pseries. This is done by overwriting the weak pcibios_root_bridge_prepare function which is called by pci_create_root_bus(). From: Lucas Kannebley Tavares Signed-off-by: Kleber Sacilotto de Souza Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 63a157c381354ba92145b5636c46475356921a6b Author: Brian King Date: Wed May 22 11:07:46 2013 +0000 powerpc/pseries: Make 32-bit MSI quirk work on systems lacking firmware support commit f1dd153121dcb872ae6cba8d52bec97519eb7d97 upstream. Recent commit e61133dda480062d221f09e4fc18f66763f8ecd0 added support for a new firmware feature to force an adapter to use 32 bit MSIs. However, this firmware is not available for all systems. The hack below allows devices needing 32 bit MSIs to work on these systems as well. It is careful to only enable this on Gen2 slots, which should limit this to configurations where this hack is needed and tested to work. [Small change to factor out the hack into a separate function -- BenH] Signed-off-by: Brian King Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kleber Sacilotto de Souza Signed-off-by: Greg Kroah-Hartman commit 12b29dc333b467aba67c6b1c16334e4859f517fb Author: Brian King Date: Fri May 3 11:30:59 2013 +0000 powerpc/pseries: Force 32 bit MSIs for devices that require it commit e61133dda480062d221f09e4fc18f66763f8ecd0 upstream. The following patch implements a new PAPR change which allows the OS to force the use of 32 bit MSIs, regardless of what the PCI capabilities indicate. This is required for some devices that advertise support for 64 bit MSIs but don't actually support them. Signed-off-by: Brian King Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kleber Sacilotto de Souza Signed-off-by: Greg Kroah-Hartman commit cf4056e3892e51ee4e38dcb7967767a7fa2e2557 Author: Brian King Date: Mon Apr 8 03:05:10 2013 +0000 powerpc: Set default VGA device commit c2e1d84523ad2a19e5be08c1f01999cc9e82652e upstream. Add a PCI quirk for VGA devices on Power to set the default VGA device. Ensures a default VGA is always set if a graphics adapter is present, even if firmware did not initialize it. If more than one graphics adapter is present, ensure the one initialized by firmware is set as the default VGA device. This ensures that X autoconfiguration will work. Signed-off-by: Brian King Signed-off-by: Michael Ellerman Signed-off-by: Kleber Sacilotto de Souza Signed-off-by: Greg Kroah-Hartman commit 4d0a4d4a9a3d6fc4d998c459d24202e657d0406f Author: Brian King Date: Mon Apr 8 03:05:07 2013 +0000 pci: Set dev->dev.type in alloc_pci_dev commit 88e7b167a079f090405ab4390b629b5effdab41a upstream. Set dev->dev.type in alloc_pci_dev so that archs that have their own versions of pci_setup_device get this set properly in order to ensure things like the boot_vga sysfs parameter get created as expected. Signed-off-by: Brian King Acked-by: Bjorn Helgaas Signed-off-by: Michael Ellerman Signed-off-by: Kleber Sacilotto de Souza Signed-off-by: Greg Kroah-Hartman commit 213546495109a31ff87386628325a1ff254c656e Author: Patrik Jakobsson Date: Thu Apr 25 22:23:36 2013 +0200 drm/gma500: Increase max resolution for mode setting commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream. By having a higher max resolution we can now set up a virtual framebuffer that spans several monitors. 4096 should be ok since we're gen 3 or higher and should be enough for most dual head setups. Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-modesetting/+bug/1169147 Signed-off-by: Patrik Jakobsson Signed-off-by: Greg Kroah-Hartman commit 48691720be2d219ad2c14580ba5f1d974ad15d8c Author: George Cherian Date: Mon May 27 14:35:49 2013 +0530 usb: dwc3: gadget: free trb pool only from epnum 2 commit 5bf8fae33d14cc5c3c53a926f9079f92c8b082b0 upstream. we never allocate a TRB pool for physical endpoints 0 and 1 so trying to free it (a invalid TRB pool pointer) will lead us in a warning while removing dwc3.ko module. In order to fix the situation, all we have to do is skip dwc3_free_trb_pool() for physical endpoints 0 and 1 just as we while deleting endpoints from the endpoints list. Signed-off-by: George Cherian Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c67d06ef087d1dccbe85470c490eccfd6184fcbc Author: Guenter Roeck Date: Sat Jun 8 07:23:47 2013 -0700 powerpc: Fix build error in stable/3.9 Commit e71c42189 (powerpc/tm: Abort on emulation and alignment faults) introduced a powerpc build error in 3.9.5. Signed-off-by: Guenter Roeck Acked-by: Michael Neuling Signed-off-by: Greg Kroah-Hartman commit 3e9ef737770227e1f7c01851d239a3db10263bbb Author: Rafael J. Wysocki Date: Sat Jun 8 02:55:07 2013 +0200 Revert "ACPI / scan: do not match drivers against objects having scan handlers" commit ea7f665612fcc73da6b7698f468cd5fc03a30d47 upstream. Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects having scan handlers") introduced a boot regression on Tony's ia64 HP rx2600. Tony says: "It panics with the message: Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel [...] my problem comes from arch/ia64/hp/common/sba_iommu.c where the code in sba_init() says: acpi_bus_register_driver(&acpi_sba_ioc_driver); if (!ioc_list) { but because of this change we never managed to call ioc_init() so ioc_list doesn't get set up, and we die." Revert it to avoid this breakage and we'll fix the problem it attempted to address later. Reported-by: Tony Luck Signed-off-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c7ac79de28de4a4c6a2e903ff097c4bfed98e816 Author: Daniel Vetter Date: Fri May 24 21:29:32 2013 +0200 drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus commit 7abb690a0e095717420ba78dcab4309abbbec78a upstream. Chris Wilson noticed that since commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9] Author: Daniel Vetter Date: Thu Nov 15 17:17:22 2012 +0100 drm/i915: clear up wedged transitions X can again get -EIO when it does not expect it. And even worse score a SIGBUS when accessing gtt mmaps. The established ABI is that we _only_ return an -EIO from execbuf - all other ioctls should just work. And since the reset code moves all bos out of gpu domains and clears out all the last_seqno/ring tracking there really shouldn't be any reason for non-execbuf code to ever touch the hw and see an -EIO. After some extensive discussions we've noticed that these spurios -EIO are caused by i915_gem_wait_for_error: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html That is easy to fix by returning 0 instead of -EIO, since grabbing the dev->struct_mutex does not yet mean that we actually want to touch the hw. And so there is no reason at all to fail with -EIO. But that's not the entire since, since often (at least it's easily googleable) dmesg indicates that the reset fails and we declare the gpu wedged. Then, quite a bit later X wakes up with the "Timed out waiting for the gpu reset to complete" DRM_ERROR message in wait_for_errror and brings down the desktop with an -EIO/SIGBUS. So clearly we're missing a wakeup somewhere, since the gpu reset just doesn't take 10 seconds to complete. And indeed we're do handle the terminally wedged state wrong. Fix this all up. Reviewed-by: Chris Wilson Cc: Daniel Vetter Cc: Damien Lespiau Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 0676316a2f650ffebb3c25bc8486e0322a5b0497 Author: Ben Mesman Date: Tue Apr 16 20:00:28 2013 +0200 drm/i915: no lvds quirk for hp t5740 commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream. Last year, a patch was made for the "HP t5740e Thin Client" (see http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by: Ben Mesman Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit a2d4481fee6acd8ba4b8aaaea1aec876e0d21524 Author: Egbert Eich Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by: Egbert Eich Reviewed-by: Chris Wilson [danvet: Add note about which commit likely introduced this issue.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit d5f4fa2be6b3751b9a206f3ed0362bd2cb195b1d Author: Huacai Chen Date: Tue May 21 06:23:43 2013 +0000 drm: fix a use-after-free when GPU acceleration disabled commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream. When GPU acceleration is disabled, drm_vblank_cleanup() will free the vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. But we found that drm_vblank_post_modeset() may be called after the cleanup, which use vblank_refcount and vblank_inmodeset. And this will cause a kernel panic. Fix this by return immediately if dev->num_crtcs is zero. This is the same thing that drm_vblank_pre_modeset() does. Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): [ 62.628906] [] drm_vblank_post_modeset+0x34/0xb4 [ 62.628906] [] atombios_crtc_dpms+0xb4/0x174 [ 62.628906] [] atombios_crtc_commit+0x18/0x38 [ 62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc [ 62.628906] [] drm_crtc_helper_set_config+0x6d8/0x988 [ 62.628906] [] drm_fb_helper_set_par+0x94/0x104 [ 62.628906] [] fbcon_init+0x424/0x57c [ 62.628906] [] visual_init+0xb8/0x118 [ 62.628906] [] take_over_console+0x238/0x384 [ 62.628906] [] fbcon_takeover+0x7c/0xdc [ 62.628906] [] notifier_call_chain+0x44/0x94 [ 62.628906] [] __blocking_notifier_call_chain+0x48/0x68 [ 62.628906] [] register_framebuffer+0x228/0x260 [ 62.628906] [] drm_fb_helper_single_fb_probe+0x260/0x314 [ 62.628906] [] drm_fb_helper_initial_config+0x200/0x234 [ 62.628906] [] radeon_fbdev_init+0xd4/0xf4 [ 62.628906] [] radeon_modeset_init+0x9bc/0xa18 [ 62.628906] [] radeon_driver_load_kms+0xdc/0x12c [ 62.628906] [] drm_get_pci_dev+0x148/0x238 [ 62.628906] [] local_pci_probe+0x5c/0xd0 [ 62.628906] [] work_for_cpu_fn+0x1c/0x30 [ 62.628906] [] process_one_work+0x274/0x3bc [ 62.628906] [] process_scheduled_works+0x24/0x44 [ 62.628906] [] worker_thread+0x31c/0x3f4 [ 62.628906] [] kthread+0x88/0x90 [ 62.628906] [] kernel_thread_helper+0x10/0x18 Signed-off-by: Huacai Chen Signed-off-by: Binbin Zhou Reviewed-by: Michel Dänzer Acked-by: Paul Menzel Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0880a5673614de562db73bb5e128e7155671bf65 Author: Christopher Harvey Date: Fri May 31 20:33:07 2013 +0000 drm/mgag200: Add missing write to index before accessing data register commit 91f8f105f2b82b4a38dee2d74760bc39d40ec42c upstream. This is a bug fix for some versions of g200se cards while doing mode-setting. Signed-off-by: Christopher Harvey Tested-by: Julia Lemire Acked-by: Julia Lemire Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 291c6021c3dd2f9575c5a480a9868f05b9f37b07 Author: Guenter Roeck Date: Wed Jun 5 14:09:30 2013 -0700 hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617 commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream. On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected as LM84. Strengthen detection sufficiently enough to avoid this misdetection. Also improve detection for ADM1021. Modeled after chip detection code in sensors-detect command. Signed-off-by: Guenter Roeck Tested-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 4dbfc6cccf119acb59d9cf8853a78890c81e21c5 Author: Tyler Hicks Date: Tue Jun 4 10:24:56 2013 -0700 eCryptfs: Check return of filemap_write_and_wait during fsync commit bc5abcf7e411b889f73ea2a90439071a0f451011 upstream. Error out of ecryptfs_fsync() if filemap_write_and_wait() fails. Signed-off-by: Tyler Hicks Cc: Paul Taysom Cc: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit ef6190a2ac96fa2156c5e1423d1ea84a1cdf1bda Author: Paul Taysom Date: Thu May 23 14:31:43 2013 -0700 ecryptfs: fixed msync to flush data commit c15cddd900e867c5adfb3c79596479dc5975f743 upstream. When msync is called on a memory mapped file, that data is not flushed to the disk. In Linux, msync calls fsync for the file. For ecryptfs, fsync just calls the lower level file system's fsync. Changed the ecryptfs fsync code to call filemap_write_and_wait before calling the lower level fsync. Addresses the problem described in http://crbug.com/239536 Signed-off-by: Paul Taysom Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit cd73e0b96b03189cbd4881b6176d841d700a4485 Author: Jeff Layton Date: Fri May 31 10:00:18 2013 -0400 cifs: fix off-by-one bug in build_unc_path_to_root commit 1fc29bacedeabb278080e31bb9c1ecb49f143c3b upstream. commit 839db3d10a (cifs: fix up handling of prefixpath= option) changed the code such that the vol->prepath no longer contained a leading delimiter and then fixed up the places that accessed that field to account for that change. One spot in build_unc_path_to_root was missed however. When doing the pointer addition on pos, that patch failed to account for the fact that we had already incremented "pos" by one when adding the length of the prepath. This caused a buffer overrun by one byte. This patch fixes the problem by correcting the handling of "pos". Reported-by: Marcus Moeller Reported-by: Ken Fallon Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a4f30a305648eefad969c2653513ddb83786ce31 Author: Mikulas Patocka Date: Sun Jun 9 01:25:57 2013 +0200 hpfs: fix warnings when the filesystem fills up commit bbd465df73f0d8ba41b8a0732766a243d0f5b356 upstream. This patch fixes warnings due to missing lock on write error path. WARNING: at fs/hpfs/hpfs_fn.h:353 hpfs_truncate+0x75/0x80 [hpfs]() Hardware name: empty Pid: 26563, comm: dd Tainted: P O 3.9.4 #12 Call Trace: hpfs_truncate+0x75/0x80 [hpfs] hpfs_write_begin+0x84/0x90 [hpfs] _hpfs_bmap+0x10/0x10 [hpfs] generic_file_buffered_write+0x121/0x2c0 __generic_file_aio_write+0x1c7/0x3f0 generic_file_aio_write+0x7c/0x100 do_sync_write+0x98/0xd0 hpfs_file_write+0xd/0x50 [hpfs] vfs_write+0xa2/0x160 sys_write+0x51/0xa0 page_fault+0x22/0x30 system_call_fastpath+0x1a/0x1f Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ffd0edf882b5719520d98ea951671784649c47a2 Author: Alex Deucher Date: Mon Jun 3 10:32:40 2013 -0400 drm/radeon: don't allow audio on DCE6 commit 1cbcca302a318499f20a512847c5d6a510c08c35 upstream. It's not supported yet. Fixes display issues when users force it on. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e335ccae2ae4caef26a1e81711c44aec1cc83bd2 Author: Adis Hamzić Date: Sun Jun 2 16:47:54 2013 +0200 radeon: Fix system hang issue when using KMS with older cards commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream. The current radeon driver initialization routines, when using KMS, are written so that the IRQ installation routine is called before initializing the WB buffer and the CP rings. With some ASICs, though, the IRQ routine tries to access the GFX_INDEX ring causing a call to RREG32 with the value of -1 in radeon_fence_read. This, in turn causes the system to completely hang with some cards, requiring a hard reset. A call stack that can cause such a hang looks like this (using rv515 ASIC for the example here): * rv515_init (rv515.c) * radeon_irq_kms_init (radeon_irq_kms.c) * drm_irq_install (drm_irq.c) * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c) * rs600_irq_process (rs600.c) * radeon_fence_process - due to SW interrupt (radeon_fence.c) * radeon_fence_read (radeon_fence.c) * hang due to RREG32(-1) The patch moves the IRQ installation to the card startup routine, after the ring has been initialized, but before the IRQ has been set. This fixes the issue, but requires a check to see if the IRQ is already installed, as is the case in the system resume codepath. I have tested the patch on three machines using the rv515, the rv770 and the evergreen ASIC. They worked without issues. This seems to be a known issue and has been reported on several bug tracking sites by various distributions (see links below). Most of reports recommend booting the system with KMS disabled and then enabling KMS by reloading the radeon module. For some reason, this was indeed a usable workaround, however, UMS is now deprecated and disabled by default. Bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=845745 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789 https://bbs.archlinux.org/viewtopic.php?id=156964 Signed-off-by: Adis Hamzić Signed-off-by: Alex Deucher commit 3e4d1280a94d81a1ed6110d44daa83d9a9cdcdec Author: Rabin Vincent Date: Mon May 27 16:03:40 2013 +0200 dmaengine: ste_dma40: fix pm runtime ref counting commit 9ecb41bd8cf002fd8f3e063db4df81647ddd623c upstream. The pm runtime reference counting of the driver is broken for the case when there is more than one transfer queued, leading to the device being runtime suspend while active. Fix it. Signed-off-by: Rabin Vincent Acked-by: Linus Walleij Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 878aac71d99971e7b79361b173f3ad14d3abf02b Author: Michael Ellerman Date: Wed Jun 5 17:58:20 2013 +0000 powerpc/perf: Fix deadlock caused by calling printk() in PMU exception commit 6772faa1ba22eba18d087c2459030a683b65be57 upstream. In commit bc09c21 "Fix finding overflowed PMC in interrupt" we added a printk() to the PMU exception handler. Unfortunately that is not safe. The problem is that the PMU exception may run even when interrupts are soft disabled, aka NMI context. We do this so that we can profile parts of the kernel that have interrupts soft-disabled. But by calling printk() from the exception handler, we can potentially deadlock in the printk code on logbuf_lock, eg: [c00000038ba575c0] c000000000081928 .vprintk_emit+0xa8/0x540 [c00000038ba576a0] c0000000007bcde8 .printk+0x48/0x58 [c00000038ba57710] c000000000076504 .perf_event_interrupt+0x2d4/0x490 [c00000038ba57810] c00000000001f6f8 .performance_monitor_exception+0x48/0x60 [c00000038ba57880] c0000000000032cc performance_monitor_common+0x14c/0x180 --- Exception: f01 (Performance Monitor) at c0000000007b25d4 ._raw_spin_lock_irq +0x64/0xc0 [c00000038ba57bf0] c00000000007ed90 .devkmsg_read+0xd0/0x5a0 [c00000038ba57d00] c0000000001c2934 .vfs_read+0xc4/0x1e0 [c00000038ba57d90] c0000000001c2cd8 .SyS_read+0x58/0xd0 [c00000038ba57e30] c000000000009d54 syscall_exit+0x0/0x98 --- Exception: c01 (System Call) at 00001fffffbf6f7c SP (3ffff6d4de10) is in userspace Fix it by making sure we only call printk() when we are not in NMI context. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 9dc9f5e35b518c61ddff7226ee7de09b841831ff Author: Michael Neuling Date: Thu May 16 20:27:31 2013 +0000 powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression commit 82a9f16adc12f51c3f8ea59a7c3c120241aff836 upstream. When introducing support for DABRX in 4474ef0, we broke older 32-bit CPUs that don't have that register. Some CPUs have a DABR but not DABRX. Configuration are: - No 32bit CPUs have DABRX but some have DABR. - POWER4+ and below have the DABR but no DABRX. - 970 and POWER5 and above have DABR and DABRX. - POWER8 has DAWR, hence no DABRX. This introduces CPU_FTR_DABRX and sets it on appropriate CPUs. We use the top 64 bits for CPU FTR bits since only 64 bit CPUs have this. Processors that don't have the DABRX will still work as they will fall back to software filtering these breakpoints via perf_exclude_event(). Signed-off-by: Michael Neuling Reported-by: "Gorelik, Jacob (335F)" Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 4492133d2e4fb329afe900e9cd18560a0dfbd7d7 Author: Gavin Shan Date: Wed Jun 5 14:25:50 2013 +0000 powerpc/eeh: Don't check RTAS token to get PE addr commit b8b3de224f194005ad87ede6fd022fcc2bef3b1a upstream. RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2" are used to retrieve the PE address according to PCI address, which made up of domain/bus/slot/function. If we don't have those 2 tokens, the domain/bus/slot/function would be used as the address for EEH RTAS operations. Some older f/w might not have those 2 tokens and that blocks the EEH functionality to be initialized. It was introduced by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization"). The patch skips the check on those 2 tokens so we can bring up EEH functionality successfully. And domain/bus/slot/function will be used as address for EEH RTAS operations. Reported-by: Robert Knight Signed-off-by: Gavin Shan Tested-by: Robert Knight Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 4722ea98c19c668ad239bbb1598decfadf7c1c93 Author: Will Deacon Date: Wed Jun 5 11:20:33 2013 +0100 ARM: 7747/1: pcpu: ensure __my_cpu_offset cannot be re-ordered across barrier() commit 509eb76ebf9771abc9fe51859382df2571f11447 upstream. __my_cpu_offset is non-volatile, since we want its value to be cached when we access several per-cpu variables in a row with preemption disabled. This means that we rely on preempt_{en,dis}able to hazard with the operation via the barrier() macro, so that we can't end up migrating CPUs without reloading the per-cpu offset. Unfortunately, GCC doesn't treat a "memory" clobber on a non-volatile asm block as a side-effect, and will happily re-order it before other memory clobbers (including those in prempt_disable()) and cache the value. This has been observed to break the cmpxchg logic in the slub allocator, leading to livelock in kmem_cache_alloc in mainline kernels. This patch adds a dummy memory input operand to __my_cpu_offset, forcing it to be ordered with respect to the barrier() macro. Reviewed-by: Nicolas Pitre Cc: Rob Herring Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 9704849d29b041166765e70c07666c5a339fc060 Author: Arnd Bergmann Date: Fri May 31 22:50:47 2013 +0100 ARM: 7743/1: compressed/head.S: work around new binutils warning commit da94a829305f1c217cfdf6771cb1faca0917e3b9 upstream. In August 2012, Matthew Gretton-Dann checked a change into binutils labelled "Error on obsolete & warn on deprecated registers", apparently as part of ARMv8 support. Apparently, this was supposed to emit the message "Warning: This coprocessor register access is deprecated in ARMv8" when using certain mcr/mrc instructions and building for ARMv8. Unfortunately, the message that is actually emitted appears to be '(null)', which is less helpful in comparison. Even more unfortunately, this is biting us on every single kernel build with a new gas, because arch/arm/boot/compressed/head.S and some other files in that directory are built with -march=all since kernel commit 80cec14a8 "[ARM] Add -march=all to assembly file build in arch/arm/boot/compressed" back in v2.6.28. This patch reverts Russell's nice solution and instead marks the head.S file to be built for armv7-a, which fortunately lets us build all instructions in that file without warnings even on the broken binutils. Without this patch, building anything results in: arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:565: Warning: (null) arch/arm/boot/compressed/head.S:676: Warning: (null) arch/arm/boot/compressed/head.S:698: Warning: (null) arch/arm/boot/compressed/head.S:722: Warning: (null) arch/arm/boot/compressed/head.S:726: Warning: (null) arch/arm/boot/compressed/head.S:957: Warning: (null) arch/arm/boot/compressed/head.S:996: Warning: (null) arch/arm/boot/compressed/head.S:997: Warning: (null) arch/arm/boot/compressed/head.S:1027: Warning: (null) arch/arm/boot/compressed/head.S:1035: Warning: (null) arch/arm/boot/compressed/head.S:1046: Warning: (null) arch/arm/boot/compressed/head.S:1060: Warning: (null) arch/arm/boot/compressed/head.S:1092: Warning: (null) arch/arm/boot/compressed/head.S:1094: Warning: (null) arch/arm/boot/compressed/head.S:1095: Warning: (null) arch/arm/boot/compressed/head.S:1102: Warning: (null) arch/arm/boot/compressed/head.S:1134: Warning: (null) Signed-off-by: Arnd Bergmann Cc: Matthew Gretton-Dann Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit a5d8b729453cacc09eaa505fc724bdb429237050 Author: Arnd Bergmann Date: Fri May 31 22:49:22 2013 +0100 ARM: 7742/1: topology: export cpu_topology commit 92bdd3f5eba299b33c2f4407977d6fa2e2a6a0da upstream. The cpu_topology symbol is required by any driver using the topology interfaces, which leads to a couple of build errors: ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined! ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined! ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined! The obvious solution is to export this symbol. Signed-off-by: Arnd Bergmann Acked-by: Will Deacon Cc: Nicolas Pitre Cc: Vincent Guittot Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit c8ab178e5ea57632e83446f3ee127694f24a3096 Author: Andrew Lunn Date: Tue May 21 19:41:48 2013 +0200 ARM: Kirkwood: TS219: Fix crash by double PCIe instantiation commit e89b4058096569c999fa599370162022a5a2b3d2 upstream. When creating the DT based boards-ts219.c the none DT ts219-setup.c was used as a template. This includes a lateinit() call to initialize the PCIe bus. The code makes use of machine_is_ts219() which is never true on DT, so a FIXME was added and the code left as is. This was unproblematic until b73690c8f8b5d: "ARM: Kirkwood: Support basic hotplug for PCI-E" which changes the way the PCIe bus is initialized. The non-DT ts219-setup.c now crashes during boot. The lateinit() call in the DT boards-ts219.c is being called, machine_is_ts219() is true and so the PCIe is initialized a second time. This patch removes the useless, and now clearly dangerous, code from boards-ts219.c, making ts219-setup.c work again. Signed-off-by: Andrew Lunn Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit c602c52d7c10200f2763c1a6bb30e7fd90ccefaa Author: Takashi Iwai Date: Fri May 31 19:55:54 2013 +0200 ALSA: hda - Add keep_eapd_on flag to generic parser commit 05909d5c679cf7c9a8a5bc663677c066a546894f upstream. VT1802 codec seems to reset EAPD of other pins in the hardware level, and this was another reason of the silent headphone output on some machines. As a workaround, introduce a new flag indicating to keep the EPAD on to the generic parser, and set it in patch_via.c. Reported-by: Alex Riesen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f7aa0cafe089a1d965b6b7e33d582182b2c58d69 Author: Takashi Iwai Date: Fri May 31 14:10:03 2013 +0200 ALSA: hda - Allow setting automute/automic hooks after parsing commit 77afe0e94884ae40de29cd813a1fb7ddee583591 upstream. Some codec drivers (VIA codecs and some Realtek fixups) set the automute and automic hooks after calling snd_hda_gen_parse_auto_config(). In the current code, the hook pointers are referred only in snd_hda_gen_parse_auto_config() and passed to snd_hda_jack_detect_enable_callback(), thus changing the hook values won't change the actually called callbacks properly. This patch fixes this bug by setting the static functions as the primary callback functions for the jack detection, and let them calling the appropriate hooks dynamically. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fae0b025aedc23e872458046aada45c857b07373 Author: Takashi Iwai Date: Mon Jun 3 11:17:38 2013 +0200 ALSA: hda/via - Fix wrongly cleared pins after suspend on VT1802 commit 5a6f294e87974e6ec68d7113553ffd975d83bf15 upstream. VIA driver has a special suspend handling only for VT1802 to reduce the pop noise. During the transition to the generic parser, the behavior of snd_hda_set_pin_ctl() was also changed to modify the cached values, too. And this caused a regression where the pin is still cleared even after the resume (including the resume from power save), resulting in the silent output. The fix is simply to replace snd_hda_set_pin_ctl() with the explicit call of snd_hda_codec_write() again. Reported-by: Alex Riesen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ab327c178ec19e28f3b2ac88cf9d352f50d206b1 Author: Takashi Iwai Date: Fri May 31 13:54:10 2013 +0200 ALSA: hda/via - Disable broken dynamic power control commit 087c2e3b4e062573dbbc8a50b9208992e3768dcf upstream. Since the transition to the generic parser, the actual routes used there don't match always with the assumed static paths in some set_widgets_power_state callbacks. This results in the wrong power setup in the end. As a temporary workaround, we need to disable the calls together with the non-functional dynamic power control enum. Reported-by: Alex Riesen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5742034d9fdabffc077b24fa0f0857a0b5e2a2eb Author: lan,Tianyu Date: Tue May 28 02:25:33 2013 +0000 x86 / platform / hp_wmi: Fix bluetooth_rfkill misuse in hp_wmi_rfkill_setup() commit af1d486c18bad7820b0ca52b413458914231102c upstream. HP wmi platform driver fails to initialize GPS and causes poweroff failure in HP Elitebook 6930p. Call Trace: [] hp_wmi_bios_setup+0x25a/0x3a0 [hp_wmi] [] platform_drv_probe+0x3c/0x70 [] ? driver_sysfs_add+0x7a/0xb0 [] driver_probe_device+0x87/0x3a0 [] __driver_attach+0x93/0xa0 [] ? __device_attach+0x40/0x40 [] bus_for_each_dev+0x63/0xa0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1f8/0x2b0 [] driver_register+0x71/0x150 [] platform_driver_register+0x46/0x50 [] platform_driver_probe+0x1b/0xa0 [] hp_wmi_init+0x1be/0x1fb [hp_wmi] [] ? hp_wmi_bios_setup+0x3a0/0x3a0 [hp_wmi] [] do_one_initcall+0x10a/0x160 [] load_module+0x1b46/0x2640 [] ? ddebug_proc_write+0xf0/0xf0 [] sys_init_module+0xa2/0xf0 [] system_call_fastpath+0x1a/0x1f Code: 48 ff ff ff 80 7b 24 00 74 d2 41 83 e5 01 45 38 ec 74 c9 48 8d bb a0 03 00 00 e8 ed fb aa e0 5b 41 5c 41 5d 44 89 f0 41 5e 5d c3 <0f> 0b 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 RIP [] rfkill_set_hw_state+0x9f/0xb0 [rfkill] RSP Check code and find this error is caused by misusing variable bluetooth_rfkill where gps_rfkill should be. Reported-and-tested-by: Iru Cai References: https://bugzilla.kernel.org/show_bug.cgi?id=58401 Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 54921fa89f4fdbcc4f722bf5b5fb7e7579b0d7a8 Author: Rafael J. Wysocki Date: Wed Jun 5 14:01:19 2013 +0200 ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization commit 7cd8407d53ef5fb0280fcbe34f42311472f90feb upstream. Commit b378549 (ACPI / PM: Do not power manage devices in unknown initial states) added code to force devices without _PSC, but having _PS0 defined in the ACPI namespace, into ACPI power state D0 by executing _PS0 for them. That turned out to break Toshiba P870-303, however, so revert that code. References: https://bugzilla.kernel.org/show_bug.cgi?id=58201 Reported-and-tested-by: Jerome Cantenot Tracked-down-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8c25251dbff0e034b4006b347e5d145cb4c718c4 Author: Aaron Lu Date: Tue Jun 4 23:02:58 2013 +0200 ACPI / scan: do not match drivers against objects having scan handlers commit 9f29ab11ddbfc12db54df5a66dab22b39ad94e8e upstream. With the introduction of ACPI scan handlers, an ACPI device object with an ACPI scan handler attached to it must not be bound to an ACPI driver any more. Therefore it doesn't make sense to match those ACPI device objects against a newly registered ACPI driver in acpi_bus_match(), so make that function return 0 if the device object passed to it has an ACPI scan handler attached. This also addresses a regression related to a broken ACPI table in the BIOS, where it has defined a _ROM method under the PCI root bridge object. This causes the video module to treat that object as a display controller device (since only display devices are supposed to have a _ROM method defined according to the ACPI spec). As a result, the ACPI video driver binds to the PCI root bridge object and overwrites the previously assigned driver_data field of it, causing subsequent calls to acpi_get_pci_dev() to fail. [rjw: Subject and changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Reported-by: Jason Cassell Reported-and-bisected-by: Dmitry S. Demin Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2089bfbd513b6e59b61d462eb27e94704b0c2098 Author: Ash Willis Date: Wed May 29 01:27:59 2013 +0000 ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6 commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream. This patch addresses kernel bug 56661. BIOS reports an incorrect backlight value, causing the driver to switch off the backlight completely during startup. This patch ignores the incorrect value from BIOS. References: https://bugzilla.kernel.org/show_bug.cgi?id=56661 Signed-off-by: Ash Willis Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6180b5e1367b5d6eee5ae3cfe0c38270a973464f Author: Alex Hung Date: Tue May 28 02:05:09 2013 +0000 ACPI / video: ignore BIOS initial backlight value for HP m4 commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream. On HP m4 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References: https://bugs.launchpad.net/bugs/1184501 Signed-off-by: Alex Hung Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 34c35be12943c8a69d1ef65e875eab34d19fe53f Author: Ross Lagerwall Date: Fri May 31 20:45:17 2013 +0100 acpi-cpufreq: set current frequency based on target P-State commit 8673b83bf2f013379453b4779047bf3c6ae387e4 upstream. Commit 4b31e774 (Always set P-state on initialization) fixed bug #4634 and caused the driver to always set the target P-State at least once since the initial P-State may not be the desired one. Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur) caused a regression in this behavior. This fixes the regression by setting policy->cur based on the CPU's target frequency rather than the CPU's current reported frequency (which may be different). This means that the P-State will be set initially if the CPU's target frequency is different from the governor's target frequency. This fixes an issue where setting the default governor to performance wouldn't correctly enable turbo mode on all cores. Signed-off-by: Ross Lagerwall Reviewed-by: Len Brown Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit cb733ce8bf69d561a0387d79e370495eabe5b653 Author: Johan Hovold Date: Tue Jun 4 18:50:31 2013 +0200 USB: mos7720: fix hardware flow control commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream. The register access to enable hardware flow control depends on the device port number and not the port minor number. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e694433d4fe4e60f542361d9eefeb50300907819 Author: Johan Hovold Date: Mon May 27 14:44:43 2013 +0200 USB: mos7720: fix message timeouts commit 849513a7809175420d353625b6f651d961e99d49 upstream. The control and bulk-message timeouts are specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ff55159c19d51db7d1ec77512e3763d1ef4755b0 Author: Johan Hovold Date: Mon May 27 14:44:39 2013 +0200 USB: mos7720: fix DMA to stack commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream. The read_mos_reg function is called with stack-allocated buffers, which must not be used for control messages. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1014760f7c4db93f0980e19c9249dd248e0ff2bf Author: Johan Hovold Date: Mon May 27 14:44:40 2013 +0200 USB: mos7840: fix DMA to stack commit 15ee89c3347fbf58a4361011eda5ac2731e45126 upstream. Fix regression introduced by commit 0eafe4de1a ("USB: serial: mos7840: add support for MCS7810 devices") which used stack-allocated buffers for control messages. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8d0504d37c716d8e2f48beb1d7a560074d5f6d9c Author: Alan Stern Date: Tue May 28 14:03:10 2013 -0400 USB: revert periodic scheduling bugfix commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream. This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d (USB: EHCI: fix bug in scheduling periodic split transfers). The commit was valid -- it fixed a real bug -- but the periodic scheduler in ehci-hcd is in such bad shape (especially the part that handles split transactions) that fixing one bug is very likely to cause another to surface. That's what happened in this case; the result was choppy and noisy playback on certain 24-bit audio devices. The only real fix will be to rewrite this entire section of code. My next project... This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110. Thanks to Tim Richardson for extra testing and feedback, and to Joseph Salisbury and Tyson Tan for tracking down the original source of the problem. Signed-off-by: Alan Stern CC: Joseph Salisbury CC: Tim Richardson Signed-off-by: Greg Kroah-Hartman commit 1bf23da920e3c01cdca13aa303f3faa06947dcc2 Author: Johan Hovold Date: Mon May 27 14:44:37 2013 +0200 USB: serial: fix Treo/Kyocera interrrupt-in urb context commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream. The first and second interrupt-in urbs are swapped for some Treo/Kyocera devices, but the urb context was never updated with the new port. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 25f776c98c23b0216fe08940fb32168978263321 Author: Johan Hovold Date: Thu Jun 6 13:32:47 2013 +0200 USB: whiteheat: fix broken port configuration commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream. When configuring the port (e.g. set_termios) the port minor number rather than the port number was used in the request (and they only coincide for minor number 0). Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d0953d9031d26cb9bcfc745b0565febda22b3461 Author: Robert Butora Date: Fri May 31 18:09:51 2013 +0300 USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream. The patch adds a new HIDCOM device and does not affect other devices driven by the cypress_M8 module. Changes are: - add VendorID ProductID to device tables - skip unstable speed check because FRWD uses 115200bps - skip reset at probe which is an issue workaround for this particular device. Signed-off-by: Robert Butora Signed-off-by: Greg Kroah-Hartman commit 4d1e4acd5cb8894813f1adcc15f9c2d4af6b1d71 Author: Johan Hovold Date: Tue Jun 4 18:50:28 2013 +0200 USB: zte_ev: fix broken open commit d8a1d0d54d5fdac0347b75e9afd554b3dfaa465f upstream. Remove bogus port-number check in open and close, which prevented this driver from being used with a minor number different from zero. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5c6ca7460801006a1c3090c95e8d332679a425dd Author: Johan Hovold Date: Mon May 27 14:44:44 2013 +0200 USB: zte_ev: fix control-message timeouts commit 5cbfa3acdcbf19e1d29cf3479ad8200d2e644e44 upstream. The control-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a3e2f56ae5e5e5928f26610ab2b52a9957184fcc Author: Johan Hovold Date: Mon May 27 14:44:38 2013 +0200 USB: visor: fix initialisation of Treo/Kyocera devices commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3 upstream. Fix regression introduced by commit 214916f2e ("USB: visor: reimplement using generic framework") which broke initialisation of Treo/Kyocera devices that re-mapped bulk-in endpoints. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 7905740e043ed517af3496ac7aeea75a5c7f3d91 Author: Johan Hovold Date: Mon May 27 14:44:41 2013 +0200 USB: ark3116: fix control-message timeout commit 634371911730a462626071065b64cd6e1fe213e0 upstream. The control-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 29594cdbe04429fcf23fc66e65be0450e0f46a71 Author: Johan Hovold Date: Tue Jun 4 18:50:29 2013 +0200 USB: keyspan: fix bogus array index commit a07088098a650267b2eda689538133a324b9523f upstream. The outcont_endpoints array was indexed using the port minor number (which can be greater than the array size) rather than the device port number. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e9f291d715e86564d2552ecad27ea99049bac915 Author: Johan Hovold Date: Mon May 27 14:44:42 2013 +0200 USB: iuu_phoenix: fix bulk-message timeout commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7 upstream. The bulk-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4ec2198fa4e2ba98b2fbbc20eb280b9ff389680e Author: Takashi Iwai Date: Wed Jun 5 08:35:26 2013 +0200 ALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270 commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993 upstream. USB audio driver spews an error message when probing Logitech HD webcam c270: ALSA mixer.c:1300 usb_audio: Warning! Unlikely big volume range (=6144), cval->res is probably wrong. ALSA mixer.c:1304 usb_audio: [5] FU [Mic Capture Volume] ch = 1, val = 1536/7680/1 Obviously the device needs a fixed volume resolution (cval->res = 384) like other Logitech devices. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=821735 Reported-and-tested-by: Cristian Rodríguez Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 875b96bae7038ef8ecfd3b0359b93aa5c7bba0f0 Author: Takashi Iwai Date: Tue Jun 4 16:02:54 2013 +0200 ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89 upstream. ... instead of applying to all interfaces. Reference: http://forums.gentoo.org/viewtopic-p-6886404.html Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49a04f31082129872d08214d1b38d13f6df23983 Author: Clemens Ladisch Date: Sun Jun 2 19:49:07 2013 +0200 ALSA: usb-audio: fix Roland/Cakewalk UM-3G support commit a0c6d309c6df14655f9962f666d1da96318b0b7c upstream. Commit 927c9423dd5f2d1c0b93d5e694ab84b4a5559713 (ALSA: usb-audio: add Edirol UM-3G support) used a wrong quirk type, which would make the driver refuse to attach with the error message "MIDIStreaming interface descriptor not found". Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8df8f41280ebdd7203b9767a16c7a794fcc2a0e3 Author: Virupax Sadashivpetimath Date: Wed Apr 24 08:38:48 2013 +0200 usb: musb: make use_sg flag URB specific commit ed74df12dc3e07a37d99aab60211496e871488a0 upstream. Since highmem PIO URB handling was introduced in: 8e8a551 usb: musb: host: Handle highmem in PIO mode when a URB is being handled it may happen that the static use_sg flag was set by a previous URB with buffer in highmem. This leads to error in handling the present URB. Fix this by making the use_sg flag URB specific. Acked-by: Linus Walleij Signed-off-by: Virupax Sadashivpetimath Signed-off-by: Fabio Baltieri Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit f44b32e76bc1b03d3ec6e43ba4c789fb8462a795 Author: Matt Fleming Date: Wed Jun 5 15:15:41 2013 +0100 x86/PCI: Map PCI setup data with ioremap() so it can be in highmem commit 65694c5aaddfedd9da082e4e150cafc6b3fc8a6a upstream. f9a37be0f0 ("x86: Use PCI setup data") added support for using PCI ROM images from setup_data. This used phys_to_virt(), which is not valid for highmem addresses, and can cause a crash when booting a 32-bit kernel via the EFI boot stub. pcibios_add_device() assumes that the physical addresses stored in setup_data are accessible via the direct kernel mapping, and that calling phys_to_virt() is valid. This isn't guaranteed to be true on x86 where the direct mapping range is much smaller than on x86-64. Calling phys_to_virt() on a highmem address results in the following: BUG: unable to handle kernel paging request at 39a3c198 IP: [] pcibios_add_device+0x2f/0x90 ... Call Trace: [] pci_device_add+0xe3/0x130 [] pci_scan_single_device+0x8b/0xb0 [] pci_scan_slot+0x48/0x100 [] pci_scan_child_bus+0x24/0xc0 [] pci_acpi_scan_root+0x2c0/0x490 [] acpi_pci_root_add+0x312/0x42f ... The solution is to use ioremap() instead of phys_to_virt() to map the setup data into the kernel address space. [bhelgaas: changelog] Tested-by: Jani Nikula Signed-off-by: Matt Fleming Signed-off-by: Bjorn Helgaas Cc: Matthew Garrett Cc: Seth Forshee Cc: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit a9b4f1537955bfee22e87f9f049c29aa777d5ec9 Author: Sarah Sharp Date: Thu Apr 18 10:02:03 2013 -0700 xhci: Disable D3cold for buggy TI redrivers. commit c3897aa5386faba77e5bbdf94902a1658d3a5b11 upstream. Some xHCI hosts contain a "redriver" from TI that silently drops port status connect changes if the port slips into Compliance Mode. If the port slips into compliance mode while the host is in D0, there will not be a port status change event. If the port slips into compliance mode while the host is in D3, the host will not send a PME. This includes when the system is suspended (S3) or hibernated (S4). If this happens when the system is in S3/S4, there is nothing software can do. Other port status change events that would normally cause the host to wake the system from S3/S4 may also be lost. This includes remote wakeup, disconnects and connects on other ports, and overrcurrent events. A decision was made to _NOT_ disable system suspend/hibernate on these systems, since users are unlikely to enable wakeup from S3/S4 for the xHCI host. Software can deal with this issue when the system is in S0. A work around was put in to poll the port status registers for Compliance Mode. The xHCI driver will continue to poll the registers while the host is runtime suspended. Unfortunately, that means we can't allow the PCI device to go into D3cold, because power will be removed from the host, and the config space will read as all Fs. Disable D3cold in the xHCI PCI runtime suspend function. This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Sarah Sharp Cc: Huang Ying Signed-off-by: Greg Kroah-Hartman commit f63735d53c3e8d431ab16ed43a0bace88bf24974 Author: Vladimir Murzin Date: Tue Apr 9 22:33:31 2013 +0400 xhci: fix list access before init commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream. If for whatever reason we fall into fail path in xhci_mem_init() before bw table gets initialized we may access the uninitialized lists in xhci_mem_cleanup(). Check for bw table before traversing lists in cleanup routine. This patch should be backported to kernels as old as 3.2, that contain the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store information about roothubs and TTs." Reported-by: Sergey Dyasly Tested-by: Sergey Dyasly Signed-off-by: Vladimir Murzin Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 913ad664b1a1bf048a1b2d2971686862d19b33f4 Author: Sergio Aguirre Date: Thu Apr 4 10:32:13 2013 -0700 xhci-mem: init list heads at the beginning of init commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream. It is possible that we fail on xhci_mem_init, just before doing the INIT_LIST_HEAD, and calling xhci_mem_cleanup. Problem is that, the list_for_each_entry_safe macro, assumes list heads are initialized (not NULL), and dereferences their 'next' pointer, causing a kernel panic if this is not yet initialized. Let's protect from that by moving inits to the beginning. This patch should be backported to kernels as old as 3.2, that contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test USB2 software LPM". Signed-off-by: Sergio Aguirre Acked-by: David Cohen Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit c9a5873064c5d8370f2ed264ecf584fcb46f5235 Author: Tony Camuso Date: Thu Feb 21 16:11:27 2013 -0500 xhci - correct comp_mode_recovery_timer on return from hibernate commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream. Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware) was a workaround for systems using the SN65LVPE502CP, controller, but it introduced a bug in resume from hibernate. The fix created a timer, comp_mode_recovery_timer, which is deleted from a timer list when xhci_suspend() is called. However, the hibernate image, including the timer list containing the comp_mode_recovery_timer, had already been saved before the timer was deleted. Upon resume from hibernate, the list containing the comp_mode_recovery_timer is restored from the image saved to disk, and xhci_resume(), assuming that the timer had been deleted by xhci_suspend(), makes a call to compliance_mode_recoery_timer_init(), which creates a new instance of the comp_mode_recovery_timer and attempts to place it into the same list in which it is already active, thus corrupting the list during the list_add() call. At this point, a call trace is emitted indicating the list corruption. Soon afterward, the system locks up, the watchdog times out, and the ensuing NMI crashes the system. The problem did not occur when resuming from suspend. In suspend, the image in RAM remains exactly as it was when xhci_suspend() deleted the comp_mode_recovery_timer, so there is no problem when xhci_resume() creates a new instance of this timer and places it in the still empty list. This patch avoids the problem by deleting the timer in xhci_resume() when resuming from hibernate. Now xhci_resume() can safely make the call to create a new instance of this timer, whether returning from suspend or hibernate. Thanks to Alan Stern for his help with understanding the problem. [Sarah reworked this patch to cover the case where the xHCI restore register operation fails, and (temp & STS_SRE) is true (and we re-init the host, including re-init for the compliance mode), but hibernate is false. The original patch would have caused list corruption in this case.] This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Tony Camuso Tested-by: Tony Camuso Acked-by: Don Zickus Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 1a395a153a4b70175d5df2d24e05c93041509945 Author: Peter Chen Date: Fri May 24 14:29:20 2013 +0800 usb: dwc3: pci: PHY should be deleted later than dwc3 core commit f28c42c576b293b3a1daaed8ca2775ebc2fe5398 upstream. If the glue layer is removed first (core layer later), it deletes the phy device first, then the core device. But at core's removal, it still uses PHY's resources, it may cause kernel's oops. It is much like the problem Paul Zimmerman reported at: http://marc.info/?l=linux-usb&m=136547502011472&w=2. Besides, it is reasonable the PHY is deleted at last as the controller is the PHY's user. Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 0df9e559f78311ab20dcf1c18ae35744944fabd0 Author: Dan Williams Date: Wed Jun 5 15:26:27 2013 -0500 USB: option,zte_ev: move most ZTE CDMA devices to zte_ev commit 73228a0538a70ebc4547bd09dee8971360dc1d87 upstream. Per some ZTE Linux drivers I found for the AC2716, the following patch moves most ZTE CDMA devices from option to zte_ev. The blacklist stuff that option does is not required with zte_ev, because it doesn't implement any of the send_setup hooks which the blacklist suppressed. I did not move the 2718 over because I could not find any ZTE Linux drivers for that device, nor even any Windows drivers. Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 37d3597178401d9ed511b13cf74d2ca73ac366d9 Author: Bjørn Mork Date: Thu Jun 6 12:57:24 2013 +0200 USB: option: blacklist network interface on Huawei E1820 commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream. The mode used by Windows for the Huawei E1820 will use the same ff/ff/ff class codes for both serial and network functions. Reported-by: Graham Inggs Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit ed7bdba6fd5412f3e74d110c5786e0e46c7d5393 Author: Richard Weinberger Date: Fri May 24 12:01:51 2013 +0200 USB: serial: Add Option GTM681W to qcserial device table. commit 8a2f132a01c2dd4c3905fa560f92019761ed72b1 upstream. The Option GTM681W uses a qualcomm chip and can be served by the qcserial device driver. Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman