commit 13280f4e2f8cd45240aef9c31643b17bffb3e9de Author: Greg Kroah-Hartman Date: Sun Jan 27 20:50:55 2013 -0800 Linux 3.7.5 commit 3618766f77d75709caf1cd4a9ab947a34e1ec96f Author: Laxman Dewangan Date: Wed Jan 9 15:26:22 2013 +0530 dma: tegra: implement flags parameters for cyclic transfer commit b9bb37f5486ba05d2b557dbf1aeb754fef618985 upstream. The flag parameter is added in the cyclic transfer request. Use the flag option of: - DMA_PREP_INTERRUPT for enabling interrupt. - DMA_CTRL_ACK for deciding whether ack is requred or not for descriptor. Signed-off-by: Laxman Dewangan Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 28b6835f12331a395bd1da8fa9024d9ec4ca5cea Author: Shuah Khan Date: Thu Oct 25 10:22:32 2012 -0600 ioat: Fix DMA memory sync direction correct flag commit ac4989874af56435c308bdde9ad9c837a26f8b23 upstream. ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug. Fixed the dma_sync_single_for_device() call to use the correct direction. [ 226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550() [ 226.288948] Hardware name: ProLiant DL380p Gen8 [ 226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE] [ 226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod [ 226.288967] Pid: 1055, comm: work_for_cpu Tainted: G W 3.3.0-0.20.el7.x86_64 #1 [ 226.288968] Call Trace: [ 226.288974] [] warn_slowpath_common+0x7f/0xc0 [ 226.288977] [] warn_slowpath_fmt+0x46/0x50 [ 226.288980] [] check_sync+0x132/0x550 [ 226.288983] [] debug_dma_sync_single_for_device+0x3f/0x50 [ 226.288988] [] ? wait_for_common+0x72/0x180 [ 226.288995] [] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma] [ 226.288999] [] ? kfree+0x259/0x270 [ 226.289004] [] ioat3_dma_self_test+0x1b/0x20 [ioatdma] [ 226.289008] [] ioat_probe+0x2f8/0x348 [ioatdma] [ 226.289011] [] ioat3_dma_probe+0x1d5/0x2aa [ioatdma] [ 226.289016] [] ioat_pci_probe+0x139/0x17c [ioatdma] [ 226.289020] [] local_pci_probe+0x5c/0xd0 [ 226.289023] [] ? destroy_work_on_stack+0x20/0x20 [ 226.289025] [] do_work_for_cpu+0x18/0x30 [ 226.289029] [] kthread+0xb7/0xc0 [ 226.289033] [] kernel_thread_helper+0x4/0x10 [ 226.289036] [] ? _raw_spin_unlock_irq+0x30/0x50 [ 226.289038] [] ? retint_restore_args+0x13/0x13 [ 226.289041] [] ? kthread_worker_fn+0x1a0/0x1a0 [ 226.289044] [] ? gs_change+0x13/0x13 [ 226.289045] ---[ end trace e1618afc7a606089 ]--- [ 226.289047] Mapped at: [ 226.289048] [] debug_dma_map_page+0x87/0x150 [ 226.289050] [] dma_map_page.constprop.18+0x70/0xb34 [ioatdma] [ 226.289054] [] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma] [ 226.289058] [] ioat3_dma_self_test+0x1b/0x20 [ioatdma] [ 226.289061] [] ioat_probe+0x2f8/0x348 [ioatdma] Signed-off-by: Shuah Khan Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 0f7569d07a5a70c07486e95ff436dc6afe8e3bb6 Author: Konrad Rzeszutek Wilk Date: Wed Jan 16 23:40:01 2013 +0100 intel_idle: Don't register CPU notifier if we are not running. commit 6f8c2e7933679f54b6478945dc72e59ef9a3d5e0 upstream. The 'intel_idle_probe' probes the CPU and sets the CPU notifier. But if later on during the module initialization we fail (say in cpuidle_register_driver), we stop loading, but we neglect to unregister the CPU notifier. This means that during CPU hotplug events the system will fail: calling intel_idle_init+0x0/0x326 @ 1 intel_idle: MWAIT substates: 0x1120 intel_idle: v0.4 model 0x2A intel_idle: lapic_timer_reliable_states 0xffffffff intel_idle: intel_idle yielding to none initcall intel_idle_init+0x0/0x326 returned -19 after 14 usecs ... some time later, offlining and onlining a CPU: cpu 3 spinlock event irq 62 BUG: unable to ] __cpuidle_register_device+0x1c/0x120 PGD 99b8b067 PUD 99b95067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: xen_evtchn nouveau mxm_wmi wmi radeon ttm i915 fbcon tileblit font atl1c bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf CPU 0 Pid: 2302, comm: udevd Not tainted 3.8.0-rc3upstream-00249-g09ad159 #1 MSI MS-7680/H61M-P23 (MS-7680) RIP: e030:[] [] __cpuidle_register_device+0x1c/0x120 RSP: e02b:ffff88009dacfcb8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff880105380000 RCX: 000000000000001c RDX: 0000000000000000 RSI: 0000000000000055 RDI: ffff880105380000 RBP: ffff88009dacfce8 R08: ffffffff81a4f048 R09: 0000000000000008 R10: 0000000000000008 R11: 0000000000000000 R12: ffff880105380000 R13: 00000000ffffffdd R14: 0000000000000000 R15: ffffffff81a523d0 FS: 00007f37bd83b7a0(0000) GS:ffff880105200000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 00000000a09ea000 CR4: 0000000000042660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process udevd (pid: 2302, threadinfo ffff88009dace000, task ffff88009afb47f0) Stack: ffffffff8107f2d0 ffffffff810c2fb7 ffff88009dacfce8 00000000ffffffea ffff880105380000 00000000ffffffdd ffff88009dacfd08 ffffffff814d9882 0000000000000003 ffff880105380000 ffff88009dacfd28 ffffffff81340afd Call Trace: [] ? collect_cpu_info_local+0x30/0x30 [] ? __might_sleep+0xe7/0x100 [] cpuidle_register_device+0x32/0x70 [] intel_idle_cpu_init+0xad/0x110 [] cpu_hotplug_notify+0x68/0x80 [] notifier_call_chain+0x4d/0x70 [] __raw_notifier_call_chain+0x9/0x10 [] __cpu_notify+0x1b/0x30 [] _cpu_up+0x103/0x14b [] cpu_up+0xd9/0xec [] store_online+0x94/0xd0 [] dev_attr_store+0x1b/0x20 [] sysfs_write_file+0xf4/0x170 [] vfs_write+0xb4/0x130 [] sys_write+0x5a/0xa0 [] system_call_fastpath+0x16/0x1b Code: 03 18 00 c9 c3 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d e8 4c 89 65 f0 48 89 fb 4c 89 6d f8 e8 84 08 00 00 <48> 8b 78 08 49 89 c4 e8 f8 7f c1 ff 89 c2 b8 ea ff ff ff 84 d2 RIP [] __cpuidle_register_device+0x1c/0x120 RSP This patch fixes that by moving the CPU notifier registration as the last item to be done by the module. Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 52687280c7c9e5bf6d1756ba8c86d52c2ebfa481 Author: Fabio Estevam Date: Mon Jan 7 22:32:06 2013 -0200 i2c: mxs: Fix type of error code commit 0f40cbc4f85e13b1a42ae2f41231645a14965872 upstream. cmd_err is used to handle error code, so it should not be unsigned. This fixes the following warning when building with W=1 option: drivers/i2c/busses/i2c-mxs.c: In function 'mxs_i2c_xfer_msg': drivers/i2c/busses/i2c-mxs.c:331:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Signed-off-by: Fabio Estevam Acked-by: Marek Vasut Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 5f37ca96b441bcf255c4361a6b6e1873603a92f3 Author: Stefan Bader Date: Tue Jan 22 13:37:21 2013 +0100 ACPI: Check MSR valid bit before using P-state frequencies commit 9855d8ce41a7801548a05d844db2f46c3e810166 upstream. To fix incorrect P-state frequencies which can happen on some AMD systems f594065faf4f9067c2283a34619fc0714e79a98d "ACPI: Add fixups for AMD P-state figures" introduced a quirk to obtain the correct values by reading from AMD specific MSRs. This did cause a regression when running a kernel using that quirk under Xen which does (currently) not pass through MSR reads to the HW. Instead the guest gets a 0 in return. And this seems to cause a failure to initialize the ondemand governour (hard to say for sure as all P-states appear to run at the same frequency). While this should also be fixed in the hypervisor (to allow a guest to read that MSR), this patch is intended to work around the issue in the meantime. In discussion it turned out that indeed real HW/BIOSes may choose to not set the valid bit and thus mark the P-state as invalid. So this could be considered a fix for broken BIOSes that also works around the issue on Xen. Signed-off-by: Stefan Bader Acked-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 709084328e3a553ae6e27f5a8e826baecc3fd615 Author: Thomas Schlichter Date: Sat Jan 19 00:28:22 2013 +0100 ACPI / processor: Get power info before updating the C-states commit f427e5f1cf75bba84cccdac1d8a90552d9ae1065 upstream. acpi_processor_get_power_info() has to be called before acpi_processor_setup_cpuidle_states() to have the latest information available. This fixes the missing C-state information after AC-->DC transition. Signed-off-by: Thomas Schlichter Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 85df2a74cc858a8872da61a29a76bd187a98e7fc Author: Konrad Rzeszutek Wilk Date: Wed Jan 16 23:40:07 2013 +0100 ACPI / cpuidle: Fix NULL pointer issues when cpuidle is disabled commit b88a634a903d9670aa5f2f785aa890628ce0dece upstream. If cpuidle is disabled, that means that: per_cpu(acpi_cpuidle_device, pr->id) is set to NULL as the acpi_processor_power_init ends up failing at retval = cpuidle_register_driver(&acpi_idle_driver) (in acpi_processor_power_init) and never sets the per_cpu idle device. So when acpi_processor_hotplug on CPU online notification tries to reference said device it crashes: cpu 3 spinlock event irq 62 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [] acpi_processor_setup_cpuidle_cx+0x3f/0x105 PGD a259b067 PUD ab38b067 PMD 0 Oops: 0002 [#1] SMP odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf CPU 1 Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680) RIP: e030:[] [] acpi_processor_setup_cpuidle_cx+0x3f/0x105 RSP: e02b:ffff88001742dca8 EFLAGS: 00010202 RAX: 0000000000010be9 RBX: ffff8800a0a61800 RCX: ffff880105380000 RDX: 0000000000000003 RSI: 0000000000000200 RDI: ffff8800a0a61800 RBP: ffff88001742dce8 R08: ffffffff81812360 R09: 0000000000000200 R10: aaaaaaaaaaaaaaaa R11: 0000000000000001 R12: ffff8800a0a61800 R13: 00000000ffffff01 R14: 0000000000000000 R15: ffffffff81a907a0 FS: 00007fd6942f7700(0000) GS:ffff880105280000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000004 CR3: 00000000a6773000 CR4: 0000000000042660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process bash (pid: 3047, threadinfo ffff88001742c000, task ffff880017944000) Stack: 0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800 0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0 ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336 Call Trace: [] acpi_processor_hotplug+0x7c/0x9f [] ? schedule_delayed_work_on+0x16/0x20 [] acpi_cpu_soft_notify+0x90/0xca [] notifier_call_chain+0x4d/0x70 [] __raw_notifier_call_chain+0x9/0x10 [] __cpu_notify+0x1b/0x30 [] _cpu_up+0x103/0x14b [] cpu_up+0xd9/0xec [] store_online+0x94/0xd0 [] dev_attr_store+0x1b/0x20 [] sysfs_write_file+0xf4/0x170 This patch fixes it. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b1d12e5928ea12b7abf1f80e509e92ea00ba4409 Author: Matthew Garrett Date: Tue Jan 22 22:33:46 2013 +0100 cpufreq: Add module aliases for acpi-cpufreq commit efa17194581bdfca0986dabc178908bd7c21ba00 upstream. The acpi core will call request_module("acpi-cpufreq") on subsystem init, but this will fail if the module isn't available at that stage of boot. Add some module aliases to ensure that udev can load the module on Intel and AMD systems with the appropriate feature bits - I /think/ that this will also work on VIA systems, but haven't verified that. References: http://lkml.kernel.org/r/1448223.sdUJnNSRz4@vostro.rjw.lan Signed-off-by: Matthew Garrett Tested-by: Leonid Isaev Acked-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ac4f896a4da38ca42d2ca32d4127517df7331205 Author: Borislav Petkov Date: Fri Jan 18 00:19:37 2013 +0100 powernow-k8: Add a kconfig dependency on acpi-cpufreq commit 631e8ac18fd59722e7ceb15fceeef3f368c250f9 upstream. Andreas reports in https://bugzilla.kernel.org/show_bug.cgi?id=51741 that with his Gentoo config, acpi-cpufreq wasn't enabled and powernow-k8 couldn't handoff properly to acpi-cpufreq leading to running without P-state support (i.e., cores are constantly in P0). To alleaviate that, we need to make powernow-k8 depend on acpi-cpufreq so that acpi-cpufreq is always present. References: https://bugzilla.kernel.org/show_bug.cgi?id=51741 Reported-by: Andreas Signed-off-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a974118816871c9e5a1e7b837310ee1b84581c6d Author: Linus Torvalds Date: Sun Jan 20 20:22:58 2013 -0800 module: fix missing module_mutex unlock commit ee61abb3223e28a1a14a8429c0319755d20d3e40 upstream. Commit 1fb9341ac348 ("module: put modules in list much earlier") moved some of the module initialization code around, and in the process changed the exit paths too. But for the duplicate export symbol error case the change made the ddebug_cleanup path jump to after the module mutex unlock, even though it happens with the mutex held. Rusty has some patches to split this function up into some helper functions, hopefully the mess of complex goto targets will go away eventually. Reported-by: Dan Carpenter Cc: Rusty Russell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f9586ddba7b93ea72190f79c82079cbfc4bb8730 Author: Rusty Russell Date: Sat Jan 12 13:27:34 2013 +1030 module: put modules in list much earlier. commit 1fb9341ac34825aa40354e74d9a2c69df7d2c304 upstream. Prarit's excellent bug report: > In recent Fedora releases (F17 & F18) some users have reported seeing > messages similar to > > [ 15.478160] kvm: Could not allocate 304 bytes percpu data > [ 15.478174] PERCPU: allocation failed, size=304 align=32, alloc from > reserved chunk failed > > during system boot. In some cases, users have also reported seeing this > message along with a failed load of other modules. > > What is happening is systemd is loading an instance of the kvm module for > each cpu found (see commit e9bda3b). When the module load occurs the kernel > currently allocates the modules percpu data area prior to checking to see > if the module is already loaded or is in the process of being loaded. If > the module is already loaded, or finishes load, the module loading code > releases the current instance's module's percpu data. Now we have a new state MODULE_STATE_UNFORMED, we can insert the module into the list (and thus guarantee its uniqueness) before we allocate the per-cpu region. Reported-by: Prarit Bhargava Signed-off-by: Rusty Russell Tested-by: Prarit Bhargava Signed-off-by: Greg Kroah-Hartman commit 27fb20cc5a25acbc5396adfe286e3e5fc0befaf9 Author: Rusty Russell Date: Sat Jan 12 11:38:44 2013 +1030 module: add new state MODULE_STATE_UNFORMED. commit 0d21b0e3477395e7ff2acc269f15df6e6a8d356d upstream. You should never look at such a module, so it's excised from all paths which traverse the modules list. We add the state at the end, to avoid gratuitous ABI break (ksplice). Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit dd1b4df2d30cef50fd648ecba6a590d9f0ff9ea7 Author: Daniel Vetter Date: Fri Dec 14 23:38:28 2012 +0100 drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled commit 4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream. Quoting from Bspec, 3D_CHICKEN1, bit 10 This bit needs to be set always to "1", Project: DevSNB " Reviewed-by: Rodrigo Vivi Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit add6ca8709cf9a56699affef5ecd24205489ff78 Author: Zhenzhong Duan Date: Thu Dec 20 15:05:14 2012 -0800 drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists commit 9f9c9cbb60576a1518d0bf93fb8e499cffccf377 upstream. The right dmi version is in SMBIOS if it's zero in DMI region This issue was originally found from an oracle bug. One customer noticed system UUID doesn't match between dmidecode & uek2. - HP ProLiant BL460c G6 : # cat /sys/devices/virtual/dmi/id/product_uuid 00000000-0000-4C48-3031-4D5030333531 # dmidecode | grep -i uuid UUID: 00000000-0000-484C-3031-4D5030333531 From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than network byte order. So we need to get dmi version to distinguish. If version is 0.0, the real version is taken from the SMBIOS version. This is part of original kernel comment in code. [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: Zhenzhong Duan Cc: Feng Jin Cc: Jean Delvare Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Abdallah Chatila Signed-off-by: Greg Kroah-Hartman commit 2b491c79cf9ecf5fdcb312082f8cb2af98cf4cdf Author: Zhenzhong Duan Date: Thu Dec 20 15:05:13 2012 -0800 drivers/firmware/dmi_scan.c: check dmi version when get system uuid commit f1d8e614d74b09531b9a85e812485340f3df7b1c upstream. As of version 2.6 of the SMBIOS specification, the first 3 fields of the UUID are supposed to be little-endian encoded. Also a minor fix to match variable meaning and mute checkpatch.pl [akpm@linux-foundation.org: tweak code comment] Signed-off-by: Zhenzhong Duan Cc: Feng Jin Cc: Jean Delvare Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Abdallah Chatila Signed-off-by: Greg Kroah-Hartman commit 391c096fefcb7b274ba90d46409cd4ba751ba57b Author: Joel D. Diaz Date: Wed Oct 10 10:36:11 2012 +0200 SCSI: sd: Reshuffle init_sd to avoid crash commit afd5e34b2bb34881d3a789e62486814a49b47faa upstream. scsi_register_driver will register a prep_fn() function, which in turn migh need to use the sd_cdp_pool for DIF. Which hasn't been initialised at this point, leading to a crash. So reshuffle the init_sd() and exit_sd() paths to have the driver registered last. Signed-off-by: Joel D. Diaz Signed-off-by: Hannes Reinecke Signed-off-by: James Bottomley Cc: CAI Qian Signed-off-by: Greg Kroah-Hartman commit 20056d76fc15d9ca67fa806b9dd21109f736e253 Author: Sergei Shtylyov Date: Fri Dec 14 21:30:27 2012 +0300 usb: musb: cppi_dma: drop '__init' annotation commit 091a62c9b3d899d99dbf4e3dbebc8dfa3edbccdd upstream. This patch fixes the following: WARNING: vmlinux.o(.text+0x1e709c): Section mismatch in reference from the funct ion dma_controller_create() to the function .init.text:cppi_controller_start() The function dma_controller_create() references the function __init cppi_controller_start(). This is often because dma_controller_create lacks a __init annotation or the annotation of cppi_controller_start is wrong. This warning is there due to the deficiency in the commit 07a67bbb (usb: musb: Make dma_controller_create __devinit). Since the start() method is only called from musb_init_controller() which is not annotated, drop '__init' annotation from cppi_controller_start() and also cppi_pool_init() since it gets called from that function, to avoid another section mismatch warning... Signed-off-by: Sergei Shtylyov Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit cf8c21513eadeb9a3edf87e63975bdab60bcf657 Author: Benoit Goby Date: Tue Jan 8 19:57:09 2013 -0800 usb: gadget: FunctionFS: Fix missing braces in parse_opts commit b810075002c9f25a6da83cecda39d789000a04a9 upstream. Add missing braces around an if block in ffs_fs_parse_opts. This broke parsing the uid/gid mount options and causes mount to fail when using uid/gid. This has been introduced by commit b9b73f7c (userns: Convert usb functionfs to use kuid/kgid where appropriate) in 3.7. Signed-off-by: Benoit Goby Acked-by: Michal Nazarewicz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit bda2b180545b2ef586658ed5c3312cb947a2a6c9 Author: Pratyush Anand Date: Fri Jan 18 16:53:56 2013 +0530 usb: dwc3: gadget: fix ep->maxburst for ep0 commit 6048e4c69d80600baba35856651056860d5d8f5a upstream. dwc3_gadget_set_ep_config expects maxburst as incremented by 1. So, by default initialize ep->maxburst to 1 for ep0. Signed-off-by: Pratyush Anand Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit dac7b553e37a1694a51d9db87f48d5603e753afe Author: Alan Stern Date: Tue Jan 22 11:37:35 2013 -0500 USB: UHCI: fix IRQ race during initialization commit 0f815a0a700bc10547449bde6c106051a035a1b9 upstream. This patch (as1644) fixes a race that occurs during startup in uhci-hcd. If the IRQ line is shared with other devices, it's possible for the handler routine to be called before the data structures are fully initialized. The problem is fixed by adding a check to the IRQ handler routine. If the initialization hasn't finished yet, the routine will return immediately. Signed-off-by: Alan Stern Reported-by: Don Zickus Tested-by: "Huang, Adrian (ISS Linux TW)" Signed-off-by: Greg Kroah-Hartman commit e3cbd56ee0101eb1a9897bee3a04268d34170abb Author: Jacob Schloss Date: Sun Dec 9 20:18:25 2012 -0300 media: gspca_kinect: add Kinect for Windows USB id commit 98fd485795db064d0885150e2c0c7f296d8fe06e upstream. Add the USB ID for the Kinect for Windows RGB camera so it can be used with the gspca_kinect driver. Signed-off-by: Jacob Schloss Signed-off-by: Antonio Ospite Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0d1f039f86e7bdd50ae1b2456c71b67c8920d3c6 Author: Luciano Coelho Date: Mon Jan 21 13:12:42 2013 +0200 Revert "drivers/misc/ti-st: remove gpio handling" commit a7e2ca17039edb5f782be519eaf9d8ea500ba7cc upstream. This reverts commit eccf2979b2c034b516e01b8a104c3739f7ef07d1. The reason is that it broke TI WiLink shared transport on Panda. Also, callback functions should not be added to board files anymore, so revert to implementing the power functions in the driver itself. Additionally, changed a variable name ('status' to 'err') so that this revert compiles properly. Acked-by: Tony Lindgren Signed-off-by: Luciano Coelho [changed "err" back to "status" to get it to build in 3.7 - gregkh] Signed-off-by: Greg Kroah-Hartman commit 8de1accd5386dd947044890963ccfc83e5e28cb0 Author: Bjorn Helgaas Date: Fri Jan 11 12:21:15 2013 -0700 PCI: shpchp: Use per-slot workqueues to avoid deadlock commit f652e7d2916fe2fcf9e7d709aa5b7476b431e2dd upstream. When we have an SHPC-capable bridge with a second SHPC-capable bridge below it, pushing the upstream bridge's attention button causes a deadlock. The deadlock happens because we use the shpchp_wq workqueue to run shpchp_pushbutton_thread(), which uses shpchp_disable_slot() to remove devices below the upstream bridge. When we remove the downstream bridge, we call shpc_remove(), the shpchp driver's .remove() method. That calls flush_workqueue(shpchp_wq), which deadlocks because the shpchp_pushbutton_thread() work item is still running. This patch avoids the deadlock by creating a workqueue for every slot and removing the single shared workqueue. Here's the call path that leads to the deadlock: shpchp_queue_pushbutton_work queue_work(shpchp_wq) # shpchp_pushbutton_thread ... shpchp_pushbutton_thread shpchp_disable_slot remove_board shpchp_unconfigure_device pci_stop_and_remove_bus_device ... shpc_remove # shpchp driver .remove method hpc_release_ctlr cleanup_slots flush_workqueue(shpchp_wq) This change is based on code inspection, since we don't have hardware with this topology. Based-on-patch-by: Yijing Wang Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 6b816c6a5e4f45cff374ca827aeaf1be2f0b32a9 Author: Bjorn Helgaas Date: Fri Jan 11 12:07:22 2013 -0700 PCI: shpchp: Handle push button event asynchronously commit d347e75847c1fb299c97736638f45e6ea39702d4 upstream. Use non-ordered workqueue for attention button events. Attention button events on each slot can be handled asynchronously. So we should use non-ordered workqueue. This patch also removes ordered workqueue in shpchp as a result. 486b10b9f4 ("PCI: pciehp: Handle push button event asynchronously") made the same change to pciehp. I split this out from a patch by Yijing Wang so we fix one thing at a time and to make the shpchp history correspond more closely with the pciehp history. Signed-off-by: Bjorn Helgaas CC: Kenji Kaneshige Signed-off-by: Greg Kroah-Hartman commit 4400d958826604db944e3a86d922e02f689b74d7 Author: Yijing Wang Date: Fri Jan 11 10:15:54 2013 +0800 PCI: pciehp: Use per-slot workqueues to avoid deadlock commit c2be6f93b383c873a4f9d521afa49b1b67d06085 upstream. When we have a hotplug-capable PCIe port with a second hotplug-capable PCIe port below it, removing the device below the upstream port causes a deadlock. The deadlock happens because we use the pciehp_wq workqueue to run pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices below the upstream port. When we remove the downstream PCIe port, we call pciehp_remove(), the pciehp driver's .remove() method. That calls flush_workqueue(pciehp_wq), which deadlocks because the pciehp_power_thread() work item is still running. This patch avoids the deadlock by creating a workqueue for every PCIe port and removing the single shared workqueue. Here's the call path that leads to the deadlock: pciehp_queue_pushbutton_work queue_work(pciehp_wq) # queue pciehp_power_thread ... pciehp_power_thread pciehp_disable_slot remove_board pciehp_unconfigure_device pci_stop_and_remove_bus_device ... pciehp_remove # pciehp driver .remove method pciehp_release_ctrl pcie_cleanup_slot flush_workqueue(pciehp_wq) This is fairly urgent because it can be caused by simply unplugging a Thunderbolt adapter, as reported by Daniel below. [bhelgaas: changelog] Reference: http://lkml.kernel.org/r/CAMVG2ssiRgcTD1bej2tkUUfsWmpL5eNtPcNif9va2-Gzb2u8nQ@mail.gmail.com Reported-and-tested-by: Daniel J Blueman Reviewed-by: Kenji Kaneshige Signed-off-by: Yijing Wang Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 48310adbde5b3448b85d6d6d404cc7ee16339ae5 Author: Colin Ian King Date: Tue Nov 27 14:09:40 2012 +0000 PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported commit 9e16721498b0c3d3ebfa0b503c63d35c0a4c0642 upstream. Right now using pcie_aspm=force will not enable ASPM if the FADT indicates ASPM is unsupported. However, the semantics of force should probably allow for this, especially as they did before 3c076351c4 ("PCI: Rework ASPM disable code") This patch just skips the clearing of any ASPM setup that the firmware has carried out on this bus if pcie_aspm=force is being used. Reference: http://bugs.launchpad.net/bugs/962038 Signed-off-by: Colin Ian King Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 8dd19b22e59d25a3730c3b536ad9cdc2561517bf Author: Betty Dall Date: Sun Jan 13 15:46:18 2013 -0700 PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_put() commit a82b6af37d20bfe6e99a4d890f1cf1d89059929f upstream. The function aer_recover_queue() calls pci_get_domain_bus_and_slot(), which requires that the caller decrement the reference count with pci_dev_put(). This patch adds the missing call to pci_dev_put(). Signed-off-by: Betty Dall Signed-off-by: Bjorn Helgaas Reviewed-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 88bf96babf604524df116b3e9c8400020bc87724 Author: Will Deacon Date: Tue Jan 22 15:34:40 2013 +0000 arm64: elf: fix core dumping to match what glibc expects commit 9cf2b72b25f3f6a5a1a46a4f36037e66de52465c upstream. The kernel's internal definition of ELF_NGREG uses struct pt_regs, which means that we disagree with userspace on the size of coredumps since glibc correctly uses the user-visible struct user_pt_regs. This patch fixes our ELF_NGREG definition to use struct user_pt_regs and introduces our own ELF_CORE_COPY_REGS to convert between the user and kernel structure definitions. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 8380f1ac24cf817ad65afbfa7ae9ab445dc04fc9 Author: Will Deacon Date: Fri Jan 18 19:00:47 2013 +0000 arm64: makefile: fix uname munging when setting ARCH on native machine commit f1b99392caf120d7533da260318fae0eb5053737 upstream. By popular demand, arch/aarch64 is now known as arch/arm64. However, uname -m (and indeed the GNU triplet) still use aarch64 as the machine string. This patch fixes native builds of both the kernel and perf tools by updating the relevant Makefiles to munge the output of uname -m and set the ARCH variable appropriately. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 0ce1fda598f8e78e35ca17b1e24ed8c43e597b02 Author: Takashi Iwai Date: Mon Jan 21 16:53:37 2013 +0100 ALSA: hda - Add Conexant CX20755/20756/20757 codec IDs commit 42c364ace52ae6b4699105b39f2559c256b6cd4c upstream. These are just compatible with other CX2075x codecs. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1db4a44ba98b44c071ad29fad7a9200fc2792628 Author: David Henningsson Date: Fri Jan 18 12:00:47 2013 +0100 ALSA: hda - Fix mute led for another HP machine commit e04340375a314166e14519fca9e5b9e9394b2d7a upstream. This machine also has the "HP_Mute_LED_0_A" string in DMI information. BugLink: https://bugs.launchpad.net/bugs/1096789 Tested-by: Tammy Yang Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7b554bf5fb215368a77778a001383bb50448738c Author: Oleg Nesterov Date: Mon Jan 21 20:48:17 2013 +0100 wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task commit 9067ac85d533651b98c2ff903182a20cbb361fcb upstream. wake_up_process() should never wakeup a TASK_STOPPED/TRACED task. Change it to use TASK_NORMAL and add the WARN_ON(). TASK_ALL has no other users, probably can be killed. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ddfc30aacf58bf565c91f29150fe2086b698737b Author: Oleg Nesterov Date: Mon Jan 21 20:48:00 2013 +0100 ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL commit 9899d11f654474d2d54ea52ceaa2a1f4db3abd68 upstream. putreg() assumes that the tracee is not running and pt_regs_access() can safely play with its stack. However a killed tracee can return from ptrace_stop() to the low-level asm code and do RESTORE_REST, this means that debugger can actually read/modify the kernel stack until the tracee does SAVE_REST again. set_task_blockstep() can race with SIGKILL too and in some sense this race is even worse, the very fact the tracee can be woken up breaks the logic. As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace() call, this ensures that nobody can ever wakeup the tracee while the debugger looks at it. Not only this fixes the mentioned problems, we can do some cleanups/simplifications in arch_ptrace() paths. Probably ptrace_unfreeze_traced() needs more callers, for example it makes sense to make the tracee killable for oom-killer before access_process_vm(). While at it, add the comment into may_ptrace_stop() to explain why ptrace_stop() still can't rely on SIGKILL and signal_pending_state(). Reported-by: Salman Qazi Reported-by: Suleiman Souhlal Suggested-by: Linus Torvalds Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 79db599067c85ce13bb46aa72de79676e96ed8c9 Author: Oleg Nesterov Date: Mon Jan 21 20:47:41 2013 +0100 ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up() commit 910ffdb18a6408e14febbb6e4b6840fd2c928c82 upstream. Cleanup and preparation for the next change. signal_wake_up(resume => true) is overused. None of ptrace/jctl callers actually want to wakeup a TASK_WAKEKILL task, but they can't specify the necessary mask. Turn signal_wake_up() into signal_wake_up_state(state), reintroduce signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up() which adds __TASK_TRACED. This way ptrace_signal_wake_up() can work "inside" ptrace_request() even if the tracee doesn't have the TASK_WAKEKILL bit set. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7ab00191afc44277b0639f64353b366de122d2c2 Author: David Ahern Date: Fri Dec 28 19:56:07 2012 -0700 perf x86: revert 20b279 - require exclude_guest to use PEBS - kernel side commit a706d965dcfdff73bf2bad1c300f8119900714c7 upstream. This patch is brought to you by the letter 'H'. Commit 20b279 breaks compatiblity with older perf binaries when run with precise modifier (:p or :pp) by requiring the exclude_guest attribute to be set. Older binaries default exclude_guest to 0 (ie., wanting guest-based samples) unless host only profiling is requested (:H modifier). The workaround for older binaries is to add H to the modifier list (e.g., -e cycles:ppH - toggles exclude_guest to 1). This was deemed unacceptable by Linus: https://lkml.org/lkml/2012/12/12/570 Between family in town and the fresh snow in Breckenridge there is no time left to be working on the proper fix for this over the holidays. In the New Year I have more pressing problems to resolve -- like some memory leaks in perf which are proving to be elusive -- although the aforementioned snow is probably why they are proving to be elusive. Either way I do not have any spare time to work on this and from the time I have managed to spend on it the solution is more difficult than just moving to a new exclude_guest flag (does not work) or flipping the logic to include_guest (which is not as trivial as one would think). So, two options: silently force exclude_guest on as suggested by Gleb which means no impact to older perf binaries or revert the original patch which caused the breakage. This patch does the latter -- reverts the original patch that introduced the regression. The problem can be revisited in the future as time allows. Signed-off-by: David Ahern Cc: Avi Kivity Cc: Gleb Natapov Cc: Ingo Molnar Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Robert Richter Link: http://lkml.kernel.org/r/1356749767-17322-1-git-send-email-dsahern@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 87c7746150f3c90b23837817af9be414baf7e25b Author: Alex Williamson Date: Tue Jan 15 10:45:26 2013 -0700 vfio-pci: Fix buffer overfill commit ec1287e511320a2c9a02640b7ac02d5d79f56f08 upstream. A read from a range hidden from the user (ex. MSI-X vector table) attempts to fill the user buffer up to the end of the excluded range instead of up to the requested count. Fix it. Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 9b19e974ebb8ae156e03a6ad7361b8c7134e68a0 Author: Tejun Heo Date: Tue Jan 22 16:15:15 2013 -0800 async: fix __lowest_in_progress() commit f56c3196f251012de9b3ebaff55732a9074fdaae upstream. Commit 083b804c4d3e ("async: use workqueue for worker pool") made it possible that async jobs are moved from pending to running out-of-order. While pending async jobs will be queued and dispatched for execution in the same order, nothing guarantees they'll enter "1) move self to the running queue" of async_run_entry_fn() in the same order. Before the conversion, async implemented its own worker pool. An async worker, upon being woken up, fetches the first item from the pending list, which kept the executing lists sorted. The conversion to workqueue was done by adding work_struct to each async_entry and async just schedules the work item. The queueing and dispatching of such work items are still in order but now each worker thread is associated with a specific async_entry and moves that specific async_entry to the executing list. So, depending on which worker reaches that point earlier, which is non-deterministic, we may end up moving an async_entry with larger cookie before one with smaller one. This broke __lowest_in_progress(). running->domain may not be properly sorted and is not guaranteed to contain lower cookies than pending list when not empty. Fix it by ensuring sort-inserting to the running list and always looking at both pending and running when trying to determine the lowest cookie. Over time, the async synchronization implementation became quite messy. We better restructure it such that each async_entry is linked to two lists - one global and one per domain - and not move it when execution starts. There's no reason to distinguish pending and running. They behave the same for synchronization purposes. Signed-off-by: Tejun Heo Cc: Arjan van de Ven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 00112dc1bf0af8f50cd7f7c8008eb4230e8db5d7 Author: Alexander Graf Date: Wed Jan 2 15:37:17 2013 +1030 virtio-blk: Don't free ida when disk is in use commit f4953fe6c4aeada2d5cafd78aa97587a46d2d8f9 upstream. When a file system is mounted on a virtio-blk disk, we then remove it and then reattach it, the reattached disk gets the same disk name and ids as the hot removed one. This leads to very nasty effects - mostly rendering the newly attached device completely unusable. Trying what happens when I do the same thing with a USB device, I saw that the sd node simply doesn't get free'd when a device gets forcefully removed. Imitate the same behavior for vd devices. This way broken vd devices simply are never free'd and newly attached ones keep working just fine. Signed-off-by: Alexander Graf Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit a833765edd399f4c14337592bd13df6a83094c5a Author: Dmitry Kasatkin Date: Fri Jan 18 23:56:39 2013 +0200 evm: checking if removexattr is not a NULL commit a67adb997419fb53540d4a4f79c6471c60bc69b6 upstream. The following lines of code produce a kernel oops. fd = socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0); fchmod(fd, 0666); [ 139.922364] BUG: unable to handle kernel NULL pointer dereference at (null) [ 139.924982] IP: [< (null)>] (null) [ 139.924982] *pde = 00000000 [ 139.924982] Oops: 0000 [#5] SMP [ 139.924982] Modules linked in: fuse dm_crypt dm_mod i2c_piix4 serio_raw evdev binfmt_misc button [ 139.924982] Pid: 3070, comm: acpid Tainted: G D 3.8.0-rc2-kds+ #465 Bochs Bochs [ 139.924982] EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 0 [ 139.924982] EIP is at 0x0 [ 139.924982] EAX: cf5ef000 EBX: cf5ef000 ECX: c143d600 EDX: c15225f2 [ 139.924982] ESI: cf4d2a1c EDI: cf4d2a1c EBP: cc02df10 ESP: cc02dee4 [ 139.924982] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 139.924982] CR0: 80050033 CR2: 00000000 CR3: 0c059000 CR4: 000006d0 [ 139.924982] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 139.924982] DR6: ffff0ff0 DR7: 00000400 [ 139.924982] Process acpid (pid: 3070, ti=cc02c000 task=d7705340 task.ti=cc02c000) [ 139.924982] Stack: [ 139.924982] c1203c88 00000000 cc02def4 cf4d2a1c ae21eefa 471b60d5 1083c1ba c26a5940 [ 139.924982] e891fb5e 00000041 00000004 cc02df1c c1203964 00000000 cc02df4c c10e20c3 [ 139.924982] 00000002 00000000 00000000 22222222 c1ff2222 cf5ef000 00000000 d76efb08 [ 139.924982] Call Trace: [ 139.924982] [] ? evm_update_evmxattr+0x5b/0x62 [ 139.924982] [] evm_inode_post_setattr+0x22/0x26 [ 139.924982] [] notify_change+0x25f/0x281 [ 139.924982] [] chmod_common+0x59/0x76 [ 139.924982] [] ? put_unused_fd+0x33/0x33 [ 139.924982] [] sys_fchmod+0x39/0x5c [ 139.924982] [] syscall_call+0x7/0xb [ 139.924982] Code: Bad EIP value. This happens because sockets do not define the removexattr operation. Before removing the xattr, verify the removexattr function pointer is not NULL. Signed-off-by: Dmitry Kasatkin Signed-off-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit aa9be7cda7e703d5898a3c98d11fa252dc72212e Author: Steven Rostedt Date: Fri Dec 14 09:48:15 2012 -0500 ftrace: Be first to run code modification on modules commit c1bf08ac26e92122faab9f6c32ea8aba94612dae upstream. If some other kernel subsystem has a module notifier, and adds a kprobe to a ftrace mcount point (now that kprobes work on ftrace points), when the ftrace notifier runs it will fail and disable ftrace, as well as kprobes that are attached to ftrace points. Here's the error: WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280() Hardware name: Bochs Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4 auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last unloaded: bid_shared] Pid: 8068, comm: modprobe Tainted: GF 3.7.0-0.rc8.git0.1.fc19.x86_64 #1 Call Trace: [] warn_slowpath_common+0x7f/0xc0 [] ? __probe_kernel_read+0x46/0x70 [] ? 0xffffffffa017ffff [] ? 0xffffffffa017ffff [] warn_slowpath_null+0x1a/0x20 [] ftrace_bug+0x239/0x280 [] ftrace_process_locs+0x376/0x520 [] ftrace_module_notify+0x47/0x50 [] notifier_call_chain+0x4d/0x70 [] __blocking_notifier_call_chain+0x58/0x80 [] blocking_notifier_call_chain+0x16/0x20 [] sys_init_module+0x73/0x220 [] system_call_fastpath+0x16/0x1b ---[ end trace 9ef46351e53bbf80 ]--- ftrace failed to modify [] init_once+0x0/0x20 [fat] actual: cc:bb:d2:4b:e1 A kprobe was added to the init_once() function in the fat module on load. But this happened before ftrace could have touched the code. As ftrace didn't run yet, the kprobe system had no idea it was a ftrace point and simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1). Then when ftrace went to modify the location from a call to mcount/fentry into a nop, it didn't see a call op, but instead it saw the breakpoint op and not knowing what to do with it, ftrace shut itself down. The solution is to simply give the ftrace module notifier the max priority. This should have been done regardless, as the core code ftrace modification also happens very early on in boot up. This makes the module modification closer to core modification. Link: http://lkml.kernel.org/r/20130107140333.593683061@goodmis.org Acked-by: Masami Hiramatsu Reported-by: Frank Ch. Eigler Signed-off-by: Steven Rostedt commit a71e051a8e26f3cbcb200cefed0398ee300a4c19 Author: Shane Huang Date: Mon Dec 17 23:18:59 2012 +0800 libata: replace sata_settings with devslp_timing commit 803739d25c2343da6d2f95eebdcbc08bf67097d4 upstream. NCQ capability was used to check availability of SATA Settings page from Identify Device Data Log, which contains DevSlp timing variables. It does not work on some HDDs and leads to error messages. IDENTIFY word 78 bit 5(Hardware Feature Control) can't work either because it is only the sufficient condition of Identify Device data log, not the necessary condition. This patch replaced ata_device->sata_settings with ->devslp_timing to only save DevSlp timing variables(8 bytes), instead of the whole SATA Settings page(512 bytes). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=51881 Reported-by: Borislav Petkov Signed-off-by: Shane Huang Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 2f3e145dc36d228997d22e9871615f74b2b06b91 Author: Hugh Daschbach Date: Fri Jan 4 14:39:09 2013 -0800 libata: ahci: Add support for Enmotus Bobcat device. commit 7f9c9f8e24590e7dcd26ca408458c43df5b83e61 upstream. Silicon does not support standard AHCI BAR assignment. Add vendor/device exception to force BAR 2. Signed-off-by: Hugh Daschbach Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 8d218e347dce06af65d1bc6da4d4c59d2a5c9a24 Author: Bian Yu Date: Wed Dec 12 22:26:58 2012 -0500 libata: ahci: Fix lack of command retry after a success error handler. commit 1eaca39a84170b369fe61fb1da3c1e8606859e99 upstream. It should be a mistake introduced by commit 8d899e70c1b3afff. qc->flags can't be set AC_ERR_* Signed-off-by: Bian Yu Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 5afeb70e606bdce5a76de1b482c53ad3b2829bf4 Author: Chris Wilson Date: Tue Jan 15 16:17:54 2013 +0000 drm/i915: Invalidate the relocation presumed_offsets along the slow path commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream. In the slow path, we are forced to copy the relocations prior to acquiring the struct mutex in order to handle pagefaults. We forgo copying the new offsets back into the relocation entries in order to prevent a recursive locking bug should we trigger a pagefault whilst holding the mutex for the reservations of the execbuffer. Therefore, we need to reset the presumed_offsets just in case the objects are rebound back into their old locations after relocating for this exexbuffer - if that were to happen we would assume the relocations were valid and leave the actual pointers to the kernels dangling, instant hang. Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4 Author: Chris Wilson Date: Sun Nov 21 22:07:12 2010 +0000 drm/i915: Handle pagefaults in execbuffer user relocations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson Cc: Daniel Vetter Signed-off-by: Daniel Vetter commit 8d6f01346caa705631292c41efb5924e1e677dd4 Author: Vineet Gupta Date: Fri Dec 21 12:25:44 2012 +0530 Ensure that kernel_init_freeable() is not inlined into non __init code commit f80b0c904da93b9ad7db2fd9823dd701932df779 upstream. Commit d6b2123802d "make sure that we always have a return path from kernel_execve()" reshuffled kernel_init()/init_post() to ensure that kernel_execve() has a caller to return to. It removed __init annotation for kernel_init() and introduced/calls a new routine kernel_init_freeable(). Latter however is inlined by any reasonable compiler (ARC gcc 4.4 in this case), causing slight code bloat. This patch forces kernel_init_freeable() as noinline reducing the .text bloat-o-meter vmlinux vmlinux_new add/remove: 1/0 grow/shrink: 0/1 up/down: 374/-334 (40) function old new delta kernel_init_freeable - 374 +374 (.init.text) kernel_init 628 294 -334 (.text) Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit f0de17c0babe7f29381892def6b37e9181a53410 Author: Al Viro Date: Sat Jan 19 13:29:54 2013 -0500 make sure that /linuxrc has std{in,out,err} commit 43b16820249396aea7eb57c747106e211e54bed5 upstream. Signed-off-by: Al Viro Cc: Barry Davis Signed-off-by: Greg Kroah-Hartman