- 01 Apr, 2008 5 commits
-
-
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:
Linus Torvalds <torvalds@linux-foundation.org>
-
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
-
- 30 Mar, 2008 30 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:
-
Al Viro authored
Signed-off-by:
-
- 29 Mar, 2008 5 commits
-
-
Benjamin Herrenschmidt authored
This patch fixes bits of the DRM so to make the radeon DRI work on non-cache coherent PCI DMA variants of the PowerPC processors. It moves the few places that needs change to wrappers to that other architectures with similar issues can easily add their own changes to those wrappers, at least until we have more useful generic kernel API. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Dave Airlie <airlied@linux.ie>
-
Harvey Harrison authored
drivers/char/drm/radeon_mem.c:91:23: warning: Using plain integer as NULL pointer drivers/char/drm/radeon_mem.c:116:28: warning: Using plain integer as NULL pointer drivers/char/drm/radeon_mem.c:124:28: warning: Using plain integer as NULL pointer drivers/char/drm/radeon_mem.c:177:26: warning: Using plain integer as NULL pointer drivers/char/drm/radeon_mem.c:177:53: warning: Using plain integer as NULL pointer Signed-off-by:
-
Dave Airlie authored
From Kernel BZ 10289 - not sure why anyone would boot an intel with no agp but it shouldn't crash. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
This interface was originally designed wrong, confusing bit-fields and integers, major brown paper bag going back many years... But userspace only ever used 4 values so fix the interface for new users and fix the implementation to deal with the 4 values userspace has ever emitted (0x1, 0x2, 0x3, 0x6). Signed-off-by: -
Bartlomiej Zolnierkiewicz authored
We need to check for CONFIG_{CRIS,FRV} not {CRIS,FRV}. Signed-off-by:Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
