- 03 3月, 2011 1 次提交
-
-
由 Jan Beulich 提交于
Use __init for several functions, remove an unnecessary export and a stray use of __ref. Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 11 1月, 2011 1 次提交
-
-
由 Zhao Yakui 提交于
After one CPU is offlined, it is unnecessary to switch T-state for it. So it will be better that the throttling is disabled after the cpu is offline. At the same time after one cpu is online, we should check whether the T-state is supported and then set the corresponding T-state flag. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 12月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
Remove deprecated ACPI process procfs I/F for throttling control. This is because the t-state control should only be done in kernel, when system is in a overheating state. Now users can only change the processor t-state indirectly, by poking the cooling device sysfs I/F of the processor. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 10月, 2010 1 次提交
-
-
由 Stephen Hemminger 提交于
Found by running make namespacecheck on linux-next Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 10月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
As a feature that would only be used when system is overheating, the processor t-state control should not be exported to user space. Make /proc/acpi/processor/*/throttle depends on CONFIG_ACPI_PROCFS, which is cleared by default. And we will remove this I/F in 2.6.38. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 29 9月, 2010 1 次提交
-
-
由 Len Brown 提交于
otherwise, these two lines print as one: ACPI: acpi_idle yielding to intel_idle ACPI: SSDT 3f5d8741 00203 (v02 PmRef Cpu0Ist 00003000 INTL 20050624) Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 15 8月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
Remove deprecated ACPI processor procfs I/F, including: /proc/acpi/processor/CPUX/power /proc/acpi/processor/CPUX/limit /proc/acpi/processor/CPUX/info /proc/acpi/processor/CPUX/throttling still exists, as we don't have sysfs I/F available for now. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 10 6月, 2010 1 次提交
-
-
由 Thomas Renninger 提交于
Patch is against latest Linus master branch and is expected to be safe bug fix. You get: ACPI: HARDWARE addr space,NOT supported yet for each ACPI defined CPU which status is active, but exceeds maxcpus= count. As these "not booted" CPUs do not run an idle routine and echo X >/proc/acpi/processor/*/throttling did not work I couldn't find a way to really access not onlined/booted machines. Still this should get fixed and /proc/acpi/processor/X dirs of cores exceeding maxcpus should not show up. I wonder whether this could get cleaned up by truncating possible cpu mask and nr_cpu_ids to setup_max_cpus early some day (and not exporting setup_max_cpus anymore then). But this needs touching of a lot other places... Signed-off-by: NThomas Renninger <trenn@suse.de> CC: travis@sgi.com CC: linux-acpi@vger.kernel.org CC: lenb@kernel.org Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 29 5月, 2010 1 次提交
-
-
由 Len Brown 提交于
This EXPERIMENTAL driver supersedes acpi_idle on Intel Atom Processors, Intel Core i3/i5/i7 Processors and associated Intel Xeon processors. It does not support the Intel Core2 processor or earlier. For kernels configured with ACPI, CONFIG_INTEL_IDLE=y allows intel_idle to probe before the ACPI processor driver. Booting with "intel_idle.max_cstate=0" disables intel_idle and the system will fall back on ACPI's "acpi_idle". Typical Linux distributions load ACPI processor module early, making CONFIG_INTEL_IDLE=m not easily useful on ACPI platforms. intel_idle probes all processors at module_init time. Processors that are hot-added later will be limited to using C1 in idle. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 5月, 2010 1 次提交
-
-
由 Len Brown 提交于
The ACPI driver would fail probe when it found that another driver had previously registered with cpuidle. But this is a natural situation, as a native hardware cpuidle driver should be able to bind instead of ACPI, and the ACPI processor driver should be able to handle yielding control of C-states while still handling P-states and T-states. Add a KERN_DEBUG line showing when acpi_idle does successfully register. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 15 3月, 2010 4 次提交
-
-
由 Alex 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: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex 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: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex Chiang 提交于
Rename static get_cpu_id() to acpi_get_cpuid() and export it. This change also gives us an opportunity to remove the #ifndef CONFIG_SMP from processor_driver.c and into a header file where it properly belongs. Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex 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: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Naga 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: NNaga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 22 12月, 2009 2 次提交
-
-
由 Alex 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: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex 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: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 12月, 2009 1 次提交
-
-
由 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: NThomas Renninger <trenn@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 12月, 2009 1 次提交
-
-
由 Mike 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: NMike 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: NLen Brown <len.brown@intel.com>
-
- 25 11月, 2009 1 次提交
-
-
由 Lin 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=779Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 06 11月, 2009 2 次提交
-
-
由 Zhao 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: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 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: NRakib Mullick <rakib.mullick@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 03 10月, 2009 1 次提交
-
-
由 Roland 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: NRoland Dreier <rolandd@cisco.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 29 8月, 2009 1 次提交
-
-
由 Len 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: NLen Brown <len.brown@intel.com>
-
- 27 8月, 2009 1 次提交
-
-
由 Yinghai 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: NJens Rosenboom <jens@leia.mcbone.net> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NIngo Molnar <mingo@elte.hu> Cc: Len Brown <lenb@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 6月, 2009 4 次提交
-
-
由 Bjorn 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: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 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: NBjorn Helgaas <bjorn.helgaas@hp.com> CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn 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: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn 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: NBjorn 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: NLen Brown <len.brown@intel.com>
-
- 24 6月, 2009 2 次提交
-
-
由 Zhao 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=13612Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhao 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: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 6月, 2009 1 次提交
-
-
由 Pallipadi, 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: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 09 6月, 2009 1 次提交
-
-
由 Yinghai 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: NYinghai Lu <yinghai.lu@kernel.org> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 28 5月, 2009 2 次提交
-
-
由 Bjorn 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: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn 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: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 05 4月, 2009 1 次提交
-
-
由 Bjorn 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: NBjorn 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: NLen Brown <len.brown@intel.com>
-
- 04 4月, 2009 1 次提交
-
-
由 Suresh 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: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 31 3月, 2009 1 次提交
-
-
由 Alexey 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=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
-
- 04 1月, 2009 1 次提交
-
-
由 Rusty 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: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NMike Travis <travis@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-