- 24 Apr, 2009 25 commits
-
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Len Brown authored
-
Matthew Garrett authored
The ACPI video driver defers registration to the i915 driver if the system supports opregion-mediated backlight control. This registration was only being performed in the KMS case. Ensure it's done even if we don't have modesetting enabled. http://bugzilla.kernel.org/show_bug.cgi?id=13048Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
-
Len Brown authored
This reverts commit fdbdc7fc. That temporary quick-fix is no longer necessary, as the previous patch, a65131e9, "I/O port protection: update for windows compatibility" should handle this issue for all ports, including this one. Signed-off-by: Len Brown <len.brown@intel.com>
-
Lin Ming authored
For windows compatibility, 1) On a port protection violation, simply ignore the request and do not return an exception (allow the control method to continue execution.) 2) If only part of the request overlaps a protected port, read/write the individual ports that are not protected. http://bugzilla.kernel.org/show_bug.cgi?id=13036Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
-
Mattia Dongili authored
This fixes an inconsistent behaviour when loading the driver with the switch on or off. In the former case you would also need to soft unblock the switch via the sysfs file entries to really disable rfkill, in the latter you wouldn't. Signed-off-by: Mattia Dongili <malattia@linux.it> Cc: Matthias Welwarsky <matze@welwarsky.de> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
-
Mattia Dongili authored
sony_backlight_update_status returns 0 on success -1 on failure (i.e.: the return value from acpi_callsetfunc. The return value in the resume path was broken and thus always displaying a bogus warning about not being able to restore the brightness level. Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Len Brown <len.brown@intel.com>
-
Almer S. Tigelaar authored
When resuming from standby (on a laptop) I see the following message in my kernel.log: "ACPI: EC: non-query interrupt received, switching to interrupt mode" This apparently prevented sony-laptop to properly restore the brightness level on resume. The cause: In drivers/acpi/ec.c the acpi_ec_suspend function clears the GPE mode bit, but this is not restored in acpi_ec_resume (the function below it). The patch below fixes this by properly restoring the GPE_MODE bit. Tested and confirmed to work. Signed-off-by: Almer S. Tigelaar <almer@gnome.org> Signed-off-by: Mattia Dongili <malattia@linux.it> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
-
Almer S. Tigelaar authored
Fixes the "unknown input event 38" messages. ANYBUTTON_RELEASED is now treated the same way as FN_KEY_RELEASED. Signed-off-by: Almer S. Tigelaar <almer@gnome.org> Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Len Brown <len.brown@intel.com>
-
Almer S. Tigelaar authored
Fixes additional special key initialization for SNC 127 key events. Verified / tested on a Sony VAIO SR model. Signed-off-by: Almer S. Tigelaar <almer@gnome.org> Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Len Brown <len.brown@intel.com>
-
Almer S. Tigelaar authored
Fixes a duplicate mapping in the SNC sony_127_events structure. Signed-off-by: Almer S. Tigelaar <almer@gnome.org> Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Len Brown <len.brown@intel.com>
-
Len Brown authored
As processor.max_cstate is an init-time-only modparam, sanity checking it at init-time is sufficient. http://bugzilla.kernel.org/show_bug.cgi?id=13142Signed-off-by: Len Brown <len.brown@intel.com>
-
Len Brown authored
Linux tells ICH4 users that they can (manually) invoke "hpet=force" to enable the undocumented ICH-4M HPET. The HPET becomes available for both clocksource and clockevents. But as of ff69f2bb (acpi: fix of pmtimer overflow that make Cx states time incorrect) the HPET may be used via clocksource for idle accounting, and hpet=force on an ICH4 box hangs boot. It turns out that touching the MMIO HPET withing the ARB_DIS part of C3 will hang the hardware. The fix is to simply move the timer access outside the ARB_DIS region. This is a no-op on modern hardware because ARB_DIS is no longer used. http://bugzilla.kernel.org/show_bug.cgi?id=13087Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
-
- 22 Apr, 2009 7 commits
-
-
Len Brown authored
Linux-2.6.29 deleted the legacy ACPI idle handler, leaving the CPU_IDLE handler, which does not track bus master activity. So delete the unused bm_activity field -- it is confusing to print an always zero value. This patch could break programs that parse /proc/acpi/processor/*/power, since it deletes this line from that file: bus master activity: 00000000 http://bugzilla.kernel.org/show_bug.cgi?id=13145 is not fixed by this patch, but provoked this patch. Signed-off-by: Len Brown <len.brown@intel.com>
-
Len Brown authored
The c2 and c3 idle handlers check tsc_halts_in_c() after every time they return from idle. Um, when?:-) Move this check to init-time to remove the unnecessary run-time overhead, and also to have the check complete before the first entry into the idle handler. ff69f2bb (acpi: fix of pmtimer overflow that make Cx states time incorrect) replaced the hard-coded use of the PM-timer inside idle, with ktime_get_readl(), which possibly uses the TSC -- so it is now especially prudent to detect a broken TSC before entering idle. http://bugzilla.kernel.org/show_bug.cgi?id=13087Signed-off-by: Len Brown <len.brown@intel.com>
-
Linus Torvalds authored
-
Arjan van de Ven authored
There is currently only one way for userspace to say "wait for my storage device to get ready for the modules I just loaded": to load the scsi_wait_scan module. Expectations of userspace are that once this module is loaded, all the (storage) devices for which the drivers were loaded before the module load are present. Now, there are some issues with the implementation, and the async stuff got caught in the middle of this: The existing code only waits for the scsy async probing to finish, but it did not take into account at all that probing might not have begun yet. (Russell ran into this problem on his computer and the fix works for him) This patch fixes this more thoroughly than the previous "fix", which had some bad side effects (namely, for kernel code that wanted to wait for the scsi scan it would also do an async sync, which would deadlock if you did it from async context already.. there's a report about that on lkml): The patch makes the module first wait for all device driver probes, and then it will wait for the scsi parallel scan to finish. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Tested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Jonathan Corbet authored
Fix a comment typo in slow-work.h ...a trivial mistake, but it will mess up kerneldoc if nothing else. Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
David Howells authored
Collect the DECLARE/DEFINE declarations together in linux/percpu-defs.h so that they're in one place, and give them descriptive comments, particularly the SHARED_ALIGNED variant. It would be nice to collect these in linux/percpu.h, but that's not possible without sorting out the severe #include recursion between the x86 arch headers and the general headers (and possibly other arches too). Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
David Howells authored
In non-SMP mode, the variable section attribute specified by DECLARE_PER_CPU() does not agree with that specified by DEFINE_PER_CPU(). This means that architectures that have a small data section references relative to a base register may throw up linkage errors due to too great a displacement between where the base register points and the per-CPU variable. On FRV, the .h declaration says that the variable is in the .sdata section, but the .c definition says it's actually in the .data section. The linker throws up the following errors: kernel/built-in.o: In function `release_task': kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o To fix this, DECLARE_PER_CPU() should simply apply the same section attribute as does DEFINE_PER_CPU(). However, this is made slightly more complex by virtue of the fact that there are several variants on DEFINE, so these need to be matched by variants on DECLARE. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 21 Apr, 2009 8 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstableLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable: Btrfs: fix btrfs fallocate oops and deadlock Btrfs: use the right node in reada_for_balance Btrfs: fix oops on page->mapping->host during writepage Btrfs: add a priority queue to the async thread helpers Btrfs: use WRITE_SYNC for synchronous writes
-
git://jdelvare.pck.nerim.net/jdelvare-2.6Linus Torvalds authored
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: go7007: Convert to the new i2c device binding model
-
Roel Kluin authored
`!' has a higher precedence than `&', parentheses are misplaced. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by: Sonic Zhang <sonic.zhang@analog.com> Cc: Bryan Wu <cooloney@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
KOSAKI Motohiro authored
Commit a6dc60f8 ("vmscan: rename sc.may_swap to may_unmap") removed the may_swap flag, but memcg had used it as a flag for "we need to use swap?", as the name indicate. And in the current implementation, memcg cannot reclaim mapped file caches when mem+swap hits the limit. re-introduce may_swap flag and handle it at get_scan_ratio(). This patch doesn't influence any scan_control users other than memcg. Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Dave Jiang authored
Error found by Jeff Haran. The error detect register is 0s when no errors are detected. The check code is incorrect, so reverse check sense. Reported-by: Jeff Haran <jharan@Brocade.COM> Signed-off-by: Dave Jiang <djiang@mvista.com> Signed-off-by: Doug Thompson <dougthompson@xmission.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Eric Paris authored
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13133 ODEBUG: object is on stack, but not annotated ------------[ cut here ]------------ WARNING: at lib/debugobjects.c:253 __debug_object_init+0x1f3/0x276() Hardware name: VMware Virtual Platform Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi ext3 jbd mbcache Pid: 540, comm: insmod Not tainted 2.6.28-mm1 #2 Call Trace: [<c042c51c>] warn_slowpath+0x74/0x8a [<c0469600>] ? start_critical_timing+0x96/0xb7 [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c0446fad>] ? trace_hardirqs_off_caller+0x18/0xaf [<c044704f>] ? trace_hardirqs_off+0xb/0xd [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c042cb84>] ? release_console_sem+0x1a5/0x1ad [<c05013e6>] __debug_object_init+0x1f3/0x276 [<c0501494>] debug_object_init+0x13/0x17 [<c0433c56>] init_timer+0x10/0x1a [<e08e5b54>] mpt_config+0x1c1/0x2b7 [mptbase] [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase] [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase] [<e08e6fa2>] mpt_do_ioc_recovery+0x950/0x1212 [mptbase] [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c [<c060c3af>] ? _spin_unlock_irq+0x22/0x26 [<c04f2d8b>] ? string+0x2b/0x76 [<c04f310e>] ? vsnprintf+0x338/0x7b3 [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c044897d>] ? debug_check_no_locks_freed+0xeb/0x105 [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c [<c04488bc>] ? debug_check_no_locks_freed+0x2a/0x105 [<c0446b8c>] ? lock_release_holdtime+0x43/0x48 [<c043f742>] ? up_read+0x16/0x29 [<c05076f8>] ? pci_get_slot+0x66/0x72 [<e08e89ca>] mpt_attach+0x881/0x9b1 [mptbase] [<e091c8e5>] mptspi_probe+0x11/0x354 [mptspi] Noticing that every caller of mpt_config has its CONFIGPARMS struct declared on the stack and thus the &pCfg->timer is always on the stack I changed init_timer() to init_timer_on_stack() and it seems to have shut up..... Cc: "Moore, Eric Dean" <Eric.Moore@lsil.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: "Desai, Kashyap" <Kashyap.Desai@lsi.com> Cc: <stable@kernel.org> [2.6.29.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Robin Holt authored
For an upcoming distro release, we need to have the xp kernel module loadable even when not on UV equipment. The xpc module will not load. This will allow one set of modules dependent upon xp to work on either UV or non-UV equipment. Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Jack Steiner <steiner@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
WANG Cong authored
Got this warning from Kconfig: boolean symbol INPUT tested for 'm'? test forced to 'n' because INPUT is tristate, not bool. Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-