- 07 Feb, 2008 2 commits
-
-
Len Brown authored
also, address some checkpatch.pl violations Signed-off-by:
Len Brown <len.brown@intel.com>
-
Éric Piel authored
The acpi_no_initrd_override parameter permits to disable the load of an ACPI table from the initramfs. Signed-off-by:
Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 06 Feb, 2008 2 commits
-
-
Éric Piel authored
When an ACPI table is overridden (for now this can happen only for DSDT) display a big warning and taint the kernel with flag A. Signed-off-by:
Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
Len Brown <len.brown@intel.com>
-
Markus Gaugusch authored
The basics of DSDT from initramfs. In case this option is selected, populate_rootfs() is called a bit earlier to have the initramfs content available during ACPI initialization. This is a very similar path to the one available at http://gaugusch.at/kernel.shtml but with some update in the documentation, default set to No and the change of populate_rootfs() the "Jeff Mahony way" (which avoids reading the initramfs twice). Signed-off-by:
Thomas Renninger <trenn@suse.de> Signed-off-by:
Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 23 Jan, 2008 4 commits
-
-
Len Brown authored
If BIOS invokes _OSI(Linux), the kernel response depends on what the ACPI DMI list knows about the system, and that is reflectd in dmesg: 1) System unknown to DMI: ACPI: BIOS _OSI(Linux) query ignored ACPI: DMI System Vendor: LENOVO ACPI: DMI Product Name: 7661W1P ACPI: DMI Product Version: ThinkPad T61 ACPI: DMI Board Name: 7661W1P ACPI: DMI BIOS Vendor: LENOVO ACPI: DMI BIOS Date: 10/18/2007 ACPI: Please send DMI info above to linux-acpi@vger.kernel.org ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org 2) System known to DMI, but effect of OSI(Linux) unknown: ACPI: DMI detected: Lenovo ThinkPad T61 ... ACPI: BIOS _OSI(Linux) query ignored via DMI ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org 3) System known to DMI, which disables _OSI(Linux): ACPI: DMI detected: Lenovo ThinkPad T61 ... ACPI: BIOS _OSI(Linux) query ignored via DMI 4) System known to DMI, which enable _OSI(Linux): ACPI: DMI detected: Lenovo ThinkPad T61 ACPI: Added _OSI(Linux) ... ACPI: BIOS _OSI(Linux) query honored via DMI cmdline overrides take precidence over the built-in default and the DMI prescribed default. cmdline "acpi_osi=Linux" results in: ACPI: BIOS _OSI(Linux) query honored via cmdline Signed-off-by:
Len Brown <len.brown@intel.com>
-
Len Brown authored
Linux does not want BIOS writers to invoke _OSI(Linux) - for in the field it causes more Windows incompatibility problems than it solves. So when it is seen in the BIOS for an Intel Customer Reference Board, Linux should ignore its effect by default, and should complain loudly. Otherwise, the reference BIOS will go unfixed, and the bad BIOS will spread to the field. Users of this board can get the old behavior with "acpi_osi=Linux" As this was the only entry, delete acpi_osl_dmi_table[]. Signed-off-by:
Len Brown <len.brown@intel.com>
-
Len Brown authored
Signed-off-by:
Len Brown <len.brown@intel.com>
-
Len Brown authored
A utility routine to print common entries used for ACPI-related DMI blacklist entries. Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 16 Nov, 2007 1 commit
-
-
Zhao Yakui authored
We've run into BIOS that hand us 4-bit access width requests for T-state control when the code expected only multipls of 8-bits. Round up. Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Li Shaohua <shaohua.li@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 10 Oct, 2007 1 commit
-
-
Len Brown authored
commit e5a16b1f9eec0af7cfa0830304b41c1c0833cf9f Author: Len Brown <len.brown@intel.com> Date: Tue Oct 2 23:44:44 2007 -0400 cpuidle: shrink diff processor_idle.c | 440 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 429 insertions(+), 11 deletions(-) Signed-off-by:
Len Brown <len.brown@intel.com> commit dfbb9d5aedfb18848a3e0d6f6e3e4969febb209c Author: Len Brown <len.brown@intel.com> Date: Wed Sep 26 02:17:55 2007 -0400 cpuidle: reduce diff size Reduces the cpuidle processor_idle.c diff vs 2.6.22 from this processor_idle.c | 2006 ++++++++++++++++++++++++++----------------- 1 file changed, 1219 insertions(+), 787 deletions(-) to this: processor_idle.c | 502 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 458 insertions(+), 44 deletions(-) ...for the purpose of making the cpuilde patch less invasive and easier to review. no functional changes. build tes...
-
- 09 Oct, 2007 1 commit
-
-
Jeff Garzik authored
Three main sets of changes: 1) dmi_get_system_info() return value should have been marked const, since callers should not be changing that data. 2) const-ify DMI internals, since DMI firmware tables should, whenever possible, be marked const to ensure we never ever write to that data area. 3) const-ify DMI API, to enable marking tables const where possible in low-level drivers. And if we're really lucky, this might enable some additional optimizations on the part of the compiler. The bulk of the changes are #2 and #3, which are interrelated. #1 could have been a separate patch, but it was so small compared to the others, it was easier to roll it into this changeset. Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
- 19 Jul, 2007 1 commit
-
-
Paul Mundt authored
Slab destructors were no longer supported after Christoph's c59def9f change. They've been BUGs for both slab and slub, and slob never supported them either. This rips out support for the dtor pointer from kmem_cache_create() completely and fixes up every single callsite in the kernel (there were about 224, not including the slab allocator definitions themselves, or the documentation references). Signed-off-by:
Paul Mundt <lethal@linux-sh.org>
-
- 03 Jul, 2007 2 commits
-
-
Adrian Bunk authored
make the needlessly global osi_linux static. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Len Brown <len.brown@intel.com>
-
Len Brown authored
Need to check for special case "acpi_osi=!Linux" before handling the general case "acpi_osi=!*", or it will have no effect. Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 09 Jun, 2007 1 commit
-
-
Len Brown authored
In Linux-2.6.22 we expanded the boot parameter osi= so that it can enable and !enable an OSI string. _OSI(Linux) is a special case because we know that there are both systems that require it set, and systems require that it _not_ to be set. In the long term it can't be set, for the same reason _OS(Linux) can't be enabled -- it tends to confuse BIOS that are not properly validated with Linux. Further, the semantics and version information of _OSI(Linux) were never actually defined. The kernel prints out a message if it sees _OSI(Linux) requested, and there is a DMI workaround to invoke "osi=Linux" automatically for existing systems that need it. http://bugzilla.kernel.org/show_bug.cgi?id=7787 Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 30 May, 2007 2 commits
-
-
Len Brown authored
Add __init to: acpi_initialize_subsystem() (and un-export it) acpi_os_initialize() Add __initdata to: acpi_osl_dmi_table[] Signed-off-by:
Len Brown <len.brown@intel.com>
-
Len Brown authored
_OSI("Linux") is like _OS("Linux"), it is ill-defined and virtually no BIOS vendors test interaction with it. As a result, it can do more damage than good because it causes the BIOS to follow un-tested paths. Recently, several machines have turned up that erroneously test this string in a way which causes them to _not_ test other compatibility strings, including the ZI9 and Toshiba. So it appears that this bad code has made it into a BIOS vendor's reference BIOS. Linux has no choice but to stop advertising compatibility with _OSI string "Linux" - as there are an unbounded number of possible incompatibilities going forward. But some BIOSes have already shipped which do use it for things like conditionally re-enabling video on resume from S3. (Too bad they didn't do that unconditionally) Add special case code for _OSI(Linux) Squawk to dmesg if _OSI(Linux) is requested Add DMI list both to enable and disable _OSI(Linux) But for now, keep the default enabled via #define OSI_LINUX_ENABLED. http://bugzilla.kernel.org/show_bug.cgi?id=7787 Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 29 May, 2007 1 commit
-
-
Len Brown authored
The boot option "acpi_osi=" has always disabled Linux _OSI support, thus disabling all OS Interface strings which are advertised by Linux to the BIOS. Now... acpi_osi="string" adds the interface string, and acpi_osi="!string" invalidates the pre-defined interface string eg. acpi_osi="!Windows 2006" would disable Linux's claim of Vista compatibility. Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 09 May, 2007 1 commit
-
-
Alexey Starikovskiy authored
HP nx6125/nx6325/... machines have a _GPE handler with an infinite loop sending Notify() events to different ACPI subsystems. Notify handler in ACPI driver is a C-routine, which may call ACPI interpreter again to get access to some ACPI variables (acpi_evaluate_xxx). On these HP machines such an evaluation changes state of some variable and lets the loop above break. In the current ACPI implementation Notify requests are being deferred to the same kacpid workqueue on which the above GPE handler with infinite loop is executing. Thus we have a deadlock -- loop will continue to spin, sending notify events, and at the same time preventing these notify events from being run on a workqueue. All notify events are deferred, thus we see increase in memory consumption noticed by author of the thread. Also as GPE handling is bloked, machines overheat. Eventually by external poll of the same acpi_evaluate, kacpid is released and all the queued notify events are free to run, thus 100% cpu utilization by kacpid for several seconds or more. To prevent all these horrors it's needed to not put notify events to kacpid workqueue by either executing them immediately or putting them on some other thread. It's dangerous to execute notify events in place, as it will put several ACPI interpreter stacks on top of each other (at least 4 in case of nx6125), thus causing kernel stack overflow. First attempt to create a new thread was done by Peter Wainwright He created a bunch of threads, which were stealing work from a kacpid workqueue. This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS. Second attempt was done by me, I created a new thread for each Notify event. This worked OK on HP nx machines, but broke Linus' Compaq n620c, by producing threads with a speed what they stopped the machine completely. Thus this patch was reverted from 18-rc2 as I remember. I re-made the patch to create second workqueue just for notify events, thus hopping it will not break Linus' machine. Patch was tested on the same HP nx machines in #5534 and #7122, but I did not received reply from Linus on a test patch sent to him. Patch went to 19-rc and was rejected with much fanfare again. There was 4th patch, which inserted schedule_timeout(1) into deferred execution of kacpid, if we had any notify requests pending, but Linus decided that it was too complex (involved either changes to workqueue to see if it's empty or atomic inc/dec). Now you see last variant which adds yield() to every GPE execution. http://bugzilla.kernel.org/show_bug.cgi?id=5534 http://bugzilla.kernel.org/show_bug.cgi?id=8385 Signed-off-by:
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 08 May, 2007 1 commit
-
-
Randy Dunlap authored
Remove includes of <linux/smp_lock.h> where it is not used/needed. Suggested by Al Viro. Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc, sparc64, and arm (all 59 defconfigs). Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 16 Feb, 2007 1 commit
-
-
Len Brown authored
Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 15 Feb, 2007 2 commits
-
-
Len Brown authored
...which are now unused Signed-off-by:
Len Brown <len.brown@intel.com>
-
Randy Dunlap authored
Use NULL for pointers drivers/acpi/osl.c:208:10: warning: Using plain integer as NULL pointer drivers/acpi/tables/tbxface.c:411:49: warning: Using plain integer as NULL pointer drivers/acpi/processor_core.c:1008:10: warning: Using plain integer as NULL pointer Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 12 Feb, 2007 1 commit
-
-
Len Brown authored
cosmetic only Make "module name" actually match the file name. Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care. Fix indentation where Lindent did get confused. Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 02 Feb, 2007 2 commits
-
-
Alexey Starikovskiy authored
Signed-off-by:
Len Brown <len.brown@intel.com>
-
Alexey Starikovskiy authored
Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 26 Jan, 2007 1 commit
-
-
Bjorn Helgaas authored
Resources described by the FADT aren't really a good fit for the ACPI motherboard driver. The motherboard driver cares about PNP0C01 and PNP0C02 devices and their resources. The FADT describes some resources used by the ACPI core. Often, they are also described by by the _CRS of a motherboard device, but I think it's better to reserve them specifically in the ACPI osl.c because (a) the motherboard driver is optional and ACPI uses the resources even if the driver is absent, and (b) I want to remove the ACPI motherboard driver because it's mostly redundant with the PNP system.c driver. Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 20 Dec, 2006 1 commit
-
-
Adrian Bunk authored
Spotted by the Coverity checker. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 22 Nov, 2006 1 commit
-
-
David Howells authored
Pass the work_struct pointer to the work function rather than context data. The work function can use container_of() to work out the data. For the cases where the container of the work_struct may go away the moment the pending bit is cleared, it is made possible to defer the release of the structure by deferring the clearing of the pending bit. To make this work, an extra flag is introduced into the management side of the work_struct. This governs auto-release of the structure upon execution. Ordinarily, the work queue executor would release the work_struct for further scheduling or deallocation by clearing the pending bit prior to jumping to the work function. This means that, unless the driver makes some guarantee itself that the work_struct won't go away, the work function may not access anything else in the work_struct or its container lest they be deallocated.. This is a problem if the auxiliary data is taken away (as done by the last patch). However, if the pending bit is *not* cleared before jumping to the work function, then the work function *may* access the work_struct and its container with no problems. But then the work function must itself release the work_struct by calling work_release(). In most cases, automatic release is fine, so this is the default. Special initiators exist for the non-auto-release case (ending in _NAR). Signed-Off-By:
David Howells <dhowells@redhat.com>
-
- 17 Nov, 2006 1 commit
-
-
Linus Torvalds authored
This reverts commit 37605a69. Again. This same bug has now been introduced twice: it was done earlier by commit b8d35192, only to be reverted last time in commit 72945b2b . We must NOT try to queue up notify handlers to another thread than the normal ACPI execution thread, because the notifications on some systems seem to just keep on accumulating until we run out of memory and/or threads. Keeping events within the one deferred execution thread automatically throttles the events properly. At least the Compaq N620c will lock up completely on the first thermal event without this patch reverted. Cc: David Brownell <david-b@pacbell.net> Cc: Len Brown <len.brown@intel.com> Cc: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 14 Oct, 2006 2 commits
-
-
Jan Engelhardt authored
Signed-off-by:
Jan Engelhardt <jengelh@gmx.de> Signed-off-by:
Len Brown <len.brown@intel.com>
-
Alexey Y. Starikovskiy authored
http://bugzilla.kernel.org/show_bug.cgi?id=5534#c160 Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 05 Oct, 2006 1 commit
-
-
David Howells authored
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By:
David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
-
- 27 Sep, 2006 1 commit
-
-
Alexey Dobriyan authored
* Rougly half of callers already do it by not checking return value * Code in drivers/acpi/osl.c does the following to be sure: (void)kmem_cache_destroy(cache); * Those who check it printk something, however, slab_error already printed the name of failed cache. * XFS BUGs on failed kmem_cache_destroy which is not the decision low-level filesystem driver should make. Converted to ignore. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 16 Aug, 2006 1 commit
-
-
Len Brown authored
__might_sleep+0x8e/0x93 acpi_os_wait_semaphore+0x50/0xa3 acpi_ut_acquire_mutex+0x28/0x6a acpi_ns_get_node+0x46/0x88 acpi_ns_evaluate+0x2d/0xfc acpi_rs_set_srs_method_data+0xc5/0xe1 acpi_set_current_resources+0x31/0x3f acpi_pci_link_set+0xfc/0x1a5 irqrouter_resume+0x48/0x5f and __might_sleep+0x8e/0x93 kmem_cache_alloc+0x2a/0x8f acpi_evaluate_integer+0x32/0x96 acpi_bus_get_status+0x30/0x84 acpi_pci_link_set+0x12a/0x1a5 irqrouter_resume+0x48/0x5f http://bugzilla.kernel.org/show_bug.cgi?id=6810 Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 13 Jul, 2006 1 commit
-
-
Len Brown authored
This effectively reverts commit b8d35192 by reverts acpi_os_queue_for_execution() to what it was before that, except it changes the name to acpi_os_execute() to match ACPICA 20060512. Signed-off-by:
Len Brown <len.brown@intel.com> [ The thread execution doesn't actually solve the bug it set out to solve (see http://bugzilla.kernel.org/show_bug.cgi?id=5534 for more details) because the new events can get caught behind the AML semaphore or other serialization. And when that happens, the notify threads keep on piling up until the system dies. ] Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 10 Jul, 2006 1 commit
-
-
Len Brown authored
Replace acpi_in_resume with a more general hack to check irqs_disabled() on any kmalloc() from ACPI. While setting (system_state != SYSTEM_RUNNING) on resume seemed more general, Andrew Morton preferred this approach. http://bugzilla.kernel.org/show_bug.cgi?id=3469 Make acpi_os_allocate() into an inline function to allow /proc/slab_allocators to work. Delete some memset() that could fault on allocation failure. Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 02 Jul, 2006 1 commit
-
-
Thomas Gleixner authored
Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "David S. Miller" <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 30 Jun, 2006 2 commits
-
-
Jörn Engel authored
Signed-off-by:
Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-
Len Brown authored
Signed-off-by:
Len Brown <len.brown@intel.com>
-