- 05 Jul, 2010 40 commits
-
-
Tejun Heo authored
commit 8b27ff4c upstream. vt6421 has problems talking to recent WD drives. It causes a lot of transmission errors while high bandwidth transfer as reported in the following bugzilla entry. https://bugzilla.kernel.org/show_bug.cgi?id=15173 Joseph Chan provided the following fix. I don't have any idea what it does but I can verify the issue is gone with the patch applied. Signed-off-by:
Tejun Heo <tj@kernel.org> Originally-from: Joseph Chan <JosephChan@via.com.tw> Reported-by:
Jorrit Tijben <sjorrit@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tejun Heo authored
commit f3faf8fc upstream. On mcp55, nIEN gets stuck once set and liteon blueray rom iHOS104-08 violates ATA specification and fails to set I on D2H Reg FIS if nIEN is set when the command was issued. When the other party is following the spec, both devices can work fine but when the two flaws are put together, they can't talk to each other. mcp55 has its own IRQ masking mechanism and there's no reason to mess with nIEN in the first place. Fix it by dropping nIEN diddling from nv_mcp55_freeze/thaw(). This was originally reported by Cengiz. Although Cengiz hasn't verified the fix yet, I could reproduce this problem and verfiy the fix. Even if Cengiz is experiencing different or additional problems, this patch is needed. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Cengiz Günay <cgunay@emory.edu> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stephane Eranian authored
commit 4b24a88b upstream. If reserve_pmc_hardware() succeeds but reserve_ds_buffers() fails, then we need to release_pmc_hardware. It won't be done by the destroy() callback because we return before setting it in case of error. Signed-off-by:
Stephane Eranian <eranian@google.com> Cc: peterz@infradead.org Cc: paulus@samba.org Cc: davem@davemloft.net Cc: fweisbec@gmail.com Cc: robert.richter@amd.com Cc: perfmon2-devel@lists.sf.net LKML-Reference: <4ba1568b.15185e0a.182a.7802@mx.google.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stefan Richter authored
commit 10389536 upstream. Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check whether the current IRM complies to 1394a-2000 or later. If not force a compliant node (e.g. itself) to become IRM. This was implemented in the older ieee1394 driver but not yet in firewire-core. An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM but neither 1394a-2000 IRM nor BM was now found to cause an interoperability bug: - Camcorder becomes root node when plugged in, hence gets IRM role. - firewire-core successfully contends for BM role, proceeds to perform gap count optimization and resets the bus. - Sony camcorder ignores presence of a BM (against the spec, this is a firmware bug), performs its idea of gap count optimization and resets the bus. - Preceding two steps are repeated endlessly, bus never settles, regular I/O is practically impossible. http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913 This is an interoperability regression from the old to the new drivers. Fix it indirectly by adding the 1394a IRM check. The spec suggests three and a half methods to determine 1394a compliance of a remote IRM; we choose the method of testing the Config_ROM.Bus_Info.generation field. This is data that firewire-core should have readily available at this point, i.e. does not require extra I/O. Reported-by: Clemens Ladisch <clemens@ladisch.de> (missing 1394a check) Reported-by: H. S. <hs.samix@gmail.com> (issue with Sony DCR-TRV25) Tested-by:
H. S. <hs.samix@gmail.com> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tejun Heo authored
commit 4daedcfe upstream. JMB362 is a new variant of jmicron controller which is similar to JMB360 but has two SATA ports instead of one. As there is no PATA port, single function AHCI mode can be used as in JMB360. Add pci quirk for JMB362. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Aries Lee <arieslee@jmicron.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Bob Copeland authored
commit 6b5dcccb upstream. Commit 56d1de0a, "ath5k: clean up filter flags setting" introduced a regression in monitor mode such that the promisc filter flag would get lost. Although we set the promisc flag when it changed, we did not preserve it across subsequent calls to configure_filter. This patch restores the original functionality. Bisected-by: weedy2887@gmail.com Tested-by: weedy2887@gmail.com Tested-by:
Rick Farina <sidhayn@gmail.com> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Paul Mundt authored
commit f4d7c356 upstream. Based on the sh_tmu change in 66f49121 ("clocksource: sh_tmu: compute mult and shift before registration"). The same issues impact the sh_cmt driver, so we take the same approach here. Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Martin Homuth-Rosemann authored
commit ebe86223 upstream. Correct at least one of the incorrect specs for a national instrument data acquisition card DAQCard-6024E. This card has only four different gain settings (+-10V, +-5V, +-0.5V, +-0.05V). Signed-off-by:
Martin Homuth-Rosemann <homuth-rosemann@gmx.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel T Chen authored
commit 9f75c1b1 upstream. BugLink: https://launchpad.net/bugs/587546 Symptom: On the reporter's ASUS M2V, using PulseAudio in Ubuntu 10.04 LTS results in the PA daemon crashing shortly after attempting playback of an audio file. Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or Linux 2.6.34, attempt playback of an audio file while PulseAudio is active. Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method. Reported-and-Tested-By: D Tangman Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel T Chen authored
commit b90c0764 upstream. BugLink: https://launchpad.net/bugs/580749 Symptom: on the original reporter's VIA VT1708-based board, the PulseAudio daemon dies shortly after the user attempts to play an audio file. Test case: boot from Ubuntu 10.04 LTS live cd; attempt to play an audio file. Resolution: add SSID for the original reporter's hardware to the position_fix quirk table, explicitly specifying the LPIB method. Reported-and-Tested-By: Harald Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel T Chen authored
commit 26fd74fc upstream. BugLink: https://launchpad.net/bugs/542550 Symptom: On the reporter's iMac, in Ubuntu 10.04 LTS neither playback nor capture appear audible out-of-the-box. Test case: Boot from an Ubuntu 10.04 LTS live cd or from an installed configuration and attempt to play or capture audio. Resolution: Specify the mb31 quirk for this machine in the codec SSID table. Reported-and-Tested-By: f3a97 Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel T Chen authored
commit dd37f8e8 upstream. BugLink: https://launchpad.net/bugs/465942 Symptom: On the reporter's ASUS device, using PulseAudio in Ubuntu 10.04 LTS results in the PA daemon crashing shortly after attempting to select capture or to configure the audio hardware profile. Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or Linux 2.6.34, adjust the HDA device's capture volume with PulseAudio. Resolution: add SSID for this machine to the position_fix quirk table, explicitly specifying the LPIB method. Reported-and-Tested-By: Irihapeti Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ian Campbell authored
commit b3831cb5 upstream. Since the device we are resuming could be the device containing the swap device we should ensure that the allocation cannot cause IO. On resume, this path is triggered when the running system tries to continue using its devices. If it cannot then the resume will fail; to try to avoid this we let it dip into the emergency pools. The majority of these changes were made when linux-2.6.18-xen.hg changeset e8b49cfbdac0 was ported upstream in a144ff09 but somehow this hunk was dropped. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Acked-by:
Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ian Campbell authored
commit cd52e17e upstream. The core suspend/resume code is run from stop_machine on CPU0 but parts of the suspend/resume machinery (including xen_arch_resume) are run on whichever CPU happened to schedule the xenwatch kernel thread. As part of the non-core resume code xen_arch_resume is called in order to restart the timer tick on non-boot processors. The boot processor itself is taken care of by core timekeeping code. xen_arch_resume uses smp_call_function which does not call the given function on the current processor. This means that we can end up with one CPU not receiving timer ticks if the xenwatch thread happened to be scheduled on CPU > 0. Use on_each_cpu instead of smp_call_function to ensure the timer tick is resumed everywhere. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Acked-by:
Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Gabor Gombas authored
commit 3d6e77a3 upstream. The low-memory corruption checker triggers during suspend/resume, so we need to reserve the low 64k. Don't be fooled that the BIOS identifies itself as "Dell Inc.", it's still Phoenix BIOS. [ hpa: I think we blacklist almost every BIOS in existence. We should either change this to a whitelist or just make it unconditional. ] Signed-off-by:
Gabor Gombas <gombasg@digikabel.hu> LKML-Reference: <201005241913.o4OJDIMM010877@imap1.linux-foundation.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Kosina authored
commit a747c5ab upstream. If run_to_completion flag is set, it means that we are running in a single-threaded mode, and thus no locks are held. This fixes a deadlock when IPMI notifier is being called during panic. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Acked-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jeff Moyer authored
commit 91803b49 upstream. I/O errors can happen due to temporary failures, like multipath errors or losing network contact with the iSCSI server. Because of that, the VM will retry readpage on the page. However, do_generic_file_read does not clear PG_error. This causes the system to be unable to actually use the data in the page cache page, even if the subsequent readpage completes successfully! The function filemap_fault has had a ClearPageError before readpage forever. This patch simply adds the same to do_generic_file_read. Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Rik van Riel <riel@redhat.com> Acked-by:
Larry Woodman <lwoodman@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Oleg Nesterov authored
commit 065add39 upstream. Andrew Tridgell reports that aio_read(SIGEV_SIGNAL) can fail if the notification from the helper thread races with setresuid(), see http://samba.org/~tridge/junkcode/aio_uid.c This happens because check_kill_permission() doesn't permit sending a signal to the task with the different cred->xids. But there is not any security reason to check ->cred's when the task sends a signal (private or group-wide) to its sub-thread. Whatever we do, any thread can bypass all security checks and send SIGKILL to all threads, or it can block a signal SIG and do kill(gettid(), SIG) to deliver this signal to another sub-thread. Not to mention that CLONE_THREAD implies CLONE_VM. Change check_kill_permission() to avoid the credentials check when the sender and the target are from the same thread group. Also, move "cred = current_cred()" down to avoid calling get_current() twice. Note: David Howells pointed out we could relax this even more, the CLONE_SIGHAND (without CLONE_THREAD) case probably does not need these checks too. Roland said: : The glibc (libpthread) that does set*id across threads has : been in use for a while (2.3.4?), probably in distro's using kernels as old : or older than any active -stable streams. In the race in question, this : kernel bug is breaking valid POSIX application expectations. Reported-by:
Andrew Tridgell <tridge@samba.org> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Roland McGrath <roland@redhat.com> Acked-by:
David Howells <dhowells@redhat.com> Cc: Eric Paris <eparis@parisplace.org> Cc: Jakub Jelinek <jakub@redhat.com> Cc: James Morris <jmorris@namei.org> Cc: Roland McGrath <roland@redhat.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ira W. Snyder authored
commit df16dd53 upstream. Read only one of the GPIO pins as an analog voltage. The ADC can be switched to a different GPIO pin at runtime, but this is not supported. Previously, this driver would report the analog voltage of the currently selected GPIO pin as all three GPIO voltages: in9_input, in10_input and in11_input. Signed-off-by:
Ira W. Snyder <iws@ovro.caltech.edu> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dave Airlie authored
commit cf22f20a upstream. airlied -> brown paper bag. I blame Hi-5 or the Wiggles for lowering my IQ, move the fix inside some brackets instead of breaking everything in site. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dave Airlie authored
commit 566d84d1 upstream. radeon's have a special ability to passthrough writes in their internal memory space directly to PCI, this ability means that if some of the internal surfaces like the depth buffer point at 0x0, any writes to these will go directly to RAM at 0x0 via PCI busmastering. Now mesa used to always emit clears after emitting state, since the radeon mesa driver was refactored a year or more ago, it was found it could generate a clear request without ever sending any setup state to the card. So the clear would attempt to clear the depth buffer at 0x0, which would overwrite main memory at this point. fs corruption ensues. Also once one app did this correctly, it would never get set back to 0 making this messy to reproduce. The kernel should block this from happening as mesa runs without privs, though it does require the user be connected to the current running X session. This patch implements a check to make sure the depth offset has been set before a depth clear occurs and if it finds one it prints a warning and ignores the depth clear request. There is also a mesa fix to avoid sending the badness going into mesa. This only affects r100/r200 GPUs in user modesetting mode. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mark Brown authored
commit f68596c6 upstream. These should be regular, not linear. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mark Brown authored
commit 3351e9fb upstream. These scales should be regular, not linear. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mark Brown authored
commit e6a08c5a upstream. These should be regular rather than linear scales. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Russell King authored
commit 138de1c4 upstream. vfp_put_double() takes the double value in r0,r1 not r1,r2. Reported-by:
Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Linus Walleij authored
commit ea208f64 upstream. This fixes a bug in mm/init.c when freeing the TCM compile memory, this was being referred to as a char * which is incorrect: this will dereference the pointer and feed in the value at the location instead of the address to it. Change it to a plain char and use &(char) to reference it. Signed-off-by:
Linus Walleij <linus.walleij@stericsson.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Marek Vašut authored
commit 3defb247 upstream. This patch reorganises the sa1111_resume() function in a manner the spinlock happens after calling the sa1111_wake(). This fixes two bugs: 1) This function called sa1111_wake() which tried to claim the same spinlock the sa1111_resume() already claimed. This would result in certain deadlock. Original idea for this part: Russell King <rmk+kernel@arm.linux.org.uk> 2) The function didn't unlock the spinlock in case the chip didn't report correct ID. Original idea for this part: Julia Lawall <julia@diku.dk> Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Khem Raj authored
commit 9a40ac86 upstream. When functions incoming parameters are not in input operands list gcc 4.5 does not load the parameters into registers before calling this function but the inline assembly assumes valid addresses inside this function. This breaks the code because r0 and r1 are invalid when execution enters v4wb_copy_user_page () Also the constant needs to be used as third input operand so account for that as well. Tested on qemu arm. Signed-off-by:
Khem Raj <raj.khem@gmail.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Anfei authored
commit 5e27fb78 upstream. Instruction faults on pre-ARMv6 CPUs are interpreted as a 'translation fault', but do_translation_fault doesn't handle well if user mode trying to run instruction above TASK_SIZE, and result in the infinite retry of that instruction. Signed-off-by:
Anfei Zhou <anfei.zhou@gmail.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sebastien Dugue authored
commit c0dc72ba upstream. If the number of sg entries in the ICM chunk reaches MLX4_ICM_CHUNK_LEN, we must set chunk to NULL even for coherent mappings so that the next time through the loop will allocate another chunk. Otherwise we'll overflow the sg list the next time through the loop. This will lead to memory corruption if this case is hit. mthca does not have this bug. Signed-off-by:
Sebastien Dugue <sebastien.dugue@bull.net> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
KOSAKI Motohiro authored
commit e9d6c157 upstream. Shaohua Li reported parallel file copy on tmpfs can lead to OOM killer. This is regression of caused by commit 9ff473b9 ("vmscan: evict streaming IO first"). Wow, It is 2 years old patch! Currently, tmpfs file cache is inserted active list at first. This means that the insertion doesn't only increase numbers of pages in anon LRU, but it also reduces anon scanning ratio. Therefore, vmscan will get totally confused. It scans almost only file LRU even though the system has plenty unused tmpfs pages. Historically, lru_cache_add_active_anon() was used for two reasons. 1) Intend to priotize shmem page rather than regular file cache. 2) Intend to avoid reclaim priority inversion of used once pages. But we've lost both motivation because (1) Now we have separate anon and file LRU list. then, to insert active list doesn't help such priotize. (2) In past, one pte access bit will cause page activation. then to insert inactive list with pte access bit mean higher priority than to insert active list. Its priority inversion may lead to uninteded lru chun. but it was already solved by commit 64574746 (vmscan: detect mapped file pages used only once). (Thanks Hannes, you are great!) Thus, now we can use lru_cache_add_anon() instead. Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reported-by:
Shaohua Li <shaohua.li@intel.com> Reviewed-by:
Wu Fengguang <fengguang.wu@intel.com> Reviewed-by:
Johannes Weiner <hannes@cmpxchg.org> Reviewed-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
FUJITA Tomonori authored
commit 76b99699 upstream. Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
FUJITA Tomonori authored
commit 498900fc upstream. Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Chris Zankel <chris@zankel.net> Acked-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
FUJITA Tomonori authored
commit 69dcf3db upstream. Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by:
David Howells <dhowells@redhat.com> Acked-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Maurus Cuelenaere authored
commit e893de59 upstream. s3c_rtc_setfreq() uses the platform driver data to derive struct rtc_device, so make sure drvdata is set _before_ s3c_rtc_setfreq() is called. Signed-off-by:
Maurus Cuelenaere <mcuelenaere@gmail.com> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Maurus Cuelenaere <mcuelenaere@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit 6ba8bcd4 upstream. The bug is an oops when dev_get_drvdata() returned null in cmos_update_irq_enable(). The call tree looks like this: rtc_dev_ioctl() => rtc_update_irq_enable() => cmos_update_irq_enable() It's caused by a race condition in the module initialization. It is rtc_device_register() which makes the ioctl operations live so I moved the call to dev_set_drvdata() before the call to rtc_device_register(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15963Reported-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Dan Carpenter <error27@gmail.com> Tested-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Cc: Malte Schroder <maltesch@gmx.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
FUJITA Tomonori authored
commit dd6c26a6 upstream. Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Acked-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
FUJITA Tomonori authored
commit 6cdafaae upstream. Architectures that handle DMA-non-coherent memory need to set ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the buffer doesn't share a cache with the others. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by:
David Howells <dhowells@redhat.com> Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> Acked-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dan Carpenter authored
commit ddf08f4b upstream. For kmap_atomic() we call kunmap_atomic() on the returned pointer. That's different from kmap() and kunmap() and so it's easy to get them backwards. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Joerg Roedel authored
This is a suspend resume fix for 2.6.32-stable inclusion. The problem with this patch is that it is not upstream because the code changed with 2.6.33 and the function where this bug is in was removed. So this fix does not make sense anymore for anything later than 2.6.32. The patch was tested by multiple partys and is confirmed to fix the broken suspend/resume issue with the 2.6.32 kernel. This patch fixes suspend/resume with AMD IOMMU enabled. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-