commit 7dab6e46c118c060c04b12131def39003a59d1b9 Author: Greg Kroah-Hartman Date: Wed Mar 23 12:52:59 2011 -0700 Linux 2.6.37.5 commit 4e3837bb22675cef56b921230f7604fe1a451a5f Author: Vivien Didelot Date: Mon Mar 21 17:59:35 2011 +0100 hwmon: (sht15) Fix integer overflow in humidity calculation commit ccd32e735de7a941906e093f8dca924bb05c5794 upstream. An integer overflow occurs in the calculation of RHlinear when the relative humidity is greater than around 30%. The consequence is a subtle (but noticeable) error in the resulting humidity measurement. Signed-off-by: Vivien Didelot Signed-off-by: Jean Delvare Cc: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c5243dd839aca1011b90ff0d810f4d6ea927f18f Author: Alexander van Heukelum Date: Fri Mar 11 21:59:38 2011 +0100 x86, binutils, xen: Fix another wrong size directive commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream. The latest binutils (2.21.0.20110302/Ubuntu) breaks the build yet another time, under CONFIG_XEN=y due to a .size directive that refers to a slightly differently named (hence, to the now very strict and unforgiving assembler, non-existent) symbol. [ mingo: This unnecessary build breakage caused by new binutils version 2.21 gets escallated back several kernel releases spanning several years of Linux history, affecting over 130,000 upstream kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially affecting all major Linux distro kernel configs). Git annotate tells us that this slight debug symbol code mismatch bug has been introduced in 2008 in commit 3d75e1b8: 3d75e1b8 (Jeremy Fitzhardinge 2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs) The 'bug' is just a slight assymetry in ENTRY()/END() debug-symbols sequences, with lots of assembly code between the ENTRY() and the END(): ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs) ... END(do_hypervisor_callback) Human reviewers almost never catch such small mismatches, and binutils never even warned about it either. This new binutils version thus breaks the Xen build on all upstream kernels since v2.6.27, out of the blue. This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels impossible on such binutils, for a bisection window of over hundred thousand historic commits. (!) This is a major fail on the side of binutils and binutils needs to turn this show-stopper build failure into a warning ASAP. ] Signed-off-by: Alexander van Heukelum Cc: Jeremy Fitzhardinge Cc: Jan Beulich Cc: H.J. Lu Cc: Linus Torvalds Cc: Andrew Morton Cc: "H. Peter Anvin" Cc: Kees Cook LKML-Reference: <1299877178-26063-1-git-send-email-heukelum@fastmail.fm> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7503dd0d943211e428a91ec35b3e44604b722196 Author: Stefan Nilsson XK Date: Tue Mar 1 14:41:04 2011 +0100 mmc: sdio: remember new card RCA when redetecting card commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream. During redetection of a SDIO card, a request for a new card RCA was submitted to the card, but was then overwritten by the old RCA. This caused the card to be deselected instead of selected when using the incorrect RCA. This bug's been present since the "oldcard" handling was introduced in 2.6.32. Signed-off-by: Stefan Nilsson XK Reviewed-by: Ulf Hansson Reviewed-by: Pawel Wieczorkiewicz Signed-off-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 95abbe32f49a602b77144e797b556ee801be46a1 Author: Manoj Iyer Date: Fri Feb 11 16:25:31 2011 -0600 mmc: sdhci: Add Ricoh e823 PCI ID commit 5fd11c0754fa069b6aba64b65734aa2fb193552d upstream. Signed-off-by: Manoj Iyer Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 4ebea48e75fc819ed1454cbe42ea06d68abdd8b9 Author: Roman Fietze Date: Sun Mar 20 14:50:52 2011 +0100 i2c: Fix typo in instantiating-devices document commit 6ced9e6b3901af4ab6ac0a11231402c888286ea6 upstream. The struct i2c_board_info member holding the name is "type", not "name". Signed-off-by: Roman Fietze Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 998e8811f221196f568d124fb58a53ac0050c573 Author: Thomas Gleixner Date: Mon Feb 7 19:28:01 2011 +0100 fix per-cpu flag problem in the cpu affinity checkers commit 9804c9eaeacfe78651052c5ddff31099f60ef78c upstream. The CHECK_IRQ_PER_CPU is wrong, it should be checking irq_to_desc(irq)->status not just irq. Signed-off-by: Thomas Gleixner Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 19e70a61f3234d50db625a3b38f5597feffb2814 Author: Amir Hanania Date: Tue Feb 15 09:11:31 2011 +0000 ixgbe: work around for DDP last buffer size commit c600636bd560b04973174caa5e349a72bce51637 upstream. A HW limitation was recently discovered where the last buffer in a DDP offload cannot be a full buffer size in length. Fix the issue with a work around by adding another buffer with size = 1. Signed-off-by: Amir Hanania Tested-by: Ross Brattain Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit ba707d1b10f6b178babe6becbf520bb411141d9b Author: Alexander Duyck Date: Wed Jan 19 18:33:05 2011 +0000 ixgbe: limit VF access to network traffic commit 96cc637235892a102fb829218adac048bd730ab7 upstream. This change fixes VM pool allocation issues based on MAC address filtering, as well as limits the scope of VF access to promiscuous mode. Signed-off-by: Alexander Duyck Acked-by: Greg Rose Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 40c6b0274a9660e5051c3c150458d9bae2ac8979 Author: Shaohua Li Date: Wed Mar 16 11:37:29 2011 +0800 x86: Flush TLB if PGD entry is changed in i386 PAE mode commit 4981d01eada5354d81c8929d5b2836829ba3df7b upstream. According to intel CPU manual, every time PGD entry is changed in i386 PAE mode, we need do a full TLB flush. Current code follows this and there is comment for this too in the code. But current code misses the multi-threaded case. A changed page table might be used by several CPUs, every such CPU should flush TLB. Usually this isn't a problem, because we prepopulate all PGD entries at process fork. But when the process does munmap and follows new mmap, this issue will be triggered. When it happens, some CPUs keep doing page faults: http://marc.info/?l=linux-kernel&m=129915020508238&w=2 Reported-by: Yasunori Goto Tested-by: Yasunori Goto Reviewed-by: Rik van Riel Signed-off-by: Shaohua Li Cc: Mallick Asit K Cc: Linus Torvalds Cc: Andrew Morton Cc: linux-mm LKML-Reference: <1300246649.2337.95.camel@sli10-conroe> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ad58925882d5e691de79b2967b78ce94359ab4c8 Author: Milton Miller Date: Tue Mar 15 13:27:17 2011 -0600 smp_call_function_many: handle concurrent clearing of mask commit 723aae25d5cdb09962901d36d526b44d4be1051c upstream. Mike Galbraith reported finding a lockup ("perma-spin bug") where the cpumask passed to smp_call_function_many was cleared by other cpu(s) while a cpu was preparing its call_data block, resulting in no cpu to clear the last ref and unlock the block. Having cpus clear their bit asynchronously could be useful on a mask of cpus that might have a translation context, or cpus that need a push to complete an rcu window. Instead of adding a BUG_ON and requiring yet another cpumask copy, just detect the race and handle it. Note: arch_send_call_function_ipi_mask must still handle an empty cpumask because the data block is globally visible before the that arch callback is made. And (obviously) there are no guarantees to which cpus are notified if the mask is changed during the call; only cpus that were online and had their mask bit set during the whole call are guaranteed to be called. Reported-by: Mike Galbraith Reported-by: Jan Beulich Acked-by: Jan Beulich Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 41d8bc00cdfbb19da383cff529d139f8ddfe606c Author: Milton Miller Date: Tue Mar 15 13:27:16 2011 -0600 call_function_many: add missing ordering commit 45a5791920ae643eafc02e2eedef1a58e341b736 upstream. Paul McKenney's review pointed out two problems with the barriers in the 2.6.38 update to the smp call function many code. First, a barrier that would force the func and info members of data to be visible before their consumption in the interrupt handler was missing. This can be solved by adding a smp_wmb between setting the func and info members and setting setting the cpumask; this will pair with the existing and required smp_rmb ordering the cpumask read before the read of refs. This placement avoids the need a second smp_rmb in the interrupt handler which would be executed on each of the N cpus executing the call request. (I was thinking this barrier was present but was not). Second, the previous write to refs (establishing the zero that we the interrupt handler was testing from all cpus) was performed by a third party cpu. This would invoke transitivity which, as a recient or concurrent addition to memory-barriers.txt now explicitly states, would require a full smp_mb(). However, we know the cpumask will only be set by one cpu (the data owner) and any preivous iteration of the mask would have cleared by the reading cpu. By redundantly writing refs to 0 on the owning cpu before the smp_wmb, the write to refs will follow the same path as the writes that set the cpumask, which in turn allows us to keep the barrier in the interrupt handler a smp_rmb instead of promoting it to a smp_mb (which will be be executed by N cpus for each of the possible M elements on the list). I moved and expanded the comment about our (ab)use of the rcu list primitives for the concurrent walk earlier into this function. I considered moving the first two paragraphs to the queue list head and lock, but felt it would have been too disconected from the code. Cc: Paul McKinney Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9bc79b33d6e75d2b2760efb39a40e36de0587cdd Author: Milton Miller Date: Tue Mar 15 13:27:16 2011 -0600 call_function_many: fix list delete vs add race commit e6cd1e07a185d5f9b0aa75e020df02d3c1c44940 upstream. Peter pointed out there was nothing preventing the list_del_rcu in smp_call_function_interrupt from running before the list_add_rcu in smp_call_function_many. Fix this by not setting refs until we have gotten the lock for the list. Take advantage of the wmb in list_add_rcu to save an explicit additional one. I tried to force this race with a udelay before the lock & list_add and by mixing all 64 online cpus with just 3 random cpus in the mask, but was unsuccessful. Still, inspection shows a valid race, and the fix is a extension of the existing protection window in the current code. Reported-by: Peter Zijlstra Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2b9c40b666aa9d9279c22a1d648b0d9bad276909 Author: Eric Sandeen Date: Fri Mar 4 16:04:08 2011 -0600 ext3: Always set dx_node's fake_dirent explicitly. commit d7433142b63d727b5a217c37b1a1468b116a9771 upstream. (crossport of 1f7bebb9e911d870fa8f997ddff838e82b5715ea by Andreas Schlick ) When ext3_dx_add_entry() has to split an index node, it has to ensure that name_len of dx_node's fake_dirent is also zero, because otherwise e2fsck won't recognise it as an intermediate htree node and consider the htree to be corrupted. Signed-off-by: Eric Sandeen Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 0e833fda3eda25a89d68cfdda421fb24ee3596b0 Author: Josh Hunt Date: Tue Mar 15 19:16:40 2011 -0700 perf tools: Version incorrect with some versions of grep commit 58d406ed6a5f1ca4bc1dba5390b718c67847fa5f upstream. Some versions of grep don't treat '\s' properly. When building perf on such systems and using a kernel tarball the perf version is unable to be determined from the main kernel Makefile and the user is left with a version of '..'. Replacing the use of '\s' with '[[:space:]]', which should work in all grep versions, gives a usable version number. Reported-by: Tapan Dhimant Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Tapan Dhimant Cc: linux-kernel@vger.kernel.org LKML-Reference: <1300241800-30281-1-git-send-email-johunt@akamai.com> Signed-off-by: Josh Hunt Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit d36135722758275db3a6a1f3ba4b26d2c1cd4946 Author: Anton Blanchard Date: Wed Mar 9 14:38:42 2011 +1100 perf, powerpc: Handle events that raise an exception without overflowing commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 upstream. Events on POWER7 can roll back if a speculative event doesn't eventually complete. Unfortunately in some rare cases they will raise a performance monitor exception. We need to catch this to ensure we reset the PMC. In all cases the PMC will be 256 or less cycles from overflow. Signed-off-by: Anton Blanchard Signed-off-by: Peter Zijlstra LKML-Reference: <20110309143842.6c22845e@kryten> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 89fc7b8e5c2a313b248a0e4a5614774630e3c745 Author: Frederic Weisbecker Date: Mon Mar 7 21:27:09 2011 +0100 perf: Handle stopped state with tracepoints commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream. We toggle the state from start and stop callbacks but actually don't check it when the event triggers. Do it so that these callbacks actually work. Signed-off-by: Frederic Weisbecker Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras Cc: Stephane Eranian Signed-off-by: Peter Zijlstra LKML-Reference: <1299529629-18280-2-git-send-email-fweisbec@gmail.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 873a16379489db8a72ad416725c13f11c672a100 Author: Frederic Weisbecker Date: Mon Mar 7 21:27:08 2011 +0100 perf: Fix the software events state check commit 91b2f482e62ad0d444222253026a5cbca28c4ab9 upstream. Fix the mistakenly inverted check of events state. Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras Cc: Stephane Eranian LKML-Reference: <1299529629-18280-1-git-send-email-fweisbec@gmail.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1f4e44274e7d452f969a5ccaea9a00002d4eea0e Author: Stanislav Kinsbursky Date: Thu Mar 17 18:54:23 2011 +0300 RPC: killing RPC tasks races fixed commit 8e26de238fd794c8ea56a5c98bf67c40cfeb051d upstream. RPC task RPC_TASK_QUEUED bit is set must be checked before trying to wake up task rpc_killall_tasks() because task->tk_waitqueue can not be set (equal to NULL). Also, as Trond Myklebust mentioned, such approach (instead of checking tk_waitqueue to NULL) allows us to "optimise away the call to rpc_wake_up_queued_task() altogether for those tasks that aren't queued". Here is an example of dereferencing of tk_waitqueue equal to NULL: CPU 0 CPU 1 CPU 2 -------------------- --------------------- -------------------------- nfs4_run_open_task rpc_run_task rpc_execute rpc_set_active rpc_make_runnable (waiting) rpc_async_schedule nfs4_open_prepare nfs_wait_on_sequence nfs_umount_begin rpc_killall_tasks rpc_wake_up_task rpc_wake_up_queued_task spin_lock(tk_waitqueue == NULL) BUG() rpc_sleep_on spin_lock(&q->lock) __rpc_sleep_on task->tk_waitqueue = q Signed-off-by: Stanislav Kinsbursky Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit aef1b4e72dd2386b1d88190194ec370ed0d5aa24 Author: Trond Myklebust Date: Tue Mar 15 19:56:30 2011 -0400 SUNRPC: Ensure we always run the tk_callback before tk_action commit e020c6800c9621a77223bf2c1ff68180e41e8ebf upstream. This fixes a race in which the task->tk_callback() puts the rpc_task to sleep, setting a new callback. Under certain circumstances, the current code may end up executing the task->tk_action before it gets round to the callback. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 07fdde9d76f51afd29b1bd3ec1f5a7b8f5b16400 Author: Joseph Gruher Date: Wed Jan 5 16:00:21 2011 -0500 scsi_dh_alua: fix deadlock in stpg_endio commit ed0f36bc5719b25659b637f80ceea85494b84502 upstream. The use of blk_execute_rq_nowait() implies __blk_put_request() is needed in stpg_endio() rather than blk_put_request() -- blk_finish_request() is called with queue lock already held. Signed-off-by: Joseph Gruher Signed-off-by: Ilgu Hong Signed-off-by: Mike Snitzer Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 91a9f6d49d6759dccacd83358dcb7dc30ac622c7 Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:58 2011 +0100 ALSA: ctxfi - Clear input settings before initialization commit efed5f26664f93991c929d5bb343e65f900d72bc upstream. Clear input settings before initialization. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 81af2c039fde2e574b435d60f36aba262160b2ed Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:57 2011 +0100 ALSA: ctxfi - Fix SPDIF status retrieval commit f164753a263bfd2daaf3e0273b179de7e099c57d upstream. SDPIF status retrieval always returned the default settings instead of the actual ones. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1e5e9d738cdaae6f99e201fa73b42eb8a8aec67f Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:56 2011 +0100 ALSA: ctxfi - Fix incorrect SPDIF status bit mask commit 4c1847e884efddcc3ede371f7839e5e65b25c34d upstream. SPDIF status mask creation was incorrect. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bffb8879ed2e5da445a280a8869ec608f21500e1 Author: Takashi Iwai Date: Fri Mar 18 07:31:53 2011 +0100 ALSA: aloop - Fix possible IRQ lock inversion commit 98d21df431ad55281e1abf780f8d51e3391900b2 upstream. loopback_pos_update() can be called in the timer callback, thus the lock held should be irq-safe. Otherwise you'll get AB/BA deadlock together with substream->self_group.lock. Reported-and-tested-by: Knut Petersen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c8c9edfe6a04a862066dffbffe255eaae5742efc Author: Dan Rosenberg Date: Thu Mar 17 18:32:24 2011 -0400 ALSA: sound/pci/asihpi: check adapter index in hpi_ioctl commit 4a122c10fbfe9020df469f0f669da129c5757671 upstream. The user-supplied index into the adapters array needs to be checked, or an out-of-bounds kernel pointer could be accessed and used, leading to potentially exploitable memory corruption. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2de4380602b42871a073bead7153b5c662e3289a Author: Ben Hutchings Date: Thu Jan 13 19:47:56 2011 +0000 PCI: sysfs: Fix failure path for addition of "vpd" attribute commit 0f12a4e29368a9476076515881d9ef4e5876c6e2 upstream. Commit 280c73d ("PCI: centralize the capabilities code in pci-sysfs.c") changed the initialisation of the "rom" and "vpd" attributes, and made the failure path for the "vpd" attribute incorrect. We must free the new attribute structure (attr), but instead we currently free dev->vpd->attr. That will normally be NULL, resulting in a memory leak, but it might be a stale pointer, resulting in a double-free. Found by inspection; compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit f18cf02bf53c19a2a79d2f5a0d063af1c10947c3 Author: Jiri Slaby Date: Mon Feb 28 10:45:10 2011 +0100 PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICH commit 87e3dc3855430bd254370afc79f2ed92250f5b7c upstream. Some broken BIOSes on ICH4 chipset report an ACPI region which is in conflict with legacy IDE ports when ACPI is disabled. Even though the regions overlap, IDE ports are working correctly (we cannot find out the decoding rules on chipsets). So the only problem is the reported region itself, if we don't reserve the region in the quirk everything works as expected. This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO which is 0x1000. Some regions might be (and are by a fast google query) below this border, but the only difference is that they won't be reserved anymore. They should still work though the same as before. The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl): pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f] At 0x0100 a 128 bytes long ACPI region is reported in the quirk for ICH4. ata_piix then fails to find disks because the IDE legacy ports are zeroed: ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007]) References: https://bugzilla.novell.com/show_bug.cgi?id=558740 Signed-off-by: Jiri Slaby Cc: Bjorn Helgaas Cc: "David S. Miller" Cc: Thomas Renninger Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 3d5a68d981b63a5c0da644d0d3f778a61c10ec63 Author: Jiri Slaby Date: Mon Feb 28 10:45:09 2011 +0100 PCI: add more checking to ICH region quirks commit cdb9755849fbaf2bb9c0a009ba5baa817a0f152d upstream. Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN and GPIO_EN bits are set to 1. Add checks for these bits into the quirks prior to the region creation. While at it, name the constants by macros. Signed-off-by: Jiri Slaby Cc: Bjorn Helgaas Cc: "David S. Miller" Cc: Thomas Renninger Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit c54ac9788df19f413b4d4d8c3819ff8f17192613 Author: Brandeburg, Jesse Date: Mon Feb 14 09:05:02 2011 -0800 PCI: remove quirk for pre-production systems commit b99af4b002e4908d1a5cdaf424529bdf1dc69768 upstream. Revert commit 7eb93b175d4de9438a4b0af3a94a112cb5266944 Author: Yu Zhao Date: Fri Apr 3 15:18:11 2009 +0800 PCI: SR-IOV quirk for Intel 82576 NIC If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash BAR and program the SR-IOV BARs to use the old Flash Memory Space. Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet section 7.9.2.14.2 for details. http://download.intel.com/design/network/datashts/82576_Datasheet.pdf Signed-off-by: Yu Zhao Signed-off-by: Jesse Barnes This quirk was added before SR-IOV was in production and now all machines that originally had this issue alreayd have bios updates to correct the issue. The quirk itself is no longer needed and in fact causes bugs if run. Remove it. Signed-off-by: Jesse Brandeburg CC: Yu Zhao CC: Jesse Barnes Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 97e00d23b9a3da39952e4cea981eb66950fa0e98 Author: Herton Ronaldo Krzesinski Date: Wed Mar 16 14:13:53 2011 -0300 HID: add support for Ortek PKB-1700 commit 270fdc0748bd3f7b625caff985f2fcf8e2185ec7 upstream. As reported on http://ubuntuforums.org/showthread.php?t=1594007 the PKB-1700 needs same special handling as WKB-2000. This change is originally based on patch posted by user asmoore82 on the Ubuntu forums. Signed-off-by: Herton Ronaldo Krzesinski Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5f9e5a4224a4977b17caaf7bb94a76bb9ff8ed8f Author: Henrik Rydberg Date: Wed Mar 9 18:38:57 2011 +0100 HID: hid-magicmouse: Correct touch orientation direction commit 2d9ca4e9f393d81d8f37ed37505aecbf3a5e1bd6 upstream. The magic trackpad and mouse both report touch orientation in opposite direction to the bcm5974 driver and what is written in Documents/input/multi-touch-protocol.txt. This patch reverts the direction, so that all in-kernel devices with this feature behave the same way. Since no known application has been utilizing this information yet, it seems appropriate also for stable. Cc: Michael Poole Signed-off-by: Henrik Rydberg Acked-by: Chase Douglas Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0dfb740ef2e6bda849828e3bb010551dde2a56d6 Author: Takashi Iwai Date: Thu Mar 10 12:51:11 2011 +0100 ALSA: hda - Initialize special cases for input src in init phase commit 584c0c4c359bdac37d94157f8d7fc513d26c8328 upstream. Currently some special handling for the unusual case like dual-ADCs or a single-input-src is done in the tree-parse time in set_capture_mixer(). But this setup could be overwritten by static init verbs. This patch moves the initialization into the init phase so that such input-src setup won't be lost. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e54ee431f85d649c0c9a3a88cda5876be9c68104 Author: Vitaliy Kulikov Date: Wed Mar 9 19:47:43 2011 -0600 ALSA: hda - fix digital mic selection in mixer on 92HD8X codecs commit 094a42452abd5564429045e210281c6d22e67fca upstream. When the mux for digital mic is different from the mux for other mics, the current auto-parser doesn't handle them in a right way but provides only one mic. This patch fixes the issue. Signed-off-by: Vitaliy Kulikov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 15f6ea2ca7556cd9978cd79c7782d672f864ae92 Author: David Henningsson Date: Fri Mar 4 16:54:52 2011 +0100 ALSA: HDA: Realtek ALC88x: Do not over-initialize speakers and hp that are primary outputs commit 0a3fabe30e1a3b2037a12b863b8c45fffce38ee9 upstream. Do not initialize again the what has already been initialized as multi outs, as this breaks surround speakers. Tested-by: Bartłomiej Żogała Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2ea86e74bb34b67226254b99f7071af69228ec95 Author: Trond Myklebust Date: Thu Mar 17 21:54:39 2011 -0400 NFS: Fix a decoding problem in nfs3_decode_dirent [This needs to be applied to 2.6.37 only. The bug in question was inadvertently fixed by a series of cleanups in 2.6.38, but the patches in question are too large to be backported. This patch is a minimal fix that serves the same purpose.] When we decode a filename followed by an 8-byte cookie, we need to consider the fact that the filename and cookie are 32-bit word aligned. Presently, we may end up copying insufficient amounts of data when xdr_inline_decode() needs to invoke xdr_copy_to_scratch to deal with a page boundary. The following patch fixes the issue by first decoding the filename, and then decoding the cookie. Reported-by: Neil Brown Signed-off-by: Trond Myklebust Reviewed-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 076620dbeb0b3993144f4e73e16b966e7a26370f Author: Paul Zimmerman Date: Mon Feb 28 18:11:27 2011 -0800 USB: Add support for SuperSpeed isoc endpoints commit 500132a0f26ad7d9916102193cbc6c1b1becb373 upstream. Use the Mult and bMaxBurst values from the endpoint companion descriptor to calculate the max length of an isoc transfer. Add USB_SS_MULT macro to access Mult field of bmAttributes, at Sarah's suggestion. This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since those were the first kernels to have isochronous support for SuperSpeed devices. Signed-off-by: Paul Zimmerman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 729bc845266c888b2b9ad6ceaea28312ec0ad39e Author: Sarah Sharp Date: Wed Feb 23 18:12:29 2011 -0800 xhci: Fix cycle bit calculation during stall handling. commit 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 upstream. When an endpoint stalls, we need to update the xHCI host's internal dequeue pointer to move it past the stalled transfer. This includes updating the cycle bit (TRB ownership bit) if we have moved the dequeue pointer past a link TRB with the toggle cycle bit set. When we're trying to find the new dequeue segment, find_trb_seg() is supposed to keep track of whether we've passed any link TRBs with the toggle cycle bit set. However, this while loop's body while (cur_seg->trbs > trb || &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) { Will never get executed if the ring only contains one segment. find_trb_seg() will return immediately, without updating the new cycle bit. Since find_trb_seg() has no idea where in the segment the TD that stalled was, make the caller, xhci_find_new_dequeue_state(), check for this special case and update the cycle bit accordingly. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by: Sarah Sharp Tested-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5f1e1e95d04fc2159484ab3d8295d9167de846b1 Author: Sarah Sharp Date: Wed Feb 23 15:46:42 2011 -0800 xhci: Update internal dequeue pointers after stalls. commit bf161e85fb153c0dd5a95faca73fd6a9d237c389 upstream. When an endpoint stalls, the xHCI driver must move the endpoint ring's dequeue pointer past the stalled transfer. To do that, the driver issues a Set TR Dequeue Pointer command, which will complete some time later. Takashi was having issues with USB 1.1 audio devices that stalled, and his analysis of the code was that the old code would not update the xHCI driver's ring dequeue pointer after the command completes. However, the dequeue pointer is set in xhci_find_new_dequeue_state(), just before the set command is issued to the hardware. Setting the dequeue pointer before the Set TR Dequeue Pointer command completes is a dangerous thing to do, since the xHCI hardware can fail the command. Instead, store the new dequeue pointer in the xhci_virt_ep structure, and update the ring's dequeue pointer when the Set TR dequeue pointer command completes. While we're at it, make sure we can't queue another Set TR Dequeue Command while the first one is still being processed. This just won't work with the internal xHCI state code. I'm still not sure if this is the right thing to do, since we might have a case where a driver queues multiple URBs to a control ring, one of the URBs Stalls, and then the driver tries to cancel the second URB. There may be a race condition there where the xHCI driver might try to issue multiple Set TR Dequeue Pointer commands, but I would have to think very hard about how the Stop Endpoint and cancellation code works. Keep the fix simple until when/if we run into that case. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by: Sarah Sharp Tested-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3e94c3a1b0c9b4bd94c1c2a976604139f27117ac Author: Alan Stern Date: Mon Mar 7 11:11:52 2011 -0500 USB: move usbcore away from hcd->state commit 9b37596a2e860404503a3f2a6513db60c296bfdc upstream. The hcd->state variable is a disaster. It's not clearly owned by either usbcore or the host controller drivers, and they both change it from time to time, potentially stepping on each other's toes. It's not protected by any locks. And there's no mechanism to prevent it from going through an invalid transition. This patch (as1451) takes a first step toward fixing these problems. As it turns out, usbcore uses hcd->state for essentially only two things: checking whether the controller's root hub is running and checking whether the controller has died. Therefore the patch adds two new atomic bitflags to the hcd structure, to store these pieces of information. The new flags are used only by usbcore, and a private spinlock prevents invalid combinations (a dead controller's root hub cannot be running). The patch does not change the places where usbcore sets hcd->state, since HCDs may depend on them. Furthermore, there is one place in usb_hcd_irq() where usbcore still must use hcd->state: An HCD's interrupt handler can implicitly indicate that the controller died by setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a big improvement over the current code. The patch makes one other change. The hcd_bus_suspend() and hcd_bus_resume() routines now check first whether the host controller has died; if it has then they return immediately without calling the HCD's bus_suspend or bus_resume methods. This fixes the major problem reported in Bugzilla #29902: The system fails to suspend after a host controller dies during system resume. Signed-off-by: Alan Stern Tested-by: Alex Terekhov Signed-off-by: Greg Kroah-Hartman commit f2d3ab3688b54f1e1cb7998c599d806e0de0b800 Author: Matthew Garrett Date: Tue Jan 11 12:26:48 2011 -0500 ehci: Check individual port status registers on resume commit 294d95f2cbc2aef5346258f216cd9df570e271a5 upstream. If a device plug/unplug is detected on an ATI SB700 USB controller in D3, it appears to set the port status register but not the controller status register. As a result we'll fail to detect the plug event. Check the port status register on resume as well in order to catch this case. Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit dd4dd522c7fc2c1d55713c27ca30820f22e0a225 Author: Sebastian Andrzej Siewior Date: Tue Feb 8 21:07:40 2011 +0100 USB: isp1760: Implement solution for erratum 2 commit b14e840d04dba211fbdc930247e379085623eacd upstream. The document says: |2.1 Problem description | When at least two USB devices are simultaneously running, it is observed that | sometimes the INT corresponding to one of the USB devices stops occurring. This may | be observed sometimes with USB-to-serial or USB-to-network devices. | The problem is not noticed when only USB mass storage devices are running. |2.2 Implication | This issue is because of the clearing of the respective Done Map bit on reading the ATL | PTD Done Map register when an INT is generated by another PTD completion, but is not | found set on that read access. In this situation, the respective Done Map bit will remain | reset and no further INT will be asserted so the data transfer corresponding to that USB | device will stop. |2.3 Workaround | An SOF INT can be used instead of an ATL INT with polling on Done bits. A time-out can | be implemented and if a certain Done bit is never set, verification of the PTD completion | can be done by reading PTD contents (valid bit). | This is a proven workaround implemented in software. Russell King run into this with an USB-to-serial converter. This patch implements his suggestion to enable the high frequent SOF interrupt only at the time we have ATL packages queued. It goes even one step further and enables the SOF interrupt only if we have more than one ATL packet queued at the same time. Tested-by: Russell King Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman commit 8274b24b773d6433c461d38944cacc8eb8e574af Author: Felipe Contreras Date: Fri Mar 11 18:29:06 2011 -0600 staging: tidspbridge: protect dmm_map properly commit ab42abf33a3efdf754710a0a513c00c40854cd61 upstream. We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests, also, Tuomas Kulve found it happening quite often in Gumstix Over. This patch fixes those. Cc: Tuomas Kulve Signed-off-by: Felipe Contreras Signed-off-by: Omar Ramirez Luna Signed-off-by: Greg Kroah-Hartman commit 15750d67097c3c7957fbea4a5413994d5bda1de9 Author: Jeff Mahoney Date: Thu Feb 24 14:49:00 2011 -0500 staging: winbond: needs for msleep and friends commit cecf826df8648c843ea8db63b1f82c154a74db36 upstream. linux/delay.h is pulled in somehow on x86 but not on ia64 or powerpc. This fixes a build failure on those arches since they use [mu]delay. Signed-off-by: Jeff Mahoney Signed-off-by: Greg Kroah-Hartman commit a020a7f7864a09ef71797b76aafc7fe9049631b3 Author: wangyanqing Date: Fri Mar 11 06:24:38 2011 -0800 USB: serial: ch341: add new id commit d0781383038e983a63843a9a6a067ed781db89c1 upstream. I picked up a new DAK-780EX(professional digitl reverb/mix system), which use CH341T chipset to communication with computer on 3/2011 and the CH341T's vendor code is 1a86 Looking up the CH341T's vendor and product id's I see: 1a86 QinHeng Electronics 5523 CH341 in serial mode, usb to serial port converter CH341T,CH341 are the products of the same company, maybe have some common hardware, and I test the ch341.c works well with CH341T Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit de2410e4eb962baf3e48d326b0026fbd396f9d60 Author: Herton Ronaldo Krzesinski Date: Wed Mar 9 09:19:48 2011 +0000 USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626 commit 7a89e4cb9cdaba92f5fbc509945cf4e3c48db4e2 upstream. On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636091, one of the cases reported is a big timeout on option_send_setup, which causes some side effects as tty_lock is held. Looks like some of ZTE MF626 devices also don't like the RTS/DTR setting in option_send_setup, like with 4G XS Stick W14. The reporter confirms which this it solves the long freezes in his system. Signed-off-by: Herton Ronaldo Krzesinski Signed-off-by: Greg Kroah-Hartman commit 1dfa93a98e7e3f1f14d8c38a946ba43c3a479ddf Author: Jiri Slaby Date: Mon Feb 28 10:34:06 2011 +0100 USB: serial/kobil_sct, fix potential tty NULL dereference commit 6960f40a954619857e7095a6179eef896f297077 upstream. Make sure that we check the return value of tty_port_tty_get. Sometimes it may return NULL and we later dereference that. The only place here is in kobil_read_int_callback, so fix it. Signed-off-by: Jiri Slaby Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit a1afb5cb13080ca9b07096c1312f8695d9bd85d8 Author: Alan Stern Date: Wed Feb 23 15:28:18 2011 -0500 USB: serial drivers need to use larger bulk-in buffers commit 969e3033ae7733a0af8f7742ca74cd16c0857e71 upstream. When a driver doesn't know how much data a device is going to send, the buffer size should be at least as big as the endpoint's maxpacket value. The serial drivers don't follow this rule; many of them request only 256-byte bulk-in buffers. As a result, they suffer overflow errors if a high-speed device wants to send a lot of data, because high-speed bulk endpoints are required to have a maxpacket size of 512. This patch (as1450) fixes the problem by using the driver's bulk_in_size value as a minimum, always allocating buffers no smaller than the endpoint's maxpacket size. Signed-off-by: Alan Stern Tested-by: Flynn Marquardt Signed-off-by: Greg Kroah-Hartman commit 11503d7c36bb70eff71958ff8946d5b95299f988 Author: Felix Fietkau Date: Wed Mar 9 01:48:12 2011 +0100 ath9k: remove support for the FIF_PROMISC_IN_BSS filter flag commit 2e286947f1294239527c11f9f466ddce6466455b upstream. The hardware rx filter flag triggered by FIF_PROMISC_IN_BSS is overly broad and covers even frames with PHY errors. When this flag is enabled, this message shows up frequently during scanning or hardware resets: ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Since promiscuous mode is usually not particularly useful, yet enabled by default by bridging (either used normally in 4-addr mode, or with hacks for various virtualization software), we should sacrifice it for better reliability during normal operation. This patch leaves it enabled if there are active monitor mode interfaces, since it's very useful for debugging. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c2ba18104706630ec6e25e0ae7b07e0be048f981 Author: Senthil Balasubramanian Date: Wed Dec 22 21:14:20 2010 +0530 ath9k_hw: Fix incorrect macversion and macrev checks commit ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e upstream. There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Signed-off-by: Senthil Balasubramanian Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 39780ab15d48a88ca4652d3630808150e4ca2e5f Author: Senthil Balasubramanian Date: Wed Dec 22 19:17:18 2010 +0530 ath9k_hw: read and backup AR_WA register value even before chip reset on. commit 0a8d7cb0c8182df7a28ad719780071178c386f0f upstream. We need to read and backup AR_WA register value permanently and reading this after the chip is awakened results in this register being zeroed out. This seems to fix the ASPM with L1 enabled issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. Signed-off-by: Senthil Balasubramanian Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2bad0a40b93b87a0ebc4c789ad6defe04b3ee8d9 Author: Chris Wilson Date: Tue Mar 15 11:40:00 2011 +0000 drm: Hold the mode mutex whilst probing for sysfs status commit 007c80a5497a3f9c8393960ec6e6efd30955dcb1 upstream. As detect will use hw registers and may modify structures, it needs to be serialised by use of the dev->mode_config.mutex. Make it so. Otherwise, we may cause random crashes as the sysfs file is queried whilst a concurrent hotplug poll is being run. For example: [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100 [ 1189.189821] IP: [] intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.190020] *pde = 00000000 [ 1189.190104] Oops: 0000 [#1] SMP [ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status [ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 1189.192007] [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701 [ 1189.192007] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004 [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000) [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00 [ 1189.192007] e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e [ 1189.192007] 30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000 [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007] [] ? intel_tv_detect+0x89/0x12d [i915] [ 1189.192007] [] ? status_show+0x0/0x2f [drm] [ 1189.192007] [] ? status_show+0x14/0x2f [drm] [Digression: what is upowerd doing reading those power hungry files?] Reported-by: Paul Menzel Signed-off-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit db66d7a2baa3cecb38ea4383d803b51f2c448641 Author: Tetsuo Handa Date: Wed Mar 2 16:54:24 2011 +0900 TOMOYO: Fix memory leak upon file open. commit eae61f3c829439f8f9121b5cd48a14be04df451f upstream. In tomoyo_check_open_permission() since 2.6.36, TOMOYO was by error recalculating already calculated pathname when checking allow_rewrite permission. As a result, memory will leak whenever a file is opened for writing without O_APPEND flag. Also, performance will degrade because TOMOYO is calculating pathname regardless of profile configuration. This patch fixes the leak and performance degrade. Signed-off-by: Tetsuo Handa Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit c5c858261f3e55e16a7b9c1e54a275c0012519c3 Author: Mathieu Desnoyers Date: Thu Mar 3 11:01:37 2011 -0500 x86: stop_machine_text_poke() should issue sync_core() commit 0e00f7aed6af21fc09b2a94d28bc34e449bd3a53 upstream. Intel Archiecture Software Developer's Manual section 7.1.3 specifies that a core serializing instruction such as "cpuid" should be executed on _each_ core before the new instruction is made visible. Failure to do so can lead to unspecified behavior (Intel XMC erratas include General Protection Fault in the list), so we should avoid this at all cost. This problem can affect modified code executed by interrupt handlers after interrupt are re-enabled at the end of stop_machine, because no core serializing instruction is executed between the code modification and the moment interrupts are reenabled. Because stop_machine_text_poke performs the text modification from the first CPU decrementing stop_machine_first, modified code executed in thread context is also affected by this problem. To explain why, we have to split the CPUs in two categories: the CPU that initiates the text modification (calls text_poke_smp) and all the others. The scheduler, executed on all other CPUs after stop_machine, issues an "iret" core serializing instruction, and therefore handles core serialization for all these CPUs. However, the text modification initiator can continue its execution on the same thread and access the modified text without any scheduler call. Given that the CPU that initiates the code modification is not guaranteed to be the one actually performing the code modification, it falls into the XMC errata. Q: Isn't this executed from an IPI handler, which will return with IRET (a serializing instruction) anyway? A: No, now stop_machine uses per-cpu workqueue, so that handler will be executed from worker threads. There is no iret anymore. Signed-off-by: Mathieu Desnoyers LKML-Reference: <20110303160137.GB1590@Krystal> Reviewed-by: Masami Hiramatsu Cc: Arjan van de Ven Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Andrew Morton Cc: Andi Kleen Cc: Frederic Weisbecker Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 643023b097159a1d887278b0e84b30cd19de8ca0 Author: Steven J. Magnani Date: Thu Feb 10 12:12:13 2011 -0600 microblaze: Fix /dev/zero corruption from __clear_user() commit 6f3946b421395ff853bc0bcdab9c26b50ebbba8f upstream. A userland read of more than PAGE_SIZE bytes from /dev/zero results in (a) not all of the bytes returned being zero, and (b) memory corruption due to zeroing of bytes beyond the user buffer. This is caused by improper constraints on the assembly __clear_user function. The constrints don't indicate to the compiler that the pointer argument is modified. Since the function is inline, this results in double-incrementing of the pointer when __clear_user() is invoked through a multi-page read() of /dev/zero. Signed-off-by: Steven J. Magnani Acked-by: Michal Simek Signed-off-by: Greg Kroah-Hartman commit ded2c8bd9568be9dc8bfacaf63927b8b624737da Author: Andreas Herrmann Date: Tue Mar 15 15:31:37 2011 +0100 x86, quirk: Fix SB600 revision check commit 1d3e09a304e6c4e004ca06356578b171e8735d3c upstream. Commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 (x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems) introduced a regression. It removed some SB600 specific code to determine the revision ID without adapting a corresponding revision ID check for SB600. See this mail thread: http://marc.info/?l=linux-kernel&m=129980296006380&w=2 This patch adapts the corresponding check to cover all SB600 revisions. Tested-by: Wang Lei Signed-off-by: Andreas Herrmann Cc: Andrew Morton LKML-Reference: <20110315143137.GD29499@alberich.amd.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 35e6f483095855c0efcf9da7c82f138f3ea04e15 Author: Sean Hefty Date: Wed Feb 23 08:17:40 2011 -0800 IB/cm: Bump reference count on cm_id before invoking callback commit 29963437a48475036353b95ab142bf199adb909e upstream. When processing a SIDR REQ, the ib_cm allocates a new cm_id. The refcount of the cm_id is initialized to 1. However, cm_process_work will decrement the refcount after invoking all callbacks. The result is that the cm_id will end up with refcount set to 0 by the end of the sidr req handler. If a user tries to destroy the cm_id, the destruction will proceed, under the incorrect assumption that no other threads are referencing the cm_id. This can lead to a crash when the cm callback thread tries to access the cm_id. This problem was noticed as part of a larger investigation with kernel crashes in the rdma_cm when running on a real time OS. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 91999d4336fc7c94635cb10e254813a35bd3157e Author: Linus Torvalds Date: Wed Mar 16 08:04:07 2011 -0700 Increase OSF partition limit from 8 to 18 commit 34d211a2d5df4984a35b18d8ccacbe1d10abb067 upstream. It turns out that while a maximum of 8 partitions may be what people "should" have had, you can actually fit up to 18 entries(*) in a sector. And some people clearly were taking advantage of that, like Michael Cree, who had ten partitions on one of his OSF disks. (*) The OSF partition data starts at byte offset 64 in the first sector, and the array of 16-byte partition entries start at offset 148 in the on-disk partition structure. Reported-by: Michael Cree Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1ca3a935992de6b8da9725377b8667bab22de38e Author: Sean Hefty Date: Wed Feb 23 08:11:32 2011 -0800 RDMA/cma: Fix crash in request handlers commit 25ae21a10112875763c18b385624df713a288a05 upstream. Doug Ledford and Red Hat reported a crash when running the rdma_cm on a real-time OS. The crash has the following call trace: cm_process_work cma_req_handler cma_disable_callback rdma_create_id kzalloc init_completion cma_get_net_info cma_save_net_info cma_any_addr cma_zero_addr rdma_translate_ip rdma_copy_addr cma_acquire_dev rdma_addr_get_sgid ib_find_cached_gid cma_attach_to_dev ucma_event_handler kzalloc ib_copy_ah_attr_to_user cma_comp [ preempted ] cma_write copy_from_user ucma_destroy_id copy_from_user _ucma_find_context ucma_put_ctx ucma_free_ctx rdma_destroy_id cma_exch cma_cancel_operation rdma_node_get_transport rt_mutex_slowunlock bad_area_nosemaphore oops_enter They were able to reproduce the crash multiple times with the following details: Crash seems to always happen on the: mutex_unlock(&conn_id->handler_mutex); as conn_id looks to have been freed during this code path. An examination of the code shows that a race exists in the request handlers. When a new connection request is received, the rdma_cm allocates a new connection identifier. This identifier has a single reference count on it. If a user calls rdma_destroy_id() from another thread after receiving a callback, rdma_destroy_id will proceed to destroy the id and free the associated memory. However, the request handlers may still be in the process of running. When control returns to the request handlers, they can attempt to access the newly created identifiers. Fix this by holding a reference on the newly created rdma_cm_id until the request handler is through accessing it. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 873cd78f82db88cac1109a45a348248fcd4a84de Author: Tejun Heo Date: Thu Feb 24 19:30:37 2011 +0100 libata: fix hotplug for drivers which don't implement LPM commit eb0e85e36b971ec31610eda7e3ff5c11c1c44785 upstream. ata_eh_analyze_serror() suppresses hotplug notifications if LPM is being used because LPM generates spurious hotplug events. It compared whether link->lpm_policy was different from ATA_LPM_MAX_POWER to determine whether LPM is enabled; however, this is incorrect as for drivers which don't implement LPM, lpm_policy is always ATA_LPM_UNKNOWN. This disabled hotplug detection for all drivers which don't implement LPM. Fix it by comparing whether lpm_policy is greater than ATA_LPM_MAX_POWER. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 5618c45b73c413eba6b4504ec41eea4f9117fd03 Author: Seth Heasley Date: Fri Mar 11 11:57:42 2011 -0800 ahci: AHCI mode SATA patch for Intel Patsburg SATA RAID controller commit 64a3903d0885879ba8706a8bcf71c5e3e7664db2 upstream. This patch adds an updated SATA RAID DeviceID for the Intel Patsburg PCH. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 9841bf488c347c51c2f92a33347c993fa4822da8 Author: Seth Heasley Date: Mon Jan 10 12:57:17 2011 -0800 ahci: AHCI mode SATA patch for Intel DH89xxCC DeviceIDs commit a4a461a6df6c0481d5a3d61660ed97f5b539cf16 upstream. This patch adds the AHCI-mode SATA DeviceID for the Intel DH89xxCC PCH. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit c1375ee971e9e994a91b8aa8cd4b06e61178a407 Author: Per Jessen Date: Tue Feb 8 13:54:32 2011 +0100 ahci: recognize Marvell 88se9125 PCIe SATA 6.0 Gb/s controller commit 467b41c688c79d1b5e076fbdf082f9cd5d6a000c upstream. Recognize Marvell 88SE9125 PCIe SATA 6.0 Gb/s controller. Signed-off-by: Per Jessen Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit d085c79399fce9fb34195f21c22286a62fd16e9a Author: Kamal Mostafa Date: Thu Feb 3 17:38:05 2011 -0800 x86: Emit "mem=nopentium ignored" warning when not supported commit 9a6d44b9adb777ca9549e88cd55bd8f2673c52a2 upstream. Emit warning when "mem=nopentium" is specified on any arch other than x86_32 (the only that arch supports it). Signed-off-by: Kamal Mostafa BugLink: http://bugs.launchpad.net/bugs/553464 Cc: Yinghai Lu Cc: Len Brown Cc: Rafael J. Wysocki LKML-Reference: <1296783486-23033-2-git-send-email-kamal@canonical.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 474d7937c9436faeaf8e29f32e8a94cdb0293c9d Author: Kamal Mostafa Date: Thu Feb 3 17:38:04 2011 -0800 x86: Fix panic when handling "mem={invalid}" param commit 77eed821accf5dd962b1f13bed0680e217e49112 upstream. Avoid removing all of memory and panicing when "mem={invalid}" is specified, e.g. mem=blahblah, mem=0, or mem=nopentium (on platforms other than x86_32). Signed-off-by: Kamal Mostafa BugLink: http://bugs.launchpad.net/bugs/553464 Cc: Yinghai Lu Cc: Len Brown Cc: Rafael J. Wysocki LKML-Reference: <1296783486-23033-1-git-send-email-kamal@canonical.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8d94010a78908645e0cd99d2381053ab42fe7abb Author: Steven Rostedt Date: Thu Feb 10 21:26:13 2011 -0500 ftrace: Fix memory leak with function graph and cpu hotplug commit 868baf07b1a259f5f3803c1dc2777b6c358f83cf upstream. When the fuction graph tracer starts, it needs to make a special stack for each task to save the real return values of the tasks. All running tasks have this stack created, as well as any new tasks. On CPU hot plug, the new idle task will allocate a stack as well when init_idle() is called. The problem is that cpu hotplug does not create a new idle_task. Instead it uses the idle task that existed when the cpu went down. ftrace_graph_init_task() will add a new ret_stack to the task that is given to it. Because a clone will make the task have a stack of its parent it does not check if the task's ret_stack is already NULL or not. When the CPU hotplug code starts a CPU up again, it will allocate a new stack even though one already existed for it. The solution is to treat the idle_task specially. In fact, the function_graph code already does, just not at init_idle(). Instead of using the ftrace_graph_init_task() for the idle task, which that function expects the task to be a clone, have a separate ftrace_graph_init_idle_task(). Also, we will create a per_cpu ret_stack that is used by the idle task. When we call ftrace_graph_init_idle_task() it will check if the idle task's ret_stack is NULL, if it is, then it will assign it the per_cpu ret_stack. Reported-by: Benjamin Herrenschmidt Suggested-by: Peter Zijlstra Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 12e210970c50960edc77f459402cf12a53964ab0 Author: Andrey Vagin Date: Wed Mar 9 15:22:23 2011 -0800 x86/mm: Handle mm_fault_error() in kernel space commit f86268549f424f83b9eb0963989270e14fbfc3de upstream. mm_fault_error() should not execute oom-killer, if page fault occurs in kernel space. E.g. in copy_from_user()/copy_to_user(). This would happen if we find ourselves in OOM on a copy_to_user(), or a copy_from_user() which faults. Without this patch, the kernels hangs up in copy_from_user(), because OOM killer sends SIG_KILL to current process, but it can't handle a signal while in syscall, then the kernel returns to copy_from_user(), reexcute current command and provokes page_fault again. With this patch the kernel return -EFAULT from copy_from_user(). The code, which checks that page fault occurred in kernel space, has been copied from do_sigbus(). This situation is handled by the same way on powerpc, xtensa, tile, ... Signed-off-by: Andrey Vagin Signed-off-by: Andrew Morton Cc: "H. Peter Anvin" Cc: Linus Torvalds LKML-Reference: <201103092322.p29NMNPH001682@imap1.linux-foundation.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 9c949bdbcfa14eea4bbd9a568a8b620da4d4ee63 Author: Naga Chumbalkar Date: Fri Feb 25 20:31:55 2011 +0000 x86: Don't check for BIOS corruption in first 64K when there's no need to commit a7bd1dafdcc13ec7add4aafc927eb5e3a8d597e6 upstream. Due to commit 781c5a67f152c17c3e4a9ed9647f8c0be6ea5ae9 it is likely that the number of areas to scan for BIOS corruption is 0 -- especially when the first 64K is already reserved (X86_RESERVE_LOW is 64K by default). If that's the case then don't set up the scan. Signed-off-by: Naga Chumbalkar LKML-Reference: <20110225202838.2229.71011.sendpatchset@nchumbalkar.americas.hpqcorp.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f80e8b97a1fa31519c256a65587bcb1b5920985a Author: Andrea Arcangeli Date: Wed Feb 16 15:45:22 2011 -0800 x86/mm: Fix pgd_lock deadlock commit a79e53d85683c6dd9f99c90511028adc2043031f upstream. It's forbidden to take the page_table_lock with the irq disabled or if there's contention the IPIs (for tlb flushes) sent with the page_table_lock held will never run leading to a deadlock. Nobody takes the pgd_lock from irq context so the _irqsave can be removed. Signed-off-by: Andrea Arcangeli Acked-by: Rik van Riel Tested-by: Konrad Rzeszutek Wilk Signed-off-by: Andrew Morton Cc: Peter Zijlstra Cc: Linus Torvalds LKML-Reference: <201102162345.p1GNjMjm021738@imap1.linux-foundation.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 0bd4cf63832c3a4a02c16a8d2e50b39545eee6fb Author: Florian Fainelli Date: Sun Feb 27 19:53:53 2011 +0100 MIPS: MTX-1: Make au1000_eth probe all PHY addresses commit bf3a1eb85967dcbaae42f4fcb53c2392cec32677 upstream. When au1000_eth probes the MII bus for PHY address, if we do not set au1000_eth platform data's phy_search_highest_address, the MII probing logic will exit early and will assume a valid PHY is found at address 0. For MTX-1, the PHY is at address 31, and without this patch, the link detection/speed/duplex would not work correctly. Signed-off-by: Florian Fainelli To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/2111/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 5eac80b1296c5326888307ab76af00e9f8d535f8 Author: Jovi Zhang Date: Wed Mar 2 23:19:37 2011 +0000 nfs: fix compilation warning commit 43b7c3f051dea504afccc39bcb56d8e26c2e0b77 upstream. this commit fix compilation warning as following: linux-2.6/fs/nfs/nfs4proc.c:3265: warning: comparison of distinct pointer types lacks a cast Signed-off-by: Jovi Zhang Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7e676247795f86efe5ca97c556f9c21415f815ee Author: Lukas Czerner Date: Fri Mar 11 10:23:53 2011 +0100 block: fix mis-synchronisation in blkdev_issue_zeroout() commit 0aeea18964173715a1037034ef6838198f319319 upstream. BZ29402 https://bugzilla.kernel.org/show_bug.cgi?id=29402 We can hit serious mis-synchronization in bio completion path of blkdev_issue_zeroout() leading to a panic. The problem is that when we are going to wait_for_completion() in blkdev_issue_zeroout() we check if the bb.done equals issued (number of submitted bios). If it does, we can skip the wait_for_completition() and just out of the function since there is nothing to wait for. However, there is a ordering problem because bio_batch_end_io() is calling atomic_inc(&bb->done) before complete(), hence it might seem to blkdev_issue_zeroout() that all bios has been completed and exit. At this point when bio_batch_end_io() is going to call complete(bb->wait), bb and wait does not longer exist since it was allocated on stack in blkdev_issue_zeroout() ==> panic! (thread 1) (thread 2) bio_batch_end_io() blkdev_issue_zeroout() if(bb) { ... if (bb->end_io) ... bb->end_io(bio, err); ... atomic_inc(&bb->done); ... ... while (issued != atomic_read(&bb.done)) ... (let issued == bb.done) ... (do the rest of the function) ... return ret; complete(bb->wait); ^^^^^^^^ panic We can fix this easily by simplifying bio_batch and completion counting. Also remove bio_end_io_t *end_io since it is not used. Signed-off-by: Lukas Czerner Reported-by: Eric Whitney Tested-by: Eric Whitney Reviewed-by: Jeff Moyer CC: Dmitry Monakhov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7cc775c711787ca3a1c113c14f6105d2f89f965c Author: Takashi Iwai Date: Fri Mar 11 12:34:41 2011 +0100 drm/i915: Fix calculation of backlight value in combined mode commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0 upstream. [The upstream commit above is a combination of revert + one-liner fix. This patch contains only the latter that is needed for 2.6.37.x.] This patch fixes the backlight level calculation for combination mode used in some models like GM45. It's due to a wrong bit shift introduced by the commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870 drm/i915: Refactor panel backlight controls Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23472 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=672946 Signed-off-by: Takashi Iwai commit d078eae3ade297434429b86e4eb44f8f66aef712 Author: Johannes Stezenbach Date: Mon Dec 13 12:32:49 2010 +0100 rt2x00: fix hang when unplugging USB device in use commit d7bb5f845f437662296adbfeaab8fbfce1c32289 upstream. When an rt2x00 USB device is unplugged while in use, it reliably hangs the whole system. After some time the watchdog prints: BUG: soft lockup - CPU#0 stuck for 64s! [kworker/u:0:5] ... [] (usb_submit_urb+0x0/0x2ac) from [] (rt2x00usb_kick_rx_entry+0xb4/0xe8 [rt2x00usb]) [] (rt2x00usb_kick_rx_entry+0x0/0xe8 [rt2x00usb]) from [] (rt2x00usb_clear_entry+x28/0x2c [rt2x00usb]) [] (rt2x00usb_clear_entry+0x0/0x2c [rt2x00usb]) from [] (rt2x00lib_rxdone+0x2e0/0x2f8 [rt2x00lib]) [] (rt2x00lib_rxdone+0x0/0x2f8 [rt2x00lib]) from [] (rt2x00usb_work_rxdone+0x54/0x74 [rt2x00usb]) [] (rt2x00usb_work_rxdone+0x0/0x74 [rt2x00usb]) from [] (process_one_work+0x20c/0x35c) Clear the DEVICE_STATE_PRESENT flag when usb_submit_urb() returns -ENODEV to fix this. Signed-off-by: Johannes Stezenbach Signed-off-by: Ivo van Doorn Signed-off-by: John W. Linville Cc: Stanislaw Gruszka Signed-off-by: Greg Kroah-Hartman commit 730a268a1c3d9aa0ced3d4acf448259c778c5de7 Author: Ivo van Doorn Date: Thu Nov 4 20:41:05 2010 +0100 rt2x00: Fix crash on USB unplug commit 070192dd2975c0e97bbdeac7623b755235c6db7d upstream. By not scheduling the TX/RX completion worker threads when Radio is disabled, or hardware has been unplugged, the queues cannot be completely cleaned. This causes crashes when the hardware has been unplugged while the radio is still enabled. Signed-off-by: Ivo van Doorn Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Cc: Stanislaw Gruszka Signed-off-by: Greg Kroah-Hartman commit 71c36cc2a9ef5622024b1ca84a000ecd76e5cc13 Author: Pablo Neira Ayuso Date: Thu Jan 6 11:25:00 2011 -0800 netfilter: fix export secctx error handling commit cba85b532e4aabdb97f44c18987d45141fd93faa upstream. In 1ae4de0cdf855305765592647025bde55e85e451, the secctx was exported via the /proc/net/netfilter/nf_conntrack and ctnetlink interfaces instead of the secmark. That patch introduced the use of security_secid_to_secctx() which may return a non-zero value on error. In one of my setups, I have NF_CONNTRACK_SECMARK enabled but no security modules. Thus, security_secid_to_secctx() returns a negative value that results in the breakage of the /proc and `conntrack -L' outputs. To fix this, we skip the inclusion of secctx if the aforementioned function fails. This patch also fixes the dynamic netlink message size calculation if security_secid_to_secctx() returns an error, since its logic is also wrong. This problem exists in Linux kernel >= 2.6.37. Signed-off-by: Pablo Neira Ayuso Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 64bb48e4e88b52e05e36b8b0d033a17fa9102962 Author: Chris Mason Date: Mon Mar 7 11:10:24 2011 -0500 Btrfs: deal with short returns from copy_from_user commit 31339acd07b4ba687906702085127895a56eb920 upstream. When copy_from_user is only able to copy some of the bytes we requested, we may end up creating a partially up to date page. To avoid garbage in the page, we need to treat a partial copy as a zero length copy. This makes the rest of the file_write code drop the page and retry the whole copy instead of marking the partially up to date page as dirty. Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 67725123d5df7aace72676b94e1bdffbdbbc0f75 Author: Timo Warns Date: Mon Mar 14 14:59:33 2011 +0100 Fix corrupted OSF partition table parsing commit 1eafbfeb7bdf59cfe173304c76188f3fd5f1fd05 upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating OSF partitions contains a bug that leaks data from kernel heap memory to userspace for certain corrupted OSF partitions. In more detail: for (i = 0 ; i < le16_to_cpu(label->d_npartitions); i++, partition++) { iterates from 0 to d_npartitions - 1, where d_npartitions is read from the partition table without validation and partition is a pointer to an array of at most 8 d_partitions. Add the proper and obvious validation. Signed-off-by: Timo Warns [ Changed the patch trivially to not repeat the whole le16_to_cpu() thing, and to use an explicit constant for the magic value '8' ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7713ab22e90f782af5747e738ebb33ea94f67cf0 Author: Chuck Lever Date: Fri Mar 11 15:31:06 2011 -0500 NFS: NFSROOT should default to "proto=udp" commit 53d4737580535e073963b91ce87d4216e434fab5 upstream. There have been a number of recent reports that NFSROOT is no longer working with default mount options, but fails only with certain NICs. Brian Downing bisected to commit 56463e50 "NFS: Use super.c for NFSROOT mount option parsing". Among other things, this commit changes the default mount options for NFSROOT to use TCP instead of UDP as the underlying transport. TCP seems less able to deal with NICs that are slow to initialize. The system logs that have accompanied reports of problems all show that NFSROOT attempts to establish a TCP connection before the NIC is fully initialized, and thus the TCP connection attempt fails. When a TCP connection attempt fails during a mount operation, the NFS stack needs to fail the operation. Usually user space knows how and when to retry it. The network layer does not report a distinct error code for this particular failure mode. Thus, there isn't a clean way for the RPC client to see that it needs to retry in this case, but not in others. Because NFSROOT is used in some environments where it is not possible to update the kernel command line to specify "udp", the proper thing to do is change NFSROOT to use UDP by default, as it did before commit 56463e50. To make it easier to see how to change default mount options for NFSROOT and to distinguish default settings from mandatory settings, I've adjusted a couple of areas to document the specifics. root_nfs_cat() is also modified to deal with commas properly when concatenating strings containing mount option lists. This keeps root_nfs_cat() call sites simpler, now that we may be concatenating multiple mount option strings. Tested-by: Brian Downing Tested-by: Mark Brown Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 3d24afb103de9a869c574d7d27d04d8c74d1b211 Author: Ben Hutchings Date: Tue Feb 22 21:54:34 2011 +0000 sunrpc: Propagate errors from xs_bind() through xs_create_sock() commit 4cea288aaf0e11647880cc487350b1dc45d9febc upstream. xs_create_sock() is supposed to return a pointer or an ERR_PTR-encoded error, but it currently returns 0 if xs_bind() fails. Signed-off-by: Ben Hutchings Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit b0b9f804f5f9e59fe6d192633a3014afc1b62ab3 Author: Mark Brown Date: Wed Mar 2 11:01:18 2011 +0000 ASoC: Fix broken bitfield definitions in WM8978 commit 823dba5191220fc94b83dc0b3f2178ff0842e294 upstream. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman commit 73b700aa0682ebfbe9be1ffd759ff457b1ae79d0 Author: Joakim Tjernlund Date: Mon Feb 7 17:07:11 2011 +0100 mtd: fix race in cfi_cmdset_0001 driver commit ecf3fde07c8dcb92a1bf3fbdfe70905d85cd00e1 upstream. As inval_cache_and_wait_for_operation() drop and reclaim the lock to invalidate the cache, some other thread may suspend the operation before reaching the for(;;) loop. Therefore the loop must start with checking the chip->state before reading status from the chip. Signed-off-by: Joakim Tjernlund Acked-by: Michael Cashwell Acked-by: Stefan Bigler Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 30b42e4aff84734185f703c6e703421d196801c3 Author: Maxim Levitsky Date: Sun Jan 9 01:25:06 2011 +0200 mtd: mtd_blkdevs: fix double free on error path commit bd637f6f22235b4613f9ab6555e8088a455c1ed4 upstream. This one liner patch fixes double free that will occur if add_mtd_blktrans_dev fails. On failure it frees the input argument, but all its users also free it on error which is natural thing to do. Thus don't free it. All credit for finding that bug belongs to reporters of the bug in the android bugzilla http://code.google.com/p/android/issues/detail?id=13761 Commit message tweaked by Artem. Signed-off-by: Maxim Levitsky Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 5f4cd26f5139f5a10ccb414d804f132d4f0a1781 Author: Axel Lin Date: Mon Mar 7 11:04:24 2011 +0800 mtd: add "platform:" prefix for platform modalias commit c804c733846572ca85c2bba60c7fe6fa024dff18 upstream. Since 43cc71eed1250755986da4c0f9898f9a635cb3bf (platform: prefix MODALIAS with "platform:"), the platform modalias is prefixed with "platform:". Signed-off-by: Axel Lin Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit f8c332b31d1048a34cf6d6197d094076b8e39e64 Author: Antony Pavlov Date: Fri Feb 11 13:00:37 2011 +0300 mtd: jedec_probe: initialise make sector erase command variable commit ceabebb2bd2672f709e4454e16bc6042732e2dfe upstream. In the commit 08968041bef437ec363623cd3218c2b083537ada (mtd: cfi_cmdset_0002: make sector erase command variable) introdused a field sector_erase_cmd. In the same commit initialisation of cfi->sector_erase_cmd made in cfi_chip_setup() (file drivers/mtd/chips/cfi_probe.c), so the CFI chip has no problem: ... cfi->cfi_mode = CFI_MODE_CFI; cfi->sector_erase_cmd = CMD(0x30); ... But for the JEDEC chips this initialisation is not carried out, so the JEDEC chips have sector_erase_cmd == 0. This patch adds the missing initialisation. Signed-off-by: Antony Pavlov Acked-by: Guillaume LECERF Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 663c4358da748c42d7bc9faa5a6d506653861c51 Author: Antony Pavlov Date: Fri Feb 11 13:00:37 2011 +0300 mtd: jedec_probe: Change variable name from cfi_p to cfi commit efba2e313ea1b1bd69a7c4659263becf43bb1adc upstream. In the following commit, we'll need to use the CMD() macro in order to fix the initialisation of the sector_erase_cmd field. That requires the local variable to be called 'cfi', so change it first in a simple patch. Signed-off-by: Antony Pavlov Acked-by: Guillaume LECERF Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit ee3f3c5169e4d4669c61abe194d40c445bcadcbd Author: Hans de Goede Date: Sun Mar 13 13:50:33 2011 +0100 hwmon/f71882fg: Set platform drvdata to NULL later commit d9ebaa45472c92704f4814682eec21455edcfa1f upstream. This avoids a possible race leading to trying to dereference NULL. Signed-off-by: Hans de Goede Acked-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman