- 01 Apr, 2008 9 commits
-
-
Oliver Schuster authored
This patch corrects an error in the driver it8712f_wdt. You cannot set the 16-bit WDT_TIMEOUT access as a 16-bit outw, because the byte ordering will be wrong. So just do the high 8 bits as a separate access. Signed-off-by:
Oliver Schuster <olivers137@aol.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
* master.kernel.org:/home/rmk/linux-2.6-arm: [ARM] 4875/1: Add MODULE_ALIAS to ixp4xx-beeper module [ARM] 4873/1: Fix ITE 8152 interrupt demux [ARM] 4878/1: Add oabi shim for fstatat64
-
git://lm-sensors.org/kernel/mhoffman/hwmon-2.6Linus Torvalds authored
* 'release' of git://lm-sensors.org/kernel/mhoffman/hwmon-2.6: hwmon: (w83781d) Fix I/O resource conflict with PNP
-
git://git.o-hand.com/linux-rpurdie-ledsLinus Torvalds authored
* 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds: leds: Remove incorrect use of preempt_count() from leds-gpio leds: Fix potential leds-gpio oops
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: make sure input interfaces pin parent input devices Input: apm-power - fix crash when unloading modules Input: pxa27x - fix keypad KPC macros
-
Rafael J. Wysocki authored
Some time ago it turned out that our suspend code ordering broke some NVidia-based systems that hung if _PTS was executed with one of the PCI devices, specifically a USB controller, in a low power state. Then, it was noticed that the suspend code ordering was not compliant with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and it was argued that the code had to be changed for that reason (ref. http://bugzilla.kernel.org/show_bug.cgi?id=9528). So we did, but evidently we did wrong, because it's now turning out that some systems have been broken by this change. Refs: http://bugzilla.kernel.org/show_bug.cgi?id=10340 https://bugzilla.novell.com/show_bug.cgi?id=374217#c16 [ I said at that time that something like this might happend, but the majority of people involved thought that it was improbable due to the necessity to preserve the compliance of hardware with ACPI 1.0. ] This actually is a quite serious regression from 2.6.24. Moreover, the ACPI 1.0 ordering of suspend code introduced another issue that I have only noticed recently. Namely, if the suspend of one of devices fails, the already suspended devices will be resumed without executing _WAK before, which leads to problems on some systems (for example, in such situations thermal management is broken on my HP nx6325). Consequently, it also breaks suspend debugging on the affected systems. Note also, that the requirement to execute _PTS before suspending devices does not really make sense, because the device in question may be put into a low power state at run time for a reason unrelated to a system-wide suspend. For the reasons outlined above, the change of the suspend ordering should be reverted, which is done by the patch below. [ Felix Möller: "I am the reporter from the original Novell Bug: https://bugzilla.novell.com/show_bug.cgi?id=374217 I just tried current git head (two hours ago) with the patch (the one from the beginning of this thread) from Rafael and without it. With the patch my MacBook does suspend without it does not." ] Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Tested-by:
Felix Möller <felix@derklecks.de> Signed-off-by:
-
Mikulas Patocka authored
Plip uses spin_lock_irq/spin_unlock_irq in its IRQ handler (called from parport IRQ handler), the latter enables interrupts without parport subsystem IRQ handler expecting it. The bug can be seen if you compile kernel with lock dependency checking and use plip --- it produces a warning. This patch changes it to spin_lock_irqsave/spin_lock_irqrestore, so that it doesn't enable interrupts when already disabled. Signed-off-by: -
Dmitry Torokhov authored
Recent driver core change causes references to parent devices being dropped early, at device_del() time, as opposed to when all children are freed. This causes oops in evdev with grabbed devices. Take the reference to the parent input device ourselves to ensure that it stays around long enough. Signed-off-by:Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
-
- 31 Mar, 2008 2 commits
-
-
David Brownell authored
It appears that we can't just check to see if we're in a task context ... so instead of trying that, just make the relevant leds always schedule a little worklet. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
Richard Purdie <rpurdie@rpsys.net>
-
Uwe Kleine-König authored
Call gpio_cansleep only after gpio_request succeeded avoiding an oops. Signed-off-by:
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Acked-by:
-
- 30 Mar, 2008 29 commits
-
-
Mark Lord authored
Mark Lord wrote: > > On boot, syslog is flooded with "uevent: unsupported action-string;" messages. .. > Mar 28 14:43:29 shrimp kernel: tty ptyqd: uevent: unsupported > action-string; this will be ignored in a future kernel version > Mar 28 14:43:29 shrimp kernel: tty ptyqe: uevent: unsupported > action-string; this will be ignored in a future kernel version > Mar 28 14:43:29 shrimp kernel: tty ptyqf: uevent: unsupported > action-string; this will be ignored in a future kernel version > Mar 28 14:43:29 shrimp kernel: tty ptyr0: uevent: unsupported > action-string; this will be ignored in a future kernel version .. These messages are a regression compared with 2.6.24, which did not flood the syslog with them. The actual underlying problem was introduced in 2.6.23, when somebody made the string parsing no longer accept nul-terminated strings as a valid input to store_uevent(). Eg. "add\0" was valid prior to 2.6.23, where the code regressed to require "add" without the '\0'. This patch fixes the 2.6.23 / 2.6.24 regressions, by having the code once again tolerate the trailing '\0', if present. According to GregKH, this mainly affects older Ubuntu systems, such as the one I have here that requires this fix. Signed-off-by:
Mark Lord <mlord@pobox.com> Signed-off-by:
-
Björn Steinbrink authored
When getting disconnected we need to release eventual grabs on the underlying input device as we also release the input device itself. Otherwise, we would try to release the grab when the client that requested it closes its handle, accessing the input device which might already be freed. Signed-off-by:
Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by:
-
Adrian Bunk authored
I accidentally removed the module license from sound/oss/ac97_codec.c in commit 83bad1d7 ("scheduled OSS driver removal") Spotted by Roland <devzero@web.de>. Signed-off-by:
Adrian Bunk <bunk@kernel.org> 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 for non-coherent DMA PowerPC drm: radeon: fix sparse integer as NULL pointer warnings in radeon_mem.c drm/i915: fix oops on agp=off drm/r300: fix bug in r300 userspace hardware wait emission
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: libata: ATA_EHI_LPM should be ATA_EH_LPM pata_sil680: only enable MMIO on Cell blades
-
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: ide: fix defining SUPPORT_VLB_SYNC Revert "ide: change master/slave IDENTIFY order"
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
a) every bitwise declaration will give a unique type; use typedefs. b) no need to bother with the stuff pointed to by iomem pointers, unless it's accessed directly. noderef will force us to use helpers anyway. Signed-off-by: -
Al Viro authored
Signed-off-by:
-
Al Viro authored
NB: remaining endianness warnings in the file are, AFAICS, real bugs. Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
aka if you see a force-cast, be very suspicious... Signed-off-by:
Frank Seidel <fseidel@suse.de> Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Acked-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
