- 23 Nov, 2009 1 commit
-
-
Joerg Roedel authored
This function may be called on the resume path and can not be dropped after booting. Cc: stable@kernel.org Signed-off-by:Joerg Roedel <joerg.roedel@amd.com>
-
- 17 Nov, 2009 5 commits
-
-
Ingo Molnar authored
Clean up various small stylistic details in the GART code. No functionality changed. Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: muli@il.ibm.com Cc: joerg.roedel@amd.com LKML-Reference: <1258287594-8777-2-git-send-email-fujita.tomonori@lab.ntt.co.jp> Signed-off-by:Ingo Molnar <mingo@elte.hu>
-
FUJITA Tomonori authored
This cleans up iommu_alloc() a bit and removes unnecessary DMA_ERROR_CODE usage. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Cc: muli@il.ibm.com Cc: joerg.roedel@amd.com LKML-Reference: <1258287594-8777-4-git-send-email-fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
-
FUJITA Tomonori authored
This kills bad_dma_address variable, the old mechanism to enable IOMMU drivers to make dma_mapping_error() work in IOMMU's specific way. bad_dma_address variable was introduced to enable IOMMU drivers to make dma_mapping_error() work in IOMMU's specific way. However, it can't handle systems that use both swiotlb and HW IOMMU. SO we introduced dma_map_ops->mapping_error to solve that case. Intel VT-d, GART, and swiotlb already use dma_map_ops->mapping_error. Calgary, AMD IOMMU, and nommu use zero for an error dma address. This adds DMA_ERROR_CODE and converts them to use it (as SPARC and POWER does). Signed-off-by:
-
FUJITA Tomonori authored
GART IOMMU is the only user of bad_dma_address variable. This patch converts GART to use the newer mechanism, fill in ->mapping_error() in struct dma_map_ops, to make dma_mapping_error() work in IOMMU specific way. Signed-off-by:
-
Ingo Molnar authored
Merge reason: Add fixes we'll depend on. Signed-off-by:
-
- 16 Nov, 2009 1 commit
-
-
Hiroshi Shimamoto authored
It causes kernel panic on shutdown or reboot. Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Acked-by:
-
- 15 Nov, 2009 4 commits
-
-
FUJITA Tomonori authored
This makes calgary_iommu_init() static and moves it to remove the forward declaration. Signed-off-by:
-
FUJITA Tomonori authored
Signed-off-by:
-
FUJITA Tomonori authored
iommu_init_noop() is in arch/x86/kernel/x86_init.c but iommu_shutdown_noop() in arch/x86/include/asm/iommu.h. This moves iommu_shutdown_noop() to x86_init.c for consistency. Signed-off-by:
-
FUJITA Tomonori authored
We set dma_ops to nommu_dma_ops at two different places for x86_32 and x86_64. This unifies them by setting dma_ops to nommu_dma_ops by default. Signed-off-by:
-
- 13 Nov, 2009 1 commit
-
-
Linus Torvalds authored
-
- 12 Nov, 2009 28 commits
-
-
Linus Torvalds authored
Merge branch 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 * 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: omap3: Decrease cpufreq transition latency omap3: update Pandora defconfig omap3: 3430sdp: Enable Linux Regulator framework omap3: beagle: Fix USB host port power control omap3: pandora: Fix keypad keymap omap1: Amstrad Delta defconfig fixes omap: Fix omapfb/lcdc on OMAP1510 broken when PM set omap: Use resource_size omap: Fix race condition in omap dma driver
-
Mike Hommey authored
Because of an integer overflow on start_blk, various kind of wrong results would be returned by the generic_block_fiemap() handler, such as no extents when there is a 4GB+ hole at the beginning of the file, or wrong fe_logical when an extent starts after the first 4GB. Signed-off-by:
Mike Hommey <mh@glandium.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Eric Sandeen <sandeen@sgi.com> Cc: Josef Bacik <jbacik@redhat.com> Cc: Mark Fasheh <mfasheh@suse.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Rodolfo Giometti authored
PPS events must be recorded according to PPS's mode settings. If a process asks for (i.e.) capture-assert events only, when the PPS client calls the pps_event() function to save the current PPS event, we should verify the event type and then discard unwanted ones. Also, without this patch userland processes waiting for a specific PPS event (assert or clear but not both) may be awakened at wrong time. Signed-off-by:
Rodolfo Giometti <giometti@linux.it> Tested-by:
William S. Brasher <billb958@door.net> Tested-by:
Reg Clemens <clemens@dwf.com> Cc: <stable@kernel.org> Signed-off-by:
-
Rodolfo Giometti authored
Userland programs may read/write PPS parameters at same time and these operations may corrupt PPS data. Signed-off-by:
-
Pavel Machek authored
TASK_INTERRUPTIBLE and friends are now only available after including <linux/sched.h>, so include it when needed. bus_id is no longer available/necessary, so remove that. Android pmem driver is not available in mainline, so remove its hooks from drivers/video. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Sergei Shtylyov authored
In case of failure, device_create() returns not NULL but the error code. The current code checks for non-NULL though which causes kernel oops in sysfs_create_group() when device_create() fails. Check for error using IS_ERR() and propagate the error value using PTR_ERR() instead of fixed -ENODEV code returned now... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Scott Valentine authored
v3020_mmio_read_bit() always returns 0 when left_shift > 7. v3020_mmio_read_bit()'s return type is (unsigned char). The code returns a value masked by (1 << left_shift) that is casted to the return type. If left_shift is larger than 7, the cast will always result in a 0 return value. The problem was discovered with left_shift = 16, and the included patch corrects the problem. The bug was introduced in the last (Apr 3 2009) commit of the file, kernel versions 2.6.30 and later. Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Cc: Raphael Assenat <raph@8d.com> Cc: <stable@kernel.org> Signed-off-by:
-
Yoichi Yuasa authored
drivers/rtc/rtc-vr41xx.c: In function 'vr41xx_rtc_irq_set_freq': drivers/rtc/rtc-vr41xx.c:217: warning: comparison of distinct pointer types lacks a cast drivers/rtc/rtc-vr41xx.c:217: warning: right shift count >= width of type drivers/rtc/rtc-vr41xx.c:217: warning: passing argument 1 of '__div64_32' from incompatible pointer type include/asm-generic/div64.h:35: note: expected 'uint64_t *' but argument is of type 'long unsigned int *' Signed-off-by:
Yoichi Yuasa <yuasa@linux-mips.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Anton Blanchard authored
In setup_arg_pages we work hard to assign a value to ret, but on exit we always return 0. Also remove a now duplicated exit path and branch to out_unlock instead. Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
Serge Hallyn <serue@us.ibm.com> Reviewed-by:
WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
-
Guennadi Liakhovetski authored
The config FB_PRE_INIT_FB entry in drivers/video/Kconfig pushes all entries below it out of the menuconfig selection. Fix this. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Joe Perches authored
Use git.kernel.org not www.kernel.org Signed-off-by:
Joe Perches <joe@perches.com> Cc: James Morris <jmorris@namei.org> Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Ladislav Michl authored
Free IRQ on remove. Signed-off-by:
Ladislav Michl <ladis@linux-mips.org> Acked-by:
Tony Lindgren <tony@atomide.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Lennert Buytenhek authored
This seems to be a different model (with a different PCI ID) than the "Quatro" card that is also in the list. Signed-off-by:
Lennert Buytenhek <buytenh@wantstofly.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Lennert Buytenhek authored
struct uart_port::iobase is unsigned long, so use %lx as printk format specifier. Signed-off-by:
-
Werner Almesberger authored
According to Documentation/rtc.txt, RTC_WKALM_SET sets the alarm time and enables/disables the alarm. We implement RTC_WKALM_SET through pcf50633_rtc_set_alarm. The enabling/disabling part was missing. Signed-off-by:
Werner Almesberger <werner@openmoko.org> Reported-by:
Michael 'Mickey' Lauer <mickey@openmoko.org> Signed-off-by:
Paul Fertser <fercerpav@gmail.com> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Cc: Balaji Rao <balajirrao@openmoko.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Rask Ingemann Lambertsen authored
The PCF50633 stores a month value of 1-12, but the kernel wants 0-11. Signed-off-by:
Rask Ingemann Lambertsen <rask@sygehus.dk> Signed-off-by:
-
Nicolas Ferre authored
at91sam9g45 non ES lots have an alternate pixel clock calculation formula. Introduce this one with condition on the cpu_is_xxxxx() macros. Newer 9g45 SOC will not have good pixel clock calculation without this fix. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by:
-
Heiko Carstens authored
For FS_IOC_RESVSP and FS_IOC_RESVSP64 compat_sys_ioctl() uses its arg argument as a pointer to userspace. However it is missing a a call to compat_ptr() which will do a proper pointer conversion. This was introduced with 3e63cbb1 "fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls". Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Ankit Jain <me@ankitjain.org> Acked-by:
Christoph Hellwig <hch@lst.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Arnd Bergmann <arndbergmann@googlemail.com> Acked-by:
David S. Miller <davem@davemloft.net> Cc: <stable@kernel.org> [2.6.31.x] Signed-off-by:
-
Sukadev Bhattiprolu authored
Daniel Lezcano reported a leak in 'struct pid' and 'struct pid_namespace' that is discussed in: http://lkml.org/lkml/2009/10/2/159. To summarize the thread, when container-init is terminated, it sets the PF_EXITING flag, zaps other processes in the container and waits to reap them. As a part of reaping, the container-init should flush any /proc dentries associated with the processes. But because the container-init is itself exiting and the following PF_EXITING check, the dentries are not flushed, resulting in leak in /proc inodes and dentries. This fix reverts the commit 7766755a ("Fix /proc dcache deadlock in do_exit") which introduced the check for PF_EXITING. At the time of the commit, shrink_dcache_parent() flushed dentries from other filesystems also and could have caused a deadlock which the commit fixed. But as pointed out by Eric Biederman, after commit 0feae5c4, shrink_dcache_parent() no longer affects other filesystems. So reverting the commit is now safe. As pointed out by Jan Kara, the leak is not as critical since the unclaimed space will be reclaimed under memory pressure or by: echo 3 > /proc/sys/vm/drop_caches But since this check is no longer required, its best to remove it. Signed-off-by:
Sukadev Bhattiprolu <sukadev@us.ibm.com> Reported-by:
Daniel Lezcano <dlezcano@fr.ibm.com> Acked-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
Jan Kara <jack@ucw.cz> Cc: Andrea Arcangeli <andrea@cpushare.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: <stable@kernel.org> Signed-off-by:
-
Andrew Morton authored
arch/alpha/kernel/vmlinux.lds.S uses it: arch/alpha/kernel/vmlinux.lds:241: undefined symbol `THREAD_SIZE' referenced in expression Seems to have been caused by commit 9d93f005 Author: Geoffrey Thomas <geofft@ksplice.com> AuthorDate: Thu Sep 24 10:36:26 2009 -0400 Commit: Linus Torvalds <torvalds@linux-foundation.org> CommitDate: Thu Sep 24 17:16:22 2009 -0700 alpha: Clean up linker script using new linker script macros. Note that .data.page_aligned and .data.cacheline_aligned are now after _data; it was probably a bug that they were before it. Also, some explicit ALIGN(8)'s between various initcall sections were removed; this should be harmless as the implicit alignment of initcall_t was already 8. Cc: Geoffrey Thomas <geofft@ksplice.com> Cc: Tim Abbott <tabbott@ksplice.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by:
-
Peter Zijlstra authored
Fix a bug in commit ba0a6c9f Author: Peter Zijlstra <a.p.zijlstra@chello.nl> AuthorDate: Wed Sep 23 15:57:03 2009 -0700 Commit: Linus Torvalds <torvalds@linux-foundation.org> CommitDate: Thu Sep 24 07:21:01 2009 -0700 fcntl: add F_[SG]ETOWN_EX In asm-generic/fcntl.h, F_SETOWN_EX and F_GETLK64 both have value 12, and F_GETOWN_EX and F_SETLK64 both have value 13. Reported-by:"Joseph S. Myers" <joseph@codesourcery.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Andreas Schwab <schwab@redhat.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Ulrich Drepper <drepper@redhat.com> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Lee Schermerhorn reported that he saw bad pointer dereference in mem_cgroup_end_migration() when he disabled memcg by boot option. memcg's page migration logic works as mem_cgroup_prepare_migration(page, &ptr); do page migration mem_cgroup_end_migration(page, ptr); Now, ptr is not initialized in prepare_migration when memcg is disabled by boot option. This causes panic in end_migration. This patch fixes it. Reported-by:
Lee Schermerhorn <Lee.Schermerhorn@hp.com> Cc: Balbir Singh <balbir@in.ibm.com> Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Cc: <stable@kernel.org> Signed-off-by:
-
Krzysztof Helt authored
Fix wrong bit mask for blanking register. Due to the error a CRT monitor blanks off due to wrong frequency (out of range) instead of PM signal (vertical and horizontal frequencies cut off). Just compare the mask with bits set in the switch(blank) clause below the changed line. Signed-off-by:
Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by:
-
Krzysztof Helt authored
Remove fb_save_state() and fb_restore_state operations from frame buffer layer. They are used only in two drivers: 1. savagefb - and cause bug #11248 2. uvesafb Usage of these operations is misunderstood in both drivers so kill these operations, fix the bug #11248 and avoid confusion in the future. Tested on Savage 3D/MV card and the patch fixes the bug #11248. The frame buffer layer uses these funtions during switch between graphics and text mode of the console, but these drivers saves state before switching of the frame buffer (in the fb_open) and after releasing it (in the fb_release). This defeats the purpose of these operations. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11248Signed-off-by:
Jochen Hein <jochen@jochen.org> Tested-by:
-
Mel Gorman authored
Commit 341ce06f ("page allocator: calculate the alloc_flags for allocation only once") altered watermark logic slightly by allowing rt_tasks that are handling an interrupt to set ALLOC_HARDER. This patch brings the watermark logic more in line with 2.6.30. This change results in a reduction of the number high-order GFP_ATOMIC allocation failures reported. See http://www.gossamer-threads.com/lists/linux/kernel/1144153 [rientjes@google.com: Spotted the problem] Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Reviewed-by:
Pekka Enberg <penberg@cs.helsinki.fi> Reviewed-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: David Rientjes <rientjes@google.com> Cc: <stable@kernel.org> Signed-off-by:
-
Mel Gorman authored
page allocator: always wake kswapd when restarting an allocation attempt after direct reclaim failed If a direct reclaim makes no forward progress, it considers whether it should go OOM or not. Whether OOM is triggered or not, it may retry the allocation afterwards. In times past, this would always wake kswapd as well but currently, kswapd is not woken up after direct reclaim fails. For order-0 allocations, this makes little difference but if there is a heavy mix of higher-order allocations that direct reclaim is failing for, it might mean that kswapd is not rewoken for higher orders as much as it did previously. This patch wakes up kswapd when an allocation is being retried after a direct reclaim failure. It would be expected that kswapd is already awake, but this has the effect of telling kswapd to reclaim at the higher order as well. Signed-off-by:
Christoph Lameter <cl@linux-foundation.org> Reviewed-by:
-
