- 12 Mar, 2009 12 commits
-
-
Mark Brown authored
No software visible difference from revision A. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Samuel Ortiz <sameo@openedhand.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Michael Spang authored
Currently we disable the Acer WMI backlight device if there is no ACPI backlight device. As a result, we end up with no backlight device at all. We should instead disable it if there is an ACPI device, as the other laptop drivers do. This regression was introduced in febf2d95 ("Acer-WMI: fingers off backlight if video.ko is serving this functionality"). Each laptop driver with backlight support got a similar change around febf2d95. The changes to the other drivers look correct; see e.g. a598c82f for a similar but correct change. The regression is also in 2.6.28. Signed-off-by:
Michael Spang <mspang@csclub.uwaterloo.ca> Acked-by:
Thomas Renninger <trenn@suse.de> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Carlos Corbacho <carlos@strangeworlds.co.uk> Cc: Len Brown <len.brown@intel.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: <stable@kernel.org> [2.6.28.x] Signed-off-by:
-
Ben Dooks authored
The s3cmci driver is calling s3c2410_dma_config with incorrect data for the DCON register. The S3C2410_DCON_HWTRIG is implicit in the channel configuration and the device selection of S3C2410_DCON_CH0_SDI is incorrect as the DMA system may not select channel 0. Signed-off-by:
Ben Dooks <ben@simtec.co.uk> Acked-by:
Pierre Ossman <drzeus@drzeus.cx> Signed-off-by:
-
Michael Kerrisk authored
Unfortunately, Linux Foundation funding for my work on man-pages/testing/doc under the auspices of the LF documentation fellowship unfortunately ran out a short while ago (after earlier attempts to seek funding, only Google stepped forward with a bit of further funding for the position), so the patch below acknowledges something closer to reality. Unfortunately, there will (probably very) soon be a further downgrade from "Maintained" to "Odd Fixes" or "Orphan", unless some funding miracle occurs. So, if anyone is looking to become man-pages maintainer, there may soon be an opening (okay, don't trample me in the rush ;-).) Signed-off-by:
Michael Kerrisk <mtk.manpages@googlemail.com> Signed-off-by:
-
Daniel Mack authored
The 'battery remaining capacity' calculation in drivers/power/ds2760_battery.c lacks a parameter check to a division operation which causes the kernel to oops on my board. [ 21.233750] Division by zero in kernel. [ 21.237646] [<c002955c>] (__div0+0x0/0x20) from [<c012561c>] (Ldiv0+0x8/0x10) [ 21.244816] [<c01bef34>] (ds2760_battery_read_status+0x0/0x2a4) from [<c01bf3a4>] (ds2760_battery_get_property+0x30/0xdc) [ 21.255803] r8:c03a22c0 r7:c7886100 r6:00000009 r5:c782fe7c r4:c7886084 [ 21.262518] [<c01bf374>] (ds2760_battery_get_property+0x0/0xdc) from [<c01bde98>] (power_supply_show_property+0x48/0x114) [ 21.273480] r6:c7996000 r5:00000009 r4:00000000 [ 21.278111] [<c01bde50>] (power_supply_show_property+0x0/0x114) from [<c01be158>] (power_supply_uevent+0x188/0x280) [ 21.288537] r8:00000001 r7:c7886100 r6:c7996000 r5:000000b4 r4:00000000 [ 21.295222] [<c01bdfd0>] (power_supply_uevent+0x0/0x280) from [<c015c664>] (dev_uevent+0xd4/0x10c) [ 21.304199] [<c015c590>] (dev_uevent+0x0/0x10c) from [<c0128440>] (kobject_uevent_env+0x180/0x390) [ 21.313170] r5:00000000 r4:c78860ac [ 21.316725] [<c01282c0>] (kobject_uevent_env+0x0/0x390) from [<c0128664>] (kobject_uevent+0x14/0x18) [ 21.325850] [<c0128650>] (kobject_uevent+0x0/0x18) from [<c01bdc34>] (power_supply_changed_work+0x5c/0x70) [ 21.335506] [<c01bdbd8>] (power_supply_changed_work+0x0/0x70) from [<c004d290>] (run_workqueue+0xbc/0x144) [ 21.345167] r4:c7812040 [ 21.347716] [<c004d1d4>] (run_workqueue+0x0/0x144) from [<c004d94c>] (worker_thread+0xa8/0xbc) [ 21.356296] r7:c7812040 r6:c7820b00 r5:c782ffa4 r4:c7812048 [ 21.361957] [<c004d8a4>] (worker_thread+0x0/0xbc) from [<c0051008>] (kthread+0x5c/0x94) [ 21.369971] r7:00000000 r6:c004d8a4 r5:c7812040 r4:c782e000 [ 21.375612] [<c0050fac>] (kthread+0x0/0x94) from [<c00403d0>] (do_exit+0x0/0x688) Signed-off-by:
Daniel Mack <daniel@caiaq.de> Cc: Szabolcs Gyurko <szabolcs.gyurko@tlt.hu> Acked-by:
Matt Reimer <mreimer@vpop.net> Acked-by:
Anton Vorontsov <cbou@mail.ru> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Li Zefan authored
In sget(), destroy_super(s) is called with s->s_umount held, which makes lockdep unhappy. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Menage <menage@google.com> Signed-off-by:
-
Oleg Nesterov authored
If the second fasync_helper() fails, pipe_rdwr_fasync() returns the error but leaves the file on ->fasync_readers. This was always wrong, but since 233e70f4 "saner FASYNC handling on file close" we have the new problem. Because in this case setfl() doesn't set FASYNC bit, __fput() will not do ->fasync(0), and we leak fasync_struct with ->fa_file pointing to the freed file. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Andi Kleen <andi@firstfloor.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Daniel Mack authored
W1 master implementations are expected to return 0 or 1 from their read_bit() function. However, not all platforms do return these values from gpio_get_value() - namely PXAs won't. Hence the w1 gpio-master needs to break the result down to 0 or 1 itself. Signed-off-by:
-
akpm@linux-foundation.org authored
Fix the following warning on x86_64: LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux: 'memcpy' exported twice. Previous export was in vmlinux For x86_64, this symbol is already exported from arch/um/sys-x86_64/ksyms.c. Reported-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
WANG Cong <xiyou.wangcong@gmail.com> Tested-by:
-
Renzo Davoli authored
It is currently impossible to run a user-mode linux machine inside another user-mode linux (UML on UML). It breaks after a few instructions. When it tries to check whether SYSEMU is installed (the inner) UML receives an inconsistent result (from the outer UML). This is the output of a broken attempt: $ ./linux mem=256m ubd0=cow Locating the bottom of the address space ... 0x0 Locating the top of the address space ... 0xc0000000 Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking ptrace new tags for syscall emulation...unsupported Checking syscall emulation patch for ptrace...check_sysemu : expected SIGTRAP, got status = 256 $ The problem is the following: PTRACE_SYSCALL/SINGLESTEP is currently managed inside arch_ptrace for ARCH=um. PTRACE_SYSEMU/SUSEMU_SINGLESTEP is not captured in arch_ptrace's switch, therefore it is erroneously passed back to ptrace_request (in kernel/ptrace). This simple patch simply forces ptrace to return an error on PTRACE_SYSEMU/SUSEMU_SINGLESTEP as it is unsupported on ARCH=um, and fixes the problem. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:Renzo Davoli <renzo@cs.unibo.it> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sunhme: Fix qfe parent detection. sparc64: Fix lost interrupts on sun4u. sparc64: wait_event_interruptible_timeout may return -ERESTARTSYS jsflash: stop defining MAJOR_NR
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: MIPS: IP27: Enable RAID5 module MIPS: TXx9: update defconfigs MIPS: NEC VR5500 processor support fixup MIPS: Fix build of non-CONFIG_SYSVIPC version of sys_32_ipc
-
- 11 Mar, 2009 18 commits
-
-
git://oss.sgi.com/xfs/xfsLinus Torvalds authored
* 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: only issues a cache flush on unmount if barriers are enabled xfs: prevent lockdep false positive in xfs_iget_cache_miss xfs: prevent kernel crash due to corrupted inode log format
-
Ralf Baechle authored
Signed-off-by:Ralf Baechle <ralf@linux-mips.org>
-
Atsushi Nemoto authored
Enable following features: * MTD (PHYSMAP) * LED (LEDS_GPIO) * RBTX4939 * 7SEGLED * IDE (IDE_TX4938, IDE_TX4939) * SMC91X * RTC_DRV_TX4939 Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
-
Shinya Kuribayashi authored
Current VR5500 processor support lacks of some functions which are expected to be configured/synthesized on arch initialization. Here're some VR5500A spec notes: * All execution hazards are handled in hardware. * Once VR5500A stops the operation of the pipeline by WAIT instruction, it could return from the standby mode only when either a reset, NMI request, or all enabled interrupts is/are detected. In other words, if interrupts are disabled by Status.IE=0, it keeps in standby mode even when interrupts are internally asserted. Notes on WAIT: The operation of the processor is undefined if WAIT insn is in the branch delay slot. The operation is also undefined if WAIT insn is executed when Status.EXL and Status.ERL are set to 1. * VR5500A core only implements the Load prefetch. With these changes, it boots fine. Signed-off-by:
Shinya Kuribayashi <shinya.kuribayashi@necel.com> Signed-off-by:
-
Xiaotian Feng authored
Signed-off-by:
Xiaotian Feng <xiaotian.feng@windriver.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm: fix EDID parser problem with positive/negative hsync/vsync
-
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: radeonfb/aty128fb: Disable broken early resume hook for PowerBooks hvc_console: Remove tty->low_latency on pseries backends powerpc: fix linkstation and storcenter compilation breakage powerpc/4xx: Enable SERIAL_OF support by default for Virtex platforms
-
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intelLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: drm/i915: fix 945 fence register writes for fence 8 and above. drm/i915: Protect active fences on i915 drm/i915: Check to see if we've pinned all available fences drm/i915: Check fence status on every pin. drm/i915: First recheck for an empty fence register. drm/i915: Fix bad \n in MTRR failure notice. drm/i915: Don't restore palettes through VGA registers. i915: add newline to i915_gem_object_pin failure msg drm: Return EINVAL on duplicate objects in execbuffer object list
-
Linus Torvalds authored
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: work around Fedora-11 x86-32 kernel failures on Intel Atom CPUs
-
OGAWA Hirofumi authored
On swapon() path, it has already i_mutex. So, this uses i_alloc_sem instead of it. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reported-by:
Laurent GUERBY <laurent@guerby.net> Signed-off-by:
-
Eric Anholt authored
The last 8 fence registers sit at a different offset, so when we went to set fence number 8 in the lower offset, we instead set PGETBL_CTL, and the GPU got all sorts of angry at us. fd.o bug #20567. Easily reproducible by running glxgears and killing it about 6 times. Signed-off-by:Eric Anholt <eric@anholt.net>
-
Chris Wilson authored
The i915 also uses the fence registers for GPU access to tiled buffers so we cannot reallocate one whilst it is on the active list. By performing a LRU scan of the fenced buffers we also avoid waiting the possibility of waiting on a pinned, or otherwise unusable, buffer. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ingo Molnar authored
Impact: work around boot crash Work around Intel Atom erratum AAH41 (probabilistically) - it's triggering in the field. Reported-by:
Kyle McMartin <kyle@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Wu Fengguang authored
Fix kpf_copy_bit(src,dst) to be kpf_copy_bit(dst,src) to match the actual call patterns, e.g. kpf_copy_bit(kflags, KPF_LOCKED, PG_locked). This misplacement of src/dst only affected reporting of PG_writeback, PG_reclaim and PG_buddy. For others kflags==uflags so not affected. Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: stable@kernel.org Signed-off-by:
-
Chris Wilson authored
We need to check and report if there are no available fences - or else we spin endlessly waiting for a buffer to magically unpin itself. Signed-off-by:
-
Chris Wilson authored
As we may steal the fence register of an unpinned buffer for another, every time we repin the buffer we need to recheck whether it needs to be allocated a fence. Signed-off-by:
-
Chris Wilson authored
If we wait upon a request and successfully unbind a buffer occupying a fence register, then that slot will be freed and cause a NULL derefrence upon rescanning. Signed-off-by:
-
Pantelis Koukousoulas authored
Comparing the layouts of struct detail_pixel_timing with x.org's struct detailed_timings and how those are handled, it appears that the hsync_positive and vsync_positive fields are backwards. This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=20019 for me. It was tested on 2 monitors, LG FLATRON L225WS 22" and a YAKUMO 17" for which more details are unknown. Signed-off-by:
Pantelis Koukousoulas <pktoss@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 10 Mar, 2009 10 commits
-
-
Benjamin Herrenschmidt authored
radeonfb and aty128fb have a special hook called by the PowerMac platform code very very early on resume from sleep to bring the screen back. This is useful for debugging wakup problems, but unfortunately, this also became a source of problems of its own. The hook is called extremely early, with interrupts still off, and the code path involved with that code nowadays rely on things like taking mutexes, GFP_KERNEL allocations, etc... In addition, the driver now relies on the PCI core to restore the standard config space before calling resume which doesn't happen with this early code path. I'm keeping the code in but commented out along with a fixup call to pci_restore_state(). The reason is that I still want to make it easy to re-enable temporarily to track wake up problems, and it's possible that I can revive it at some stage if we make sleeping things save to call in early resume using a system state. In the meantime, this should fix several reported regressions. Signed-off-by:Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
The hvcs and hvsi backends both set tty->low_latency to one, along with more or less scary comments regarding bugs or races that would happen if not doing so. However, they also both call tty_flip_buffer_push() in conexts where it's illegal to do so since some recent tty changes (or at least it may have been illegal always but it nows blows) when low_latency is set (ie, hard interrupt or with spinlock held and irqs disabled). This removes the setting for now to get them back to working condition, we'll have to address the races described in the comments separately if they are still an issue (some of this might have been fixed already). Signed-off-by: -
Benjamin Herrenschmidt authored
-
Samuel CUELLA authored
Prevent the kernel from being crashed by a divide-by-zero operation when supplied an incorrectly filled 'struct fb_var_screeninfo' from userland. Previously i810_main.c:1005 (i810_check_params) was using the global 'yres' symbol previously defined at i810_main.c:145 as a module parameter value holder (i810_main.c:2174). If i810fb is compiled-in or if this param doesn't get a default value, this direct usage leads to a divide-by-zero at i810_main.c:1005 (i810_check_params). The patch simply replace the 'yres' global, perhaps undefined symbol usage by a given parameter structure lookup. This problem occurs with directfb, mplayer -vo fbdev, SDL library. It was also reported ( but non solved ) at: http://mail.directfb.org/pipermail/directfb-dev/2008-March/004050.htmlSigned-off-by:
Samuel CUELLA <samuel.cuella@supinfo.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
Steven King authored
There isn't any mcfqspi.h in the tree, and without it everything inside the #ifdef CONFIG_SPI is uncompilable. Signed-off-by:
Steven King <sfking@fdwdc.com> Acked-by:
Greg Ungerer <gerg@snapgear.com> Signed-off-by:
-
Steven King authored
Signed-off-by:
-
Paul E. McKenney authored
Update the RCU documentation to call out the need for callers of primitives like call_rcu() and synchronize_rcu() to prevent subsequent RCU readers from hazard. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Dhaval Giani authored
We were returning early in the sysfs directory cleanup function if the user belonged to a non init usernamespace. Due to this a lot of the cleanup was not done and we were left with a leak. Fix the leak. Reported-by:
Serge Hallyn <serue@linux.vnet.ibm.com> Signed-off-by:
Dhaval Giani <dhaval@linux.vnet.ibm.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Tested-by:
-
Atsushi Nemoto authored
commit e480814f ("[MTD] [MAPS] physmap: fix wrong free and del_mtd_{partition,device}") introduces a NULL pointer dereference in physmap_flash_remove when called from the error path in physmap_flash_probe (if map_probe failed). Call del_mtd_{partition,device} only if info->cmtd was not NULL. Reported-by:
pHilipp Zabel <philipp.zabel@gmail.com> Signed-off-by:
-
Lubomir Rintel authored
When GTT size is equal to amount of video memory, the amount of GTT entries is computed lower than zero, which is invalid and leads to off-by-one error in intel_i915_configure() Originally posted here: http://bugzilla.kernel.org/show_bug.cgi?id=12539 http://bugzilla.redhat.com/show_bug.cgi?id=445592Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Cc: Lubomir Rintel <lkundrak@v3.sk> Cc: Dave Airlie <airlied@linux.ie> Reviewed-by:
-
