summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/processor_core.c
Commit message (Collapse)AuthorAgeFilesLines
...
| | | * ACPI: processor: move device _HID into driverBjorn Helgaas2009-05-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI0007 _HID used for processor "Device" objects in the namespace is not needed outside the processor driver, so move it there. Also, the #define is only used once, so just remove it and hard-code "ACPI0007". Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * ACPI: processor: check for synthetic _HID, default to "Device" declarationBjorn Helgaas2009-05-281-15/+15
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch inverts the logic that distinguishes "Processor" statements from "Device" statements, so we now check explicitly for "Processor" and default to "Device". This removes the only real use of ACPI_PROCESSOR_HID, so we can then remove the #define. It also has the theoretical advantage that if a new processor _HID were ever added, we wouldn't have to change the code here. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * / ACPI: Rename ACPI processor device bus IDZhao Yakui2009-06-241-1/+10
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some BIOS re-use the same processor bus id in different scope: \_SB.SCK0.CPU0 \_SB.SCK1.CPU0 But the (deprecated) /proc/acpi/ interface assumes the bus-id's are unique, resulting in an OOPS when the processor driver is loaded: WARNING: at fs/proc/generic.c:590 proc_register+0x148/0x180() Hardware name: Sunrise Ridge proc_dir_entry 'processor/CPU0' already registered Call Trace: [<ffffffff8023f7ef>] warn_slowpath+0xb1/0xe5 [<ffffffff8036243b>] ? ida_get_new_above+0x190/0x1b1 [<ffffffff803625a8>] ? idr_pre_get+0x5f/0x75 [<ffffffff8030b2f6>] proc_register+0x148/0x180 [<ffffffff8030b4ff>] proc_mkdir_mode+0x3d/0x52 [<ffffffff8030b525>] proc_mkdir+0x11/0x13 [<ffffffffa0014b89>] acpi_processor_start+0x755/0x9bc [processor] Rename the processor device bus id. And the new bus id will be generated as the following format: CPU+ CPU ID For example: If the cpu ID is 5, then the bus ID will be "CPU5". If the CPU ID is 10, then the bus ID will be "CPUA". Yes, this will change the directory names seen in /proc/acpi/processor/* on some systems. Before this patch, those directory names where totally arbitrary strings based on the interal AML device strings. http://bugzilla.kernel.org/show_bug.cgi?id=13612 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* / cpumask: alloc zeroed cpumask for static cpumask_var_tsYinghai Lu2009-06-091-1/+1
|/ | | | | | | | These are defined as static cpumask_var_t so if MAXSMP is not used, they are cleared already. Avoid surprises when MAXSMP is enabled. Signed-off-by: Yinghai Lu <yinghai.lu@kernel.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* ACPI: processor: use .notify method instead of installing handler directlyBjorn Helgaas2009-04-051-15/+4Star
| | | | | | | | | | | | | This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Zhang Rui <rui.zhang@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> CC: Venki Pallipadi <venkatesh.pallipadi@intel.com> CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'linus' into releaseLen Brown2009-04-051-2/+0Star
|\ | | | | | | | | | | | | Conflicts: arch/x86/kernel/cpu/cpufreq/longhaul.c Signed-off-by: Len Brown <len.brown@intel.com>
| * proc 2/2: remove struct proc_dir_entry::ownerAlexey Dobriyan2009-03-301-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy as correctly noted at bug #12454. Someone can lookup entry with NULL ->owner, thus not pinning enything, and release it later resulting in module refcount underflow. We can keep ->owner and supply it at registration time like ->proc_fops and ->data. But this leaves ->owner as easy-manipulative field (just one C assignment) and somebody will forget to unpin previous/pin current module when switching ->owner. ->proc_fops is declared as "const" which should give some thoughts. ->read_proc/->write_proc were just fixed to not require ->owner for protection. rmmod'ed directories will be empty and return "." and ".." -- no harm. And directories with tricky enough readdir and lookup shouldn't be modular. We definitely don't want such modular code. Removing ->owner will also make PDE smaller. So, let's nuke it. Kudos to Jeff Layton for reminding about this, let's say, oversight. http://bugzilla.kernel.org/show_bug.cgi?id=12454 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
* | x86, ACPI: add support for x2apic ACPI extensionsSuresh Siddha2009-04-041-0/+26
|/ | | | | | | | | | | | | | | | | | All logical processors with APIC ID values of 255 and greater will have their APIC reported through Processor X2APIC structure (type-9 entry type) and all logical processors with APIC ID less than 255 will have their APIC reported through legacy Processor Local APIC (type-0 entry type) only. This is the same case even for NMI structure reporting. The Processor X2APIC Affinity structure provides the association between the X2APIC ID of a logical processor and the proximity domain to which the logical processor belongs. For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device() objects in the ACPI namespace. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_tRusty Russell2009-01-031-4/+10
| | | | | | | | | | | | | | | Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Merge branch 'processor-256' into releaseLen Brown2008-11-121-37/+49
|\
| * ACPI: 80 column adherence and spelling fix (no functional change)Myron Stowe2008-11-071-3/+4
| | | | | | | | | | Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Behave uniquely based on processor declaration definition typeMyron Stowe2008-11-071-34/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Associating a Local SAPIC with a processor object is dependent upon the processor object's definition type. CPUs declared as "Processor" should use the Local SAPIC's 'processor_id', and CPUs declared as "Device" should use the 'uid'. Note that for "Processor" declarations, even if a '_UID' child object exists, it has no bearing with respect to mapping Local SAPICs (see section 5.2.11.13 - Local SAPIC Structure; "Advanced Configuration and Power Interface Specification", Revision 3.0b). This patch changes the lsapic mapping logic to rely on the distinction of how the processor object was declared - the mapping can't just try both types of matches regardless of declaration type and rely on one failing as is currently being done. Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Disambiguate processor declaration typeMyron Stowe2008-11-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Declaring processors in ACPI namespace can be done using either a "Processor" definition or a "Device" definition (see section 8.4 - Declaring Processors; "Advanced Configuration and Power Interface Specification", Revision 3.0b). Currently the two processor declaration types are conflated. This patch disambiguates the processor declaration's definition type enabling subsequent code to behave uniquely based explicitly on the declaration's type. Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'sysfs' into releaseLen Brown2008-11-121-3/+3
|\ \
| * | ACPI: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2008-11-071-3/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is part of a larger patch series which will remove the "char bus_id[20]" name string from struct device. The device name is managed in the kobject anyway, and without any size limitation, and just needlessly copied into "struct device". To set and read the device name dev_name(dev) and dev_set_name(dev) must be used. If your code uses static kobjects, which it shouldn't do, "const char *init_name" can be used to statically provide the name the registered device should have. At registration time, the init_name field is cleared, to enforce the use of dev_name(dev) to access the device name at a later time. We need to get rid of all occurrences of bus_id in the entire tree to be able to enable the new interface. Please apply this patch, and possibly convert any remaining remaining occurrences of bus_id. We want to submit a patch to -next, which will remove bus_id from "struct device", to find the remaining pieces to convert, and finally switch over to the new api, which will remove the 20 bytes array and does no longer have a size limitation. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Len Brown <len.brown@intel.com>
* / ACPI: consolidate ACPI_*_COMPONENT definitions in acpi_drivers.hBjorn Helgaas2008-11-081-1/+0Star
|/ | | | | | | | Move all the component definitions for drivers to a single shared place, include/acpi/acpi_drivers.h. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'ull' into testLen Brown2008-10-231-2/+2
|\ | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/bay.c drivers/acpi/dock.c drivers/ata/libata-acpi.c Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernelsMatthew Wilcox2008-10-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | As of version 2.0, ACPI can return 64-bit integers. The current acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms. Change the argument to take a pointer to an acpi_integer so we support 64-bit integers on all platforms. lenb: replaced use of "acpi_integer" with "unsigned long long" lenb: fixed bug in acpi_thermal_trips_update() Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: catch calls of acpi_driver_data on pointer of wrong typePavel Machek2008-10-111-1/+1
|/ | | | | | | | | | | Catch attempts to use of acpi_driver_data on pointers of wrong type. akpm: rewritten to use proper C typechecking and remove the "function"-used-as-lvalue thing. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: Fix typo in "Disable MWAIT via DMI on broken Compal board"Dennis Jansen2008-09-021-1/+1
| | | | | | | | | | | This fixes a typo in commit 2a2a64714d9c40f7705c4de1e79a5b855c7211a9 "Disable MWAIT via DMI on broken Compal board". It allows the nomwait dmi check to actually detect the Acer 5220. Signed-off-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Dennis Jansen <dennis.jansen@web.de> Acked-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* acpi: trivial cleanupsPavel Machek2008-08-151-1/+1
| | | | | | | | | | Trivial cleanups for ACPI. Fix misspelling in printk(), fix mismerge, add file header. AK: removed file header Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* driver core: fix a lot of printk usages of bus_idGreg Kroah-Hartman2008-07-221-3/+2Star
| | | | | | | | | | We have the dev_printk() variants for this kind of thing, use them instead of directly trying to access the bus_id field of struct device. This is done in order to remove bus_id entirely. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ACPI: Disable MWAIT via DMI on broken Compal boardZhao Yakui2008-07-161-0/+28
| | | | | | | | | | | | | | | If a system matches in this DMI table, Linux will disable MWAIT support for idle. ie. "idle=nomwait" is automatically invoked and C1_FFH and C2C3_FFH access mode are disabled. http://bugzilla.kernel.org/show_bug.cgi?id=10807 http://bugzilla.kernel.org/show_bug.cgi?id=10914 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> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* ACPI : Create "idle=nomwait" bootparamZhao Yakui2008-07-161-0/+13
| | | | | | | | | | | | | | | | | | | | | | "idle=nomwait" disables the use of the MWAIT instruction from both C1 (C1_FFH) and deeper (C2C3_FFH) C-states. When MWAIT is unavailable, the BIOS and OS generally negotiate to use the HALT instruction for C1, and use IO accesses for deeper C-states. This option is useful for power and performance comparisons, and also to work around BIOS bugs where broken MWAIT support is advertised. http://bugzilla.kernel.org/show_bug.cgi?id=10807 http://bugzilla.kernel.org/show_bug.cgi?id=10914 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> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* ACPI: change processors from array to per_cpu variableMike Travis2008-07-161-11/+9Star
| | | | | | | | | Change processors from an array sized by NR_CPUS to a per_cpu variable. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* create sysfs link from acpi device to sysdev for cpuZhang Rui2008-07-161-1/+7
| | | | | | | | | | | Sys I/F under acpi device node and sysdev device node are both needed for cpu hot-removal. User space need this link so that they know they are poking the sys I/F for the same cpu. http://bugzilla.kernel.org/show_bug.cgi?id=9772 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* force offline the processor during hot-removalZhang Rui2008-07-161-3/+3
| | | | | | | | | | | The ACPI device node for the cpu has already been unregistered when acpi_processor_handle_eject is called. Thus we should offline the cpu and continue, rather than a failure here. http://bugzilla.kernel.org/show_bug.cgi?id=9772 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* proper prototype for acpi_processor_tstate_has_changed()Adrian Bunk2008-06-121-1/+0Star
| | | | | | | | | | This patch adds a proper prototype for acpi_processor_tstate_has_changed() in include/acpi/processor.h Signed-off-by: Adrian Bunk <bunk@kernel.org> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'release' of ↵Linus Torvalds2008-04-301-16/+15Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (179 commits) ACPI: Fix acpi_processor_idle and idle= boot parameters interaction acpi: fix section mismatch warning in pnpacpi intel_menlo: fix build warning ACPI: Cleanup: Remove unneeded, multiple local dummy variables ACPI: video - fix permissions on some proc entries ACPI: video - properly handle errors when registering proc elements ACPI: video - do not store invalid entries in attached_array list ACPI: re-name acpi_pm_ops to acpi_suspend_ops ACER_WMI/ASUS_LAPTOP: fix build bug thinkpad_acpi: fix possible NULL pointer dereference if kstrdup failed ACPI: check a return value correctly in acpi_power_get_context() #if 0 acpi/bay.c:eject_removable_drive() eeepc-laptop: add hwmon fan control eeepc-laptop: add backlight eeepc-laptop: add base driver ACPI: thinkpad-acpi: bump up version to 0.20 ACPI: thinkpad-acpi: fix selects in Kconfig ACPI: thinkpad-acpi: use a private workqueue ACPI: thinkpad-acpi: fluff really minor fix ACPI: thinkpad-acpi: use uppercase for "LED" on user documentation ... Fixed conflicts in drivers/acpi/video.c and drivers/misc/intel_menlow.c manually.
| * ACPI: elide a non-zero test on a result that is never 0Julia Lawall2008-04-291-16/+15Star
| | | | | | | | | | | | | | | | | | | | thermal_cooling_device_register used to return NULL if THERMAL is "n". As the ACPI fan, processor and video drivers SELECT the generic thermal in PATCH 01, this is not a problem any more. Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | [IA64] Provide ACPI fixup for /proc/cpuinfo/physical_idAlex Chiang2008-04-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Legacy HP ia64 platforms currently cannot provide /proc/cpuinfo/physical_id due to legacy SAL/PAL implementations. However, that physical topology information can be obtained via ACPI. Provide an interface that gives ACPI one last chance to provide physical_id for these legacy platforms. This logic only comes into play iff: - ACPI actually provides slot information for the CPU - we lack a valid socket_id Otherwise, we don't do anything. Since x86 uses the ACPI processor driver as well, we provide a nop stub function for arch_fix_phys_package_id() in asm-x86/topology.h Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* | acpi: use non-racy method for proc entries creationDenis V. Lunev2008-04-291-24/+15Star
|/ | | | | | | | | | | | | | Use proc_create()/proc_create_data() to make sure that ->proc_fops and ->data be setup before gluing PDE to main tree. Add correct ->owner to proc_fops to fix reading/module unloading race. Signed-off-by: Denis V. Lunev <den@openvz.org> Cc: Len Brown <lenb@kernel.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* acpi: fix "buggy BIOS check" when CPUs are hot removedAlok Kataria2008-04-091-1/+1
| | | | | | | | | | | | | | | Fixes a BUG in ACPI hotplugging. processor_device_array[pr->id] needs to be set to NULL when removing a CPU. Else the "buggy BIOS check" in acpi_processor_start mistakenly fires when a CPU is removed from the system and then later re-added. Signed-off-by: Alok N Kataria <akataria@vmware.com> Signed-off-by: Dan Arai <arai@vmware.com> Cc: Len Brown <lenb@kernel.org> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* revert "ACPI: drivers/acpi: elide a non-zero test on a result that is never 0"Ingo Molnar2008-03-281-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 1192aeb957402b45f311895f124e4ca41206843c ("ACPI: drivers/acpi: elide a non-zero test on a result that is never 0") because it turns out that thermal_cooling_device_register() does actually return NULL if CONFIG_THERMAL is turned off (then the routine turns into a dummy inline routine in the header files that returns NULL unconditionally). This was found with randconfig testing, causing a crash during bootup: initcall 0x78878534 ran for 13 msecs: acpi_button_init+0x0/0x51() Calling initcall 0x78878585: acpi_fan_init+0x0/0x2c() BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd *pde = 00000000 Oops: 0000 [#1] Modules linked in: Pid: 1, comm: swapper Not tainted (2.6.25-rc7-sched-devel.git-x86-latest.git #14) EIP: 0060:[<782b8ad0>] EFLAGS: 00010246 CPU: 0 EIP is at acpi_fan_add+0x7d/0xfd EAX: b787c718 EBX: b787c400 ECX: b782ceb4 EDX: 00000007 ESI: 00000000 EDI: b787c6f4 EBP: b782cee0 ESP: b782cecc DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Process swapper (pid: 1, ti=b782c000 task=b7846000 task.ti=b782c000) Stack: b787c459 00000000 b787c400 78790888 b787c60c b782cef8 782b6fb8 ffffffda b787c60c 00000000 78790958 b782cf0c 783005d7 b787c60c 78790958 78790584 b782cf1c 783007f6 b782cf28 00000000 b782cf40 782ffc4a 78790958 b794d558 Call Trace: [<782b6fb8>] ? acpi_device_probe+0x3e/0xdb [<783005d7>] ? driver_probe_device+0x82/0xfc [<783007f6>] ? __driver_attach+0x3a/0x70 [<782ffc4a>] ? bus_for_each_dev+0x3e/0x60 [<7830048c>] ? driver_attach+0x14/0x16 [<783007bc>] ? __driver_attach+0x0/0x70 [<7830006a>] ? bus_add_driver+0x9d/0x1b0 [<783008c3>] ? driver_register+0x47/0xa3 [<7813db00>] ? timespec_to_ktime+0x9/0xc [<782b7331>] ? acpi_bus_register_driver+0x3a/0x3c [<78878592>] ? acpi_fan_init+0xd/0x2c [<78863656>] ? kernel_init+0xac/0x1f9 [<788635aa>] ? kernel_init+0x0/0x1f9 [<78114563>] ? kernel_thread_helper+0x7/0x10 ======================= Code: 6e 78 e8 57 44 e7 ff 58 e9 93 00 00 00 8b 55 f0 8d bb f4 02 00 00 80 4b 2d 10 8b 03 e8 87 cb ff ff 8d 83 18 03 00 00 80 63 2d ef <ff> 35 00 00 00 00 50 68 e8 9c 6e 78 e8 22 44 e7 ff b9 b6 9c 6e EIP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd SS:ESP 0068:b782cecc ---[ end trace 778e504de7e3b1e3 ]--- Kernel panic - not syncing: Attempted to kill init! Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Julia Lawall <julia@diku.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ACPI: drivers/acpi: elide a non-zero test on a result that is never 0Julia Lawall2008-03-271-16/+14Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function thermal_cooling_device_register always returns either a valid pointer or a value made with ERR_PTR, so a test for non-zero on the result will always succeed. The problem was found using the following semantic match. (http://www.emn.fr/x-info/coccinelle/) //<smpl> @a@ expression E, E1; statement S,S1; position p; @@ E = thermal_cooling_device_register(...) ... when != E = E1 if@p (E) S else S1 @n@ position a.p; expression E,E1; statement S,S1; @@ E = NULL ... when != E = E1 if@p (E) S else S1 @depends on !n@ expression E; statement S,S1; position a.p; @@ * if@p (E) S else S1 //</smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
*---. Merge branches 'release', 'button-sysfs', 'misc', 'mismatch', 'randconfig' ↵Len Brown2008-03-131-4/+5
|\ \ \ | | | | | | | | | | | | and 'toshiba' into release
| | | * ACPI: fix section mismatch in processor_core.c:acpi_processor_hotplug_notifySam Ravnborg2008-02-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix following warning: WARNING: vmlinux.o(.text+0x55586c): Section mismatch in reference from the function acpi_processor_hotplug_notify() to the function .cpuinit.text:acpi_processor_start() acpi_processor_hotplug_notify() may safely reference __cpuinit stuff as it ids defined inside an ACPI_HOTPLUG_CPU block. So annotate it __ref to silence the warning. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | ACPI: use ACPI_DEBUG_PRINT instead of printk in acpi_processor_hotplug_notify()Glauber Costa2008-03-111-2/+3
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | For consistency, use ACPI_DEBUG_PRINT instead of printk in acpi_processor_hotplug_notify() for BUS_CHECK and DEVICE_CHECK events Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* / / ACPI Exception (): AE_NOT_FOUND, Processor Device is not present (update)Zhang Rui2008-02-231-7/+9
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | update cfaf3747ff3d431fba33f75083b7f50f58ae22ff ACPI: ACPI Exception (): AE_NOT_FOUND, Processor Device is not present is_processor_present is only called in the processor hotplug case, and _STA method is mandatory at this time. We should ignore those processors that are disabled in the MADT and don't have _STA methods. Because they will never exist in this system. For the processors that don't physically exist but can be hot plugged later, we still need this debug info. http://bugzilla.kernel.org/show_bug.cgi?id=8570 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| |
| \
| \
| \
*---. \ Merge branches 'release', 'bugzilla-9916', 'bugzilla-9982', 'bugzilla-9989', ↵Len Brown2008-02-211-17/+22
|\ \ \ \ | |_|_|/ |/| | | | | | | 'misc', 'suspend', 'thermal', 'thinkpad' and 'tsc' into release
| | | * ACPI thermal: extract return values using PTR_ERRThomas Sujith2008-02-161-15/+22
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | Need to extract errors using PTR_ERR macro and process accordingly.thermal_cooling_device_register returning NULL means that CONFIG_THERMAL=n and in that case no need to create symbolic links. Signed-off-by: Thomas Sujith <sujith.thomas@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | * ACPI: remove is_processor_present prototypeGlauber Costa2008-02-161-2/+0Star
| |/ |/| | | | | | | | | | | | | | | The function itself is defined just below, so this prototype is not really useful. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: thermal: Check whether cooling device exists before unregisteringZhao Yakui2008-02-161-4/+6
|/ | | | | | | | | | | | OS should check whether the cooling device exists before it is unregistered. If it doesn't exists, it is unnecessary to remove the sysfs link and call the function of thermal_cooling_device_unregister. http://bugzilla.kernel.org/show_bug.cgi?id=9982 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Tested-by : Dhaval Giani <dhaval@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branches 'release' and 'throttling-domains' into releaseLen Brown2008-02-071-0/+2
|\
| * ACPI : Update T-state coordination after getting _TSD infoZhao Yakui2008-02-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Accordint to ACPI spec, the _TSD object provides T-state control cross logical processor dependency information to OSPM. After the _TSD data for all cpus are obtained, OSPM will set up the T-state coordination between CPUs. Of course if the _TSD doesn't exist or _TSD data is incorrect , it is assumed that there is no T-state coordination and T-state is changed independently. Now there is no proper solution to update T-state coordination after one cpu is hotplugged. So this patch won't support hotplugged cpu very well. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branches 'release' and 'menlo' into releaseLen Brown2008-02-071-0/+23
|\ \ | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/video.c Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: register ACPI Processor as generic thermal cooling deviceZhang Rui2008-02-021-0/+23
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Register ACPI processor as thermal cooling devices. A combination of processor T-state and P-state are used for thermal throttling. the processor will reduce the frequency first and then set the T-state. we use cpufreq_thermal_reduction_pctg to calculate the cpufreq limit, and call cpufreq_verify_with_limit to set the cpufreq limit. if cpufreq driver is loaded, then we have four cooling state for cpufreq control. cooling state 0: cpufreq limit == max_freq cooling state 1: cpufreq limit == max_freq * 80% cooling state 2: cpufreq limit == max_freq * 60% cooling state 3: cpufreq limit == max_freq * 40% after the cpufreq limit is set to 40 percentage of the max_freq, we use T-state for cooling. eg. a processor has P-state support, and it has 8 T-state (T0-T7), the max_state of the proceesor is 10: state cpufreq-limit T-state 0: max_freq T0 1: max_freq * 80% T0 2: max_freq * 60% T0 3: max_freq * 40% T0 4: max_freq * 40% T1 5: max_freq * 40% T2 6: max_freq * 40% T3 7: max_freq * 40% T4 8: max_freq * 40% T5 9: max_freq * 40% T6 10: max_freq * 40% T7 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Thomas Sujith <sujith.thomas@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* / ACPI: ACPI Exception (): AE_NOT_FOUND, Processor Device is not presentZhang Rui2008-01-091-5/+12
|/ | | | | | | | | | | | | | | | | | | ACPI Exception (acpi_processor-0677): AE_NOT_FOUND, Processor Device is not present [20060707] According to the ACPI spec 6.3.7, "If a device object (including the processor object) does not have an _STA object, then OSPM assumes that all of the above bits are set, (in other words, the device is present, enabled, shown in the UI and funtioning)". is_processor_present shoud return 1 if the processor device object exists while it doesn't have an _STA object. http://bugzilla.kernel.org/show_bug.cgi?id=8570 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: avoid references to impossible processors.Christoph Lameter2007-11-291-7/+7
| | | | | | | | | | | | | | | | | | | | | | ACPI uses NR_CPUS in various loops and in some it accesses per cpu data of processors that are not present(!) and that will never be present. The pointers to per cpu data are typically not initialized for processors that are not present. So we seem to be reading something here from offset 0 in memory. Make ACPI use nr_cpu_ids instead. That stops at the end of the possible processors. Convert one loop to NR_CPUS to use the cpu_possible map instead. That way ranges of processor that can never be brought online are skipped during the loop. Signed-off-by: Christoph Lameter <clameter@sgi.com> Cc: Len Brown <lenb@kernel.org> Acked-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Pull bugzilla-9327 into release branchLen Brown2007-11-211-1/+4
|\ | | | | | | | | | | | | | | Conflicts: drivers/acpi/ec.c Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-11 19:20:12 +0200