summaryrefslogtreecommitdiff
path: root/drivers/acpi/processor_core.c
AgeCommit message (Collapse)Author
2010-07-12ACPI: processor: fix processor_physically_present on UPAlex Chiang
The commit 5d554a7bb06 (ACPI: processor: add internal processor_physically_present()) is broken on uniprocessor (UP) configurations, as acpi_get_cpuid() will always return -1. We use the value of num_possible_cpus() to tell us whether we got an invalid cpuid from acpi_get_cpuid() in the SMP case, or if instead, we are UP, in which case num_possible_cpus() is #defined as 1. We use num_possible_cpus() instead of num_online_cpus() to protect ourselves against the scenario of CPU hotplug, and we've taken down all the CPUs except one. Thanks to Jan Pogadl for initial report and analysis and Chen Gong for review. https://bugzilla.kernel.org/show_bug.cgi?id=16357 Reported-by: Jan Pogadl <pogadl.jan@googlemail.com>: Reviewed-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-14ACPI: processor: push file static MADT pointer into internal map_madt_entry()Alex Chiang
There's no real need for a pointer to the MADT to be global. The only function who uses it is map_madt_entry. This allows us to remove some more ugly #ifdefs. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: refactor internal map_lsapic_id()Alex Chiang
Un-nest the if statements for readability. Remove comments that re-state the obvious. Change the control flow so that we no longer need a temp variable. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: refactor internal map_x2apic_id()Alex Chiang
Untangle the nested if conditions to make this function look more similar to the other map_*apic_id() functions. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: refactor internal map_lapic_id()Alex Chiang
Untangle the if() statement a little for readability. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: driver doesn't need to evaluate _PDCAlex Chiang
Now that the early _PDC evaluation path knows how to correctly evaluate _PDC on only physically present processors, there's no need for the processor driver to evaluate it later when it loads. To cover the hotplug case, push _PDC evaluation down into the hotplug paths. Cc: x86@kernel.org Cc: Tony Luck <tony.luck@intel.com> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: remove early _PDC optin quirksAlex Chiang
Now that we check for physically present processors before blindly evaluating _PDC, we no longer need to maintain a DMI opt-in table nor a kernel param. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: add internal processor_physically_present()Alex Chiang
Detect if a processor is physically present before evaluating _PDC. We want this because some BIOS will provide a _PDC even for processors that are not present. These bogus _PDC methods then attempt to load non-existent tables, which causes problems. Avoid those bogus landmines. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: move acpi_get_cpuid into processor_core.cAlex Chiang
Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: mv processor_pdc.c processor_core.cAlex Chiang
We've renamed the old processor_core.c to processor_driver.c, to convey the idea that it can be built modular and has driver-like bits. Now let's re-create a processor_core.c for the bits needed statically by the rest of the kernel. The contents of processor_pdc.c are a good starting spot, so let's just rename that file and complete our three card monte. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: processor: mv processor_core.c processor_driver.cAlex Chiang
The ACPI processor driver can be built as a module. But it has pieces of code that should always be built statically into the kernel. The plan is for processor_core.c to contain the static bits while processor_driver.c contains the module-like bits. Since the bulk of the code in the current processor_core.c is module-like, first step is to rename the file to processor_driver.c Next step will re-create processor_core.c and cherry-pick out the static bits. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-07Merge branch 'next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] Fix cast warning in pcc driver. [CPUFREQ] Processor Clocking Control interface driver
2010-01-13[CPUFREQ] Processor Clocking Control interface driverNaga Chumbalkar
Processor Clocking Control (PCC) is an interface between the BIOS and OSPM. Based on the server workload, OSPM can request what frequency it expects from a logical CPU, and the BIOS will achieve that frequency transparently. This patch introduces driver support for PCC. OSPM uses the PCC driver to communicate with the BIOS via the PCC interface. There is a Documentation file that provides a link to the PCC Specification, and also provides a summary of the PCC interface. Currently, certain HP ProLiant platforms implement the PCC interface. However, any platform whose BIOS implements the PCC Specification, can utilize this driver. V2 --> V1 changes (based on Dominik's suggestions): - Removed the dependency on CPU_FREQ_TABLE - "cpufreq_stats" will no longer PANIC. Actually, it will not load anymore because it is not applicable. - Removed the sanity check for target frequency in the ->target routine. NOTE: A patch to sanitize the target frequency requested by "ondemand" is needed to ensure that the target freq < policy->min. Can this driver be queued up for the 2.6.33 tree? Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
2009-12-22ACPI: processor: change acpi_processor_set_pdc() interfaceAlex Chiang
When calling _PDC, we really only need the handle to the processor to call the method; we don't look at any other parts of the struct acpi_processor * given to us. In the early path, when we walk the namespace, we are given the handle directly, so just pass it through to acpi_processor_set_pdc() without stuffing it into a wasteful struct acpi_processor allocated on the stack each time This saves 2834 bytes of stack. Update the interface accordingly. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-22ACPI: processor: call _PDC earlyAlex Chiang
We discovered that at least one machine (HP Envy), methods in the DSDT attempt to call external methods defined in a dynamically loaded SSDT. Unfortunately, the DSDT methods we are trying to call are part of the EC initialization, which happens very early, and the the dynamic SSDT is only loaded when a processor _PDC method runs much later. This results in namespace lookup errors for the (as of yet) undefined methods. Since Windows doesn't have any issues with this machine, we take it as a hint that they must be evaluating _PDC much earlier than we are. Thus, the proper thing for Linux to do should be to match the Windows implementation more closely. Provide a mechanism to call _PDC before we enable the EC. Doing so loads the dynamic tables, and allows the EC to be enabled correctly. The ACPI processor driver will still evaluate _PDC in its .add() method to cover the hotplug case. Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824 Cc: ming.m.lin@intel.com Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16Merge branch 'misc-2.6.33' into releaseLen Brown
2009-12-16ACPI processor: Fix section mismatch for processor_add()Thomas Renninger
Due to the merge of processor_start() (declared with __cpuinit) into processor_add(), a section mismatch warning appears: WARNING: drivers/built-in.o(.text+0x4d59d): Section mismatch in reference from the function acpi_processor_add() to the function .cpuinit.text:acpi_processor_power_init() ... This patch fixes the warning by declaring processor_add() as __cpuinit and also declares acpi_processor_add_fs() as __cpuinit as it is only used in acpi_processor_add(). Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16Merge branch 'ost' into releaseLen Brown
Conflicts: include/acpi/processor.h Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16ACPI: Remove repeated registered as cooling_device messagesMike Travis
This message shows up for each cpu. Print as debug messages. [ 12.893967] processor ACPI0007:00: registered as cooling_device0 [ 12.907838] processor ACPI0007:01: registered as cooling_device1 Signed-off-by: Mike Travis <travis@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: linux-acpi@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
2009-11-24ACPICA: Add post-order callback to acpi_walk_namespaceLin Ming
The existing interface only has a pre-order callback. This change adds an additional parameter for a post-order callback which will be more useful for bus scans. ACPICA BZ 779. Also update the external calls to acpi_walk_namespace. http://www.acpica.org/bugzilla/show_bug.cgi?id=779 Signed-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>
2009-11-06ACPI: Notify the _PPC evaluation status to the platformZhao Yakui
According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-11-05ACPI: add __cpuinit to acpi_processor_add()Rakib Mullick
Annote acpi_processor_add with cpuinit since it calls a cpuinit function acpi_processor_power_init and fixes a section mismatch warning. We were warned by the following warning: LD drivers/acpi/processor.o WARNING: drivers/acpi/processor.o(.text+0x1829): Section mismatch in reference from the function acpi_processor_add() to the function .cpuinit.text:acpi_processor_power_init() The function acpi_processor_add() references the function __cpuinit acpi_processor_power_init(). This is often because acpi_processor_add lacks a __cpuinit annotation or the annotation of acpi_processor_power_init is wrong. Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-03ACPI: kill overly verbose "throttling states" log messagesRoland Dreier
I was recently lucky enough to get a 64-CPU system. The processors actually have T-states, so my kernel log ends up with 64 lines like: ACPI: Processor [CPU0] (supports xx throttling states) This is pretty useless clutter because - this info is already available after boot from /proc/acpi/processor/CPUnn/throttling - there's also an ACPI_DEBUG_PRINT() in processor_throttling.c that gives the same info on boot for anyone who *really* cares. So just delete the code that prints the throttling states in processor_core.c. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-19Merge branch 'processor-procfs-2.6.32' into releaseLen Brown
2009-09-19Merge branch 'bjorn-start-stop-2.6.32' into releaseLen Brown
2009-08-28ACPI: Move definition of PREFIX from acpi_bus.h to internal..hLen Brown
Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-26acpi: don't call acpi_processor_init if acpi is disabledYinghai Lu
Jens reported early_ioremap messages with old ASUS board... > [ 1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling > [ 1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36 > [ 1.561007] Call Trace: > [ 1.568638] [<c136e48b>] ? printk+0x18/0x1d > [ 1.581734] [<c15513ff>] __early_ioremap+0x74/0x1e9 > [ 1.596898] [<c15515aa>] early_ioremap+0x1a/0x1c > [ 1.611270] [<c154a187>] __acpi_map_table+0x18/0x1a > [ 1.626451] [<c135a7f8>] acpi_os_map_memory+0x1d/0x25 > [ 1.642129] [<c119459c>] acpi_tb_verify_table+0x20/0x49 > [ 1.658321] [<c1193e50>] acpi_get_table_with_size+0x53/0xa1 > [ 1.675553] [<c1193eae>] acpi_get_table+0x10/0x15 > [ 1.690192] [<c155cc19>] acpi_processor_init+0x23/0xab > [ 1.706126] [<c1001043>] do_one_initcall+0x33/0x180 > [ 1.721279] [<c155cbf6>] ? acpi_processor_init+0x0/0xab > [ 1.737479] [<c106893a>] ? register_irq_proc+0xaa/0xc0 > [ 1.753411] [<c10689b7>] ? init_irq_proc+0x67/0x80 > [ 1.768316] [<c15405e7>] kernel_init+0x120/0x176 > [ 1.782678] [<c15404c7>] ? kernel_init+0x0/0x176 > [ 1.797062] [<c10038b7>] kernel_thread_helper+0x7/0x10 > [ 1.812984] 00000080 + ffe00000 that is rather later. acpi_gbl_permanent_mmap should be set in acpi_early_init() if acpi is not disabled and we have > [ 0.000000] ASUS P2B-DS detected: force use of acpi=ht just don't load acpi_processor_init... Reported-and-tested-by: Jens Rosenboom <jens@leia.mcbone.net> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-25ACPI: processor: remove .start() methodBjorn Helgaas
This patch folds the .start() method into .add(). acpi_processor_start() is always called immediately after acpi_processor_add(), so there's really no point in having them be separate methods. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.com> CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-25ACPI: processor: move acpi_processor_start() after acpi_processor_add()Bjorn Helgaas
Move acpi_processor_start() to just after acpi_processor_add(). A subsequent patch will merge them. Code movement only; no functional change. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-25ACPI: processor: clean up in acpi_processor_start() error exitsBjorn Helgaas
We used to leave crud around if things failed in acpi_processor_start(). This patch cleans up as much as we can before returning. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.com> CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-25ACPI: processor: remove KOBJ_ONLINE/KOBJ_OFFLINE eventsBjorn Helgaas
This patch removes the KOBJ_ONLINE/KOBJ_OFFLINE events the driver used to generate for CPU hotplug. As far as I know, nobody consumes these. The driver core still generates KOBJ_ADD and KOBJ_REMOVE, of course. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> CC: Matthew Garrett <mjg@redhat.com> CC: Thomas Renninger <trenn@suse.de> CC: Dave Jones <davej@codemonkey.org.uk> CC: Kay Sievers <kay.sievers@vrfy.org> CC: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-24Merge branches 'acerhdf', 'acpi-pci-bind', 'bjorn-pci-root', ↵Len Brown
'bugzilla-12904', 'bugzilla-13121', 'bugzilla-13396', 'bugzilla-13533', 'bugzilla-13612', 'c3_lock', 'hid-cleanups', 'misc-2.6.31', 'pdc-leak-fix', 'pnpacpi', 'power_nocheck', 'thinkpad_acpi', 'video' and 'wmi' into release
2009-06-24ACPI: Rename ACPI processor device bus IDZhao Yakui
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>
2009-06-24ACPI: Make ACPI processor proc I/F depend on the ACPI_PROCFSZhao Yakui
Now whether the ACPI processor proc I/F is registered depends on the CONFIG_PROC. It had better depend on the CONFIG_ACPI_PROCFS. When the CONFIG_ACPI_PROCFS is unset in kernel configuration, the ACPI processor proc I/F won't be registered. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-20ACPI: pdc init related memory leak with physical CPU hotplugPallipadi, Venkatesh
arch_acpi_processor_cleanup_pdc() in x86 and ia64 results in memory allocated for _PDC objects that is never freed and will cause memory leak in case of physical CPU remove and add. Patch fixes the memory leak by freeing the objects soon after _PDC is evaluated. Reported-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-09cpumask: alloc zeroed cpumask for static cpumask_var_tsYinghai Lu
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>
2009-05-27ACPI: processor: move device _HID into driverBjorn Helgaas
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>
2009-05-27ACPI: processor: check for synthetic _HID, default to "Device" declarationBjorn Helgaas
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>
2009-04-05ACPI: processor: use .notify method instead of installing handler directlyBjorn Helgaas
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>
2009-04-05Merge branch 'linus' into releaseLen Brown
Conflicts: arch/x86/kernel/cpu/cpufreq/longhaul.c Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-03x86, ACPI: add support for x2apic ACPI extensionsSuresh Siddha
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>
2009-03-31proc 2/2: remove struct proc_dir_entry::ownerAlexey Dobriyan
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>
2009-01-03cpumask: convert shared_cpu_map in acpi_processor* structs to cpumask_var_tRusty Russell
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>
2008-11-11Merge branch 'processor-256' into releaseLen Brown
2008-11-11Merge branch 'sysfs' into releaseLen Brown
2008-11-07ACPI: consolidate ACPI_*_COMPONENT definitions in acpi_drivers.hBjorn Helgaas
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>
2008-11-06ACPI: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers
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>
2008-11-06ACPI: 80 column adherence and spelling fix (no functional change)Myron Stowe
Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: Behave uniquely based on processor declaration definition typeMyron Stowe
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>