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>
Some buggy BIOS exports multiple ACPI video bus devices for the same
VGA controller, and multiple backlight control methods as well.
This messes up the ACPI video backlight control.
http://bugzilla.kernel.org/show_bug.cgi?id=13577
With this patch applied, only the FIRST ACPI video bus device
under a PCI device node is bind to ACPI video driver by default.
If the first ACPI video bus device doesn't work well, we can use
video.allow_duplicates=1 to go back to the old behavior.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There are some fixes listed below:
1. When met a bogus BIOS, the return value of cpu number maybe is
a negative value so that acpi_pad_pur get an unexpected result.
2. the return value of function acpi_pad_idle_cpus is useless.
3. enhance the process of create_power_saving_task/destroy_power_saving_task
4. Add more error checks when evaluating _PUR object.
5. one typo fix
Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Introduce kernel parameter acpi_sleep=sci_force_enable
some laptop requires SCI_EN being set directly on resume,
or else they hung somewhere in the resume code path.
We already have a blacklist for these laptops but we still need
this option, especially when debugging some suspend/resume problems,
in case there are systems that need this workaround and are not yet
in the blacklist.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
backlight_device_register may return an ERR_PTR
value rather than a valid pointer.
Problem found by Julia Lawall, properly fixed by Zhang Rui.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Len Brown <len.brown@intel.com>
AML code always sends notifications to ACPI video device,
even if we disable the ACPI backlight control by using
boot option "acpi_backlight=vendor".
In this case we should not print any warning message.
http://bugzilla.kernel.org/show_bug.cgi?id=13671#c14
Sigend-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
If the ACPI power state can be got both directly and indirectly,
we prefer to get it indirectly.
https://bugzilla.redhat.com/show_bug.cgi?id=531916 describes a
system with a _PSC method for the fan that always returns "on".
There's no benefit in us always requesting the state of the fan
when performing transitions - we want to do everything we can
to ensure that the fan turns on when it should do, not risk
hardware damage by believing the hardware when it tells us the
fan is already on. Given that the Leading Other OS(tm) works fine
on this machine, it seems likely that it behaves in much this way.
inspired-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Split EC query handling into acknowledge and execution phase.
This allows much smaller pending query lattency and lowers chances
of EC going "wild" and losing events.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Executing _OSC returns a buffer, which has an acpi object in it.
Don't directly returns the buffer, instead, we return the acpi object's
buffer. This fixes a regression since caller of acpi_run_osc expects
an acpi object's buffer returned.
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
We have the acpi_object_list * right there in acpi_processor_set_pdc()
so it doesn't seem necessary for an entire helper function just to
free it.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_processor_eval_pdc() really only needs a handle and an
acpi_object_list * to do its work.
No need to pass in a struct acpi_processor *, so let's be more specific
about what we want.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_processor_init_pdc() isn't really doing anything interesting
with the struct acpi_processor * parameter. Its real job is to allocate
the buffer for the _PDC bits.
So rename the function to acpi_processor_alloc_pdc(), and just return
the struct acpi_object_list * it's supposed to allocate.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The x86 and ia64 implementations of the function in $subject are
exactly the same.
Also, since the arch-specific implementations of setting _PDC have
been completely hollowed out, remove the empty shells.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The only thing arch-specific about calling _PDC is what bits get
set in the input obj_list buffer.
There's no need for several levels of indirection to twiddle those
bits. Additionally, since we're just messing around with a buffer,
we can simplify the interface; no need to pass around the entire
struct acpi_processor * just to get at the buffer.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Both x86 and ia64 initialize _PDC with mostly common bit settings.
Factor out the common settings and leave the arch-specific ones alone.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The x86 and ia64 implementations of arch_acpi_processor_init_pdc()
are almost exactly the same. The only difference is in what bits
they set in obj_list buffer.
Combine the boilerplate memory management code, and leave the
arch-specific bit twiddling in separate implementations.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
arch dependent helper function that tells us if we should attempt to
evaluate _PDC on this machine or not.
The x86 implementation assumes that the CPUs in the machine must be
homogeneous, and that you cannot mix CPUs of different vendors.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
Fix a win7 compability issue on Asus K50IJ.
Here is the _BCM method of this laptop:
Method (_BCM, 1, NotSerialized)
{
If (LGreaterEqual (OSFG, OSVT))
{
If (LNotEqual (OSFG, OSW7))
{
Store (One, BCMD)
Store (GCBL (Arg0), Local0)
Subtract (0x0F, Local0, LBTN)
^^^SBRG.EC0.STBR ()
...
}
Else
{
DBGR (0x0B, Zero, Zero, Arg0)
Store (Arg0, LBTN)
^^^SBRG.EC0.STBR ()
...
}
}
}
LBTN is used to store the index of the brightness level in the _BCL.
GCBL is a method that convert the percentage value to the index value.
If _OSI(Windows 2009) is not disabled, LBTN is stored a percentage
value which is surely beyond the end of _BCL package.
http://bugzilla.kernel.org/show_bug.cgi?id=14753
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
v2->v1:
.improve debug info as suggedted by Bjorn,Kenji
.API is using uuid string as suggested by Alexey
Add an API to execute _OSC. A lot of devices can have this method, so add a
generic API.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
I got following warning on ia64 box:
In function 'acpi_processor_power_verify':
642: warning: passing argument 2 of 'smp_call_function_single' from
incompatible pointer type
This smp_call_function_single() was introduced by a commit
f833bab87f:
> @@ -162,8 +162,9 @@
> pr->power.timer_broadcast_on_state = state;
> }
>
> -static void lapic_timer_propagate_broadcast(struct acpi_processor *pr)
> +static void lapic_timer_propagate_broadcast(void *arg)
> {
> + struct acpi_processor *pr = (struct acpi_processor *) arg;
> unsigned long reason;
>
> reason = pr->power.timer_broadcast_on_state < INT_MAX ?
> @@ -635,7 +636,8 @@
> working++;
> }
>
> - lapic_timer_propagate_broadcast(pr);
> + smp_call_function_single(pr->id, lapic_timer_propagate_broadcast,
> + pr, 1);
>
> return (working);
> }
The problem is that the lapic_timer_propagate_broadcast() has 2 versions:
One is real code that modified in the above commit, and the other is NOP
code that used when !ARCH_APICTIMER_STOPS_ON_C3:
static void lapic_timer_propagate_broadcast(struct acpi_processor *pr) { }
So I got warning because of !ARCH_APICTIMER_STOPS_ON_C3.
We really want to do nothing here on !ARCH_APICTIMER_STOPS_ON_C3, so
modify lapic_timer_propagate_broadcast() of real version to use
smp_call_function_single() in it.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
drivers/acpi/acpi_pad.c: In function 'power_saving_thread':
drivers/acpi/acpi_pad.c:103: warning: 'preferred_cpu' may be used uninitialized in this function
Cc: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Removed some stray whitespaces
Added whitespace when needed for legibility
Removed unneeded curly braces
Removed useless void casts
Removed unnecessary local variable initialization
Renamed variables to help out with 80-column fixes
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Instead of adding a (struct dock_station **) to our dock device's
platform data, we can add the (struct dock_station *) directly.
This change saves us some ugly casting and improves readability.
The cost of making this change is an extra 290 bytes of stack usage,
but this is an infrequently called code-path and unlikely to cause
the kernel to blow up.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Move the call to platform_device_register_simple so that we do it
before allocating and initializing our struct dock_station.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We only use it in one spot, so it probably gets optimized out, but there's
still no need to use a global variable for this.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There's no real need to have a separate allocation step when adding
a dock dependent device.
Combining the two functions is both logical and helps with legibility.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Users can force a passive trip point for a thermal zone that does not have
_PSV defined in ACPI by setting the passive attribute in sysfs. It's
useful to display such trip points in /proc/acpi/thermal_zone.
.../TZ1/cooling_mode:<setting not supported>
.../TZ1/polling_frequency:polling frequency: 10 seconds
.../TZ1/state:state: ok
.../TZ1/temperature:temperature: 53 C
.../TZ1/trip_points:critical (S5): 110 C
.../TZ1/trip_points:passive (forced): 95 C
And if not set (passive is 0):
.../TZ1/trip_points:passive (forced):<not set>
Signed-off-by: Frans Pop <elendil@planet.nl>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
NUMA_NO_NODE has been exported globally and thus it can replace NID_INVAL
in the acpi code.
Also removes the unused acpi_unmap_pxm_to_node() function.
[akpm@linux-foundation.org: coding-style fixes]
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Reviewed-by: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
On some laptops it will return NOTIFY_OK(non-zero) when calling the ACPI LID
notifier. Then it is used as the result of ACPI LID resume function, which
will complain the following warning message in course of suspend/resume:
>PM: Device PNP0C0D:00 failed to resume: error 1
This patch is to eliminate the above warning message.
http://bugzilla.kernel.org/show_bug.cgi?id=14782
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
Add kernel tainting after overriding an ACPI control method successfully.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This change moves the check for a valid Thread ID structure up a
few lines to insure that the check is made before the structure
is actually used.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This change will automatically remove embedded and trailing NULL
package elements from returned package objects that are defined
to containe a variable number of sub-packages. The driver is then
presented with a package with no null elements to deal with.
ACPICA BZ 819.
http://www.acpica.org/bugzilla/show_bug.cgi?id=819
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This change enables the execution of _REG methods that appear
in the same scope as the module-level code, in resonse to an
operation region declaration within the module-level code.
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>
Only attempt the "complex" repairs (package sorting, buffer
expansion) if the previous "generic" validation and repair was
successful.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Update comments for repair of _FDE and _GTM methods.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Repair mechanism was considered too wordy. Now, messages are only
unconditionally emitted if the return object cannot be repaired.
Existing messages for successful repairs were converted to
ACPI_DEBUG_PRINT messages for now. ACPICA BZ 827.
http://www.acpica.org/bugzilla/show_bug.cgi?id=827
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Move code specific to _FDE and _GTM into the generic repair code.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes a problem where mutex errors can occur when running a _REG
method that is in the same scope as a method-defined operation
region or an operation region under a module-level IF block.
This is rare, so the problem has not been seen before.
ACPICA BZ 826.
http://www.acpica.org/bugzilla/show_bug.cgi?id=826
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixed a few errors with the headers in utcopy.c
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This change enhances the automatic repairs/conversions for
predefined name return values to make Integers, Strings, and
Buffers fully interchangeable. Also, a Buffer can be converted
to a Package of Integers if necessary. The nsrepair.c module was
completely restructured.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This change deletes the unnecessary acpi_ns_convert_entry_to_handle
interface and renames the acpi_ns_map_handle_to_node interface to
acpi_ns_validate_handle. ACPICA BZ 798.
http://www.acpica.org/bugzilla/show_bug.cgi?id=798
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The expected return value for both names is a Buffer of 5 DWORDS.
This repair fixes two possible problems (both seen in the field):
A package of integers is returned, or a buffer of BYTEs is returned.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
These messages were using the internal path for the message
instead of using the node name.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Both messages incorrectly used the internal Path string instead
of the node name.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
An object can be leaked for each block of executed module-level
code if the interpreter slack mode is enabled. The change deletes
any implicitly returned object in this case.
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>
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
[ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface
[CPUFREQ] make internal cpufreq_add_dev_* static
[CPUFREQ] use an enum for speedstep processor identification
[CPUFREQ] Document units for transition latency
[CPUFREQ] Use global sysfs cpufreq structure for conservative governor tunings
[CPUFREQ] Documentation: ABI: /sys/devices/system/cpu/cpu#/cpufreq/
[CPUFREQ] powernow-k6: set transition latency value so ondemand governor can be used
[CPUFREQ] cpumask: don't put a cpumask on the stack in x86...cpufreq/powernow-k8.c
Introduce a new debugfs I/F (/sys/kernel/debug/acpi/custom_method) for ACPI,
which can be used to customize the ACPI control methods at runtime.
We can use this to debug the AML code level bugs instead of overriding the
whole DSDT table, without rebuilding/rebooting kernel any more.
Detailed description about how to use this debugfs I/F is stated in
Documentation/acpi/method-customizing.txt
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPICA: Update version to 20091112.
ACPICA: Add additional module-level code support
ACPICA: Deploy new create integer interface where appropriate
ACPICA: New internal utility function to create Integer objects
ACPICA: Add repair for predefined methods that must return sorted lists
ACPICA: Fix possible fault if return Package objects contain NULL elements
ACPICA: Add post-order callback to acpi_walk_namespace
ACPICA: Change package length error message to an info message
ACPICA: Reduce severity of predefined repair messages, Warning to Info
ACPICA: Update version to 20091013
ACPICA: Fix possible memory leak for Scope ASL operator
ACPICA: Remove possibility of executing _REG methods twice
ACPICA: Add repair for bad _MAT buffers
ACPICA: Add repair for bad _BIF/_BIX packages
acpi_check_resource_conflict() doesn't change the resource
it operates on, so the res parameter can be marked const.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (36 commits)
x86, mm: Correct the implementation of is_untracked_pat_range()
x86/pat: Trivial: don't create debugfs for memtype if pat is disabled
x86, mtrr: Fix sorting of mtrr after subtracting
x86: Move find_smp_config() earlier and avoid bootmem usage
x86, platform: Change is_untracked_pat_range() to bool; cleanup init
x86: Change is_ISA_range() into an inline function
x86, mm: is_untracked_pat_range() takes a normal semiclosed range
x86, mm: Call is_untracked_pat_range() rather than is_ISA_range()
x86: UV SGI: Don't track GRU space in PAT
x86: SGI UV: Fix BAU initialization
x86, numa: Use near(er) online node instead of roundrobin for NUMA
x86, numa, bootmem: Only free bootmem on NUMA failure path
x86: Change crash kernel to reserve via reserve_early()
x86: Eliminate redundant/contradicting cache line size config options
x86: When cleaning MTRRs, do not fold WP into UC
x86: remove "extern" from function prototypes in <asm/proto.h>
x86, mm: Report state of NX protections during boot
x86, mm: Clean up and simplify NX enablement
x86, pageattr: Make set_memory_(x|nx) aware of NX support
x86, sleep: Always save the value of EFER
...
Fix up conflicts (added both iommu_shutdown and is_untracked_pat_range)
to 'struct x86_platform_ops') in
arch/x86/include/asm/x86_init.h
arch/x86/kernel/x86_init.c
fix some typos and punctuation in comments
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
acpi_osi=Linux helps the mute button work properly by sending Linux
a mute key press.
http://bugzilla.kernel.org/show_bug.cgi?id=13934
Signed-off-by: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Len Brown <len.brown@intel.com>
_BIF was returning buffer instead of a string since day 1 of ACPI.
Adding a warning for that is noble, but people don't like
when someone cries wolf in a production system.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14379
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This change will execute module-level code that is not at the
root of the namespace (under a Device object, etc.).
ACPICA BZ 762.
http://www.acpica.org/bugzilla/show_bug.cgi?id=762
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>
Simplifies creation of simple integer objects.
ACPICA BZ 823.
http://www.acpica.org/bugzilla/show_bug.cgi?id=823
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_ut_create_integer_object. This function (when deployed) should
simplify some of the object creation code. ACPICA BZ 823.
http://www.acpica.org/bugzilla/show_bug.cgi?id=823
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This change will repair (by sorting) packages returned by _ALR,
_PSS, and _TSS. Drivers can now assume that the packages are
correctly sorted. Adds one new file, nsrepair2.c.
ACPICA BZ 784.
http://www.acpica.org/bugzilla/show_bug.cgi?id=784
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
This message happens when the package element list is longer than
the declared length of the package. Changed to an info message
because this condition is not actually an error. It is caused by
the BIOS attempting to truncate the package on the fly by adjusting
the package element count at the start of the package definition.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Since the object was successfully repaired, a Warning is too
severe. Reduced to Info for now. We may eventually change these
messages to debug-only. ACPICA BZ 812.
http://www.acpica.org/bugzilla/show_bug.cgi?id=812
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Using Scope(\) to change the scope to the root could cause a
single object memory leak.
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>
If a custom address space handler is installed by the host
before the "initialize operation regions" phase of the ACPICA
initialization, any _REG methods for that address space could
be executed twice. This change fixes the problem.
ACPICA BZ 427.
http://www.acpica.org/bugzilla/show_bug.cgi?id=427
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>
_MAT can inadvertently return an Integer instead of a Buffer
if the return value has been read from a Field whose width is
less than or equal to the global integer width (32 or 64 bits).
ACPICA BZ 810.
http://www.acpica.org/bugzilla/show_bug.cgi?id=810
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>
Add a repair for the "Oem Information" field which is often
mistakenly returned as an integer. It should always be a string.
ACPICA BZ 807.
http://www.acpica.org/bugzilla/show_bug.cgi?id=807
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This interface is mainly intended (and implemented) for ACPI _PPC BIOS
frequency limitations, but other cpufreq drivers can also use it for
similar use-cases.
Why is this needed:
Currently it's not obvious why cpufreq got limited.
People see cpufreq/scaling_max_freq reduced, but this could have
happened by:
- any userspace prog writing to scaling_max_freq
- thermal limitations
- hardware (_PPC in ACPI case) limitiations
Therefore export bios_limit (in kHz) to:
- Point the user that it's the BIOS (broken or intended) which limits
frequency
- Export it as a sysfs interface for userspace progs.
While this was a rarely used feature on laptops, there will appear
more and more server implemenations providing "Green IT" features like
allowing the service processor to limit the frequency. People want
to know about HW/BIOS frequency limitations.
All ACPI P-state driven cpufreq drivers are covered with this patch:
- powernow-k8
- powernow-k7
- acpi-cpufreq
Tested with a patched DSDT which limits the first two cores (_PPC returns 1)
via _PPC, exposed by bios_limit:
# echo 2200000 >cpu2/cpufreq/scaling_max_freq
# cat cpu*/cpufreq/scaling_max_freq
2600000
2600000
2200000
2200000
# #scaling_max_freq shows general user/thermal/BIOS limitations
# cat cpu*/cpufreq/bios_limit
2600000
2600000
2800000
2800000
# #bios_limit only shows the HW/BIOS limitation
CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: davej@codemonkey.org.uk
CC: linux@dominikbrodowski.net
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
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>
Fixes the missing battery on sleep problem for yet another HP laptop
("HP Pavilion dv4").
Fixes:
http://bugzilla.kernel.org/show_bug.cgi?id=13449
Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Users can force a passive trip point for a thermal zone that does not
have _PSV defined in ACPI by setting the passive attribute in sysfs.
It's useful to display such trip points in /proc/acpi/thermal_zone.
.../TZ1/cooling_mode:<setting not supported>
.../TZ1/polling_frequency:polling frequency: 10 seconds
.../TZ1/state:state: ok
.../TZ1/temperature:temperature: 53 C
.../TZ1/trip_points:critical (S5): 110 C
.../TZ1/trip_points:passive (forced): 95 C
And if not set (passive is 0):
.../TZ1/trip_points:passive (forced):<not set>
Signed-off-by: Frans Pop <elendil@planet.nl>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
If the NULL test on pr is needed, then the dereference should be after the
NULL test.
A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):
// <smpl>
@match exists@
expression x, E;
identifier fld;
@@
* x->fld
... when != \(x = E\|&x\)
* x == NULL
// </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>
Ensure that memory mappings created for operation regions
do not cross page boundaries. Crossing a page boundary
while mapping regions can cause warnings if the pages have different attributes.
Such regions are probably BIOS bugs, and this is the workaround.
http://bugzilla.kernel.org/show_bug.cgi?id=14445
[Kernel summit hacking hour]
Signed-off-by: Bob Moore <robert.moore@intel.com>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
If the ACPI methods return an error code, we must return -EINVAL to userspace
to flag the error. Right now we pass the (positive) number right through,
which causes echo to keep writing bogus values.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Feedback from Hidetoshi Seto and Kenji Kaneshige incorporated. This
correctly handles PCI-X bridges, PCIe root ports and endpoints, and
prints debug messages when invalid/reserved types are found in the
HEST. PCI devices not in domain/segment 0 are not represented in
HEST, thus will be ignored.
Today, the PCIe Advanced Error Reporting (AER) driver attaches itself
to every PCIe root port for which BIOS reports it should, via ACPI
_OSC.
However, _OSC alone is insufficient for newer BIOSes. Part of ACPI
4.0 is the new APEI (ACPI Platform Error Interfaces) which is a way
for OS and BIOS to handshake over which errors for which components
each will handle. One table in ACPI 4.0 is the Hardware Error Source
Table (HEST), where BIOS can define that errors for certain PCIe
devices (or all devices), should be handled by BIOS ("Firmware First
mode"), rather than be handled by the OS.
Dell PowerEdge 11G server BIOS defines Firmware First mode in HEST, so
that it may manage such errors, log them to the System Event Log, and
possibly take other actions. The aer driver should honor this, and
not attach itself to devices noted as such.
Furthermore, Kenji Kaneshige reminded us to disallow changing the AER
registers when respecting Firmware First mode. Platform firmware is
expected to manage these, and if changes to them are allowed, it could
break that firmware's behavior.
The HEST parsing code may be replaced in the future by a more
feature-rich implementation. This patch provides the minimum needed
to prevent breakage until that implementation is available.
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
As suggested by Dmitry Torokhov, convert the individual sysfs
attributes into an attribute group.
This change eliminates quite a bit of copy/paste code in the
error handling paths.
Signed-off-by: Alex Chiang <achiang@hp.com>
Reviewed-by: Dmitry Torokhov <dtor@mail.ru>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
proc.c and video.c are a bit sloppy around types and style,
confusing gcc for a new feature that'll be in 2.6.33 and will
cause a warning on the current code.
This patch changes
if (foo + 1 > sizeof bar)
into
if (foo >= sizeof(bar))
which is more kernel-style.
it also changes a variable in proc.c to unsigned; it gets assigned
a value from an unsigned type, and is then only compared for > not
for negative, so using unsigned is just outright the right type
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
If a call comes in to check the lid state but there's no lid device
present, we should return -ENODEV.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Len Brown <len.brown@intel.com>
BugLink: http://bugs.launchpad.net/bugs/333386
Currently a video bus device must (beside other criteria) define _DOD and
_DOS methods to be considered a video device.
Some broken BIOSes prevented working backlight control by only defining both
for one (non-existing bus) and only _DOD for the rest. With this patch in
place the other bus definitions were considered too and backlight control
started to work again.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_get_pci_dev() may be called for a non-PCI device, in which case
it should return NULL. However, it assumes that every handle it
finds in the ACPI CA name space, between given device handle and the
PCI root bridge handle, corresponds to a PCI-to-PCI bridge with an
existing secondary bus. For this reason, when it finds a struct
pci_dev object corresponding to one of them, it doesn't check if
its 'subordinate' field is a valid pointer. This obviously leads to
a NULL pointer dereference if acpi_get_pci_dev() is called for a
non-PCI device with a PCI parent which is not a bridge.
To fix this issue make acpi_get_pci_dev() check if pdev->subordinate
is not NULL for every device it finds on the path between the root
bridge and the device it's supposed to get to and return NULL if the
"target" device cannot be found.
http://bugzilla.kernel.org/show_bug.cgi?id=14129
(worked in 2.6.30, regression in 2.6.31)
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Danny Feng <dfeng@redhat.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Tested-by: chepioq <chepioq@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This is the counterpart to "x86: export k8 physical topology" for
SRAT. It is not as invasive because the acpi code already seperates
node setup into detection and registration steps, with the
exception of registering e820 active regions in
acpi_numa_memory_affinity_init(). This is now moved to
acpi_scan_nodes() if NUMA emulation is disabled or deferred.
acpi_numa_init() now returns a value which specifies whether an
underlying SRAT was located. If so, that topology can be used by
the emulation code to interleave emulated nodes over physical nodes
or to register the nodes for ACPI.
acpi_get_nodes() may now be used to export the srat physical
topology of the machine for NUMA emulation.
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Ankita Garg <ankita@in.ibm.com>
Cc: Len Brown <len.brown@intel.com>
LKML-Reference: <alpine.DEB.1.00.0909251518580.14754@chino.kir.corp.google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Fix two typos in the Kconfig text about ACPI_PROCESSOR_AGGREGATOR.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add an ACPI event notifier for AC/DC connect/disconnect events.
Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'acpi-pad' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
acpi_pad: build only on X86
ACPI: create Processor Aggregator Device driver
Fixup trivial conflicts in MAINTAINERS file.
Compal DSDT breaks if scanned early, while we need early scan
for almost all ASUS machines. Safest workaround seems to be to
continue do an early scan for all machines, but this Compal model.
http://bugzilla.kernel.org/show_bug.cgi?id=14086
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Use dmi_check_system() for DMI matching.
Don't use string "Notebook" for matching MSI hardware.
http://bugzilla.kernel.org/show_bug.cgi?id=14081
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Crossword clues as haikus:
Snakes from the same brood
fighting Jackson on a plane?
sibilant siblings
I guess Will Shortz's job is still secure.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
The ACPI /proc write() code takes an unsigned length argument like any write()
function, but then assigned it to a *signed* integer called "len".
Only after this is a sanity check for len done to make it not larger than 4.
Due to the type change a len < 0 is in principle also possible; this patch
adds a check for this.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Free an acpi_get_object_info() buffer when we're finished. Skip the
acpi_get_name() altogether -- it was only used for a printk that was
really just for debug anyway.
http://bugzilla.kernel.org/show_bug.cgi?id=14271
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
EC may forget a command without sending any "reset" interrupt,
thus we need to lessen the requirement for transaction restart.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14247
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Commit 3d5b6fb47a ("ACPI: Kill overly
verbose "power state" log messages") removed the actual use of this
variable, but didn't remove the variable itself, resulting in build
warnings like
drivers/acpi/processor_idle.c: In function ‘acpi_processor_power_init’:
drivers/acpi/processor_idle.c:1169: warning: unused variable ‘i’
Just get rid of the now unused variable.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I was recently lucky enough to get a 64-CPU system, so my kernel log
ends up with 64 lines like:
ACPI: CPU0 (power states: C1[C1] C2[C3])
This is pretty useless clutter because this info is already available
after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as
well as /proc/acpi/processor/CPU*/power.
So just delete the code that prints the C-states in processor_idle.c.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The message "ACPI: Device needs an ACPI driver" is misleading. The
device _may_ need an ACPI driver, if the BIOS implemented a custom
API for the device in question (which, AFAIK, can't be checked.) If
not, then either a generic ACPI driver may be used (for example
"thermal"), or nothing can be done (other than a white list).
I propose to reword the message to:
ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driver
which I think is more correct. Comments and suggestions welcome.
I also added a message warning about possible problems and system
instability when users pass acpi_enforce_resources=lax, as suggested
by Len.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight:
backlight: new driver for ADP5520/ADP5501 MFD PMICs
backlight: extend event support to also support poll()
backlight/eeepc-laptop: Update the backlight state when we change brightness
backlight/acpi: Update the backlight state when we change brightness
backlight: Allow drivers to update the core, and generate events on changes
backlight: switch to da903x driver to dev_pm_ops
backlight: Add support for the Avionic Design Xanthos backlight device.
backlight: spi driver for LMS283GF05 LCD
backlight: move hp680-bl's probe function to .devinit.text
backlight: Add support for new Apple machines.
backlight: mbp_nvidia_bl: add support for MacBookAir 1,1
backlight: Add WM831x backlight driver
Trivial conflicts due to '#ifdef CONFIG_PM' differences in
drivers/video/backlight/da903x_bl.c
Minor code cleanup, no functional change. Instead of remembering
what HIDs & CIDs to add later, just add them immediately.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Nobody uses acpi_device_uid(), so this patch removes it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Every acpi_device has at least one ID (if there's no _HID or _CID, we
give it a synthetic or default ID). So there's no longer a need to
check whether an ID exists; we can just use it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We now keep a single list of IDs that includes both the _HID and any
_CIDs. We no longer need to keep track of whether the device has a _CID.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There's no need to treat _HID and _CID differently. Keeping them in
a single list makes code that uses the IDs a little simpler because it
can just traverse the list rather than checking "do we have a HID?",
"do we have any CIDs?"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This makes sure every acpi_device has at least one ID. If we build an
acpi_device for a namespace node with no _HID or _CID, we sometimes
synthesize an ID like "LNXCPU" or "LNXVIDEO". If we don't even have
that, give it a default "device" ID.
Note that this means things like:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:04/device:00
(a PCI slot SxFy device) will have "hid" and "modprobe" entries, where
they didn't before. These aren't very useful (a HID of "device" doesn't
tell you what *kind* of device it is, so it doesn't help find a driver),
but I don't think they're harmful.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Use acpi_device_hid() rather than accessing acpi_device.pnp.hardware_id
directly.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This makes \_SB_ show up as /sys/devices/LNXSYSTM:00/LNXSYBUS:00
rather than "device:00". This has been broken for a loooong time
(at least since 2.6.13) because device->parent is an acpi_device
pointer, not a handle.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_bus_scan() traverses the namespace to enumerate devices and uses
acpi_add_single_object() to create acpi_devices. When the platform
notifies us of a hot-plug event, we need to traverse part of the namespace
again to figure out what appeared or disappeared. (We don't yet call
acpi_bus_scan() during hot-plug, but I plan to do that in the future.)
This patch makes acpi_add_single_object() notice when we already have
an acpi_device, so we don't need to make a new one.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds acpi_bus_type_and_status(), which determines the type
of the object and whether we want to build an acpi_device for it. If
it is acpi_device-worthy, it returns the type and the device's current
status.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add acpi_bus_get_status_handle() so we can get the status of a namespace
object before building a struct acpi_device.
This removes a use of "device->flags.dynamic_status", a cached indicator of
whether _STA exists. It seems simpler and more reliable to just evaluate
_STA and catch AE_NOT_FOUND errors.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_bus_scan() currently walks the namespace manually. This patch changes
it to use acpi_walk_namespace() instead.
Besides removing some complicated code, this means we take advantage of the
namespace locking done by acpi_walk_namespace(). The locking isn't so
important at boot-time, but I hope to eventually use this same path to
handle hot-addition of devices, when it will be important.
Note that acpi_walk_namespace() does not actually visit the starting node
first, so we need to do that by hand first.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We can identify the root of the ACPI device tree by the fact that it
has no parent. This is simpler than passing around ACPI_BUS_TYPE_SYSTEM
and will help remove special treatment of the device tree root.
Currently, we add the root by hand with ACPI_BUS_TYPE_SYSTEM. If we
traverse the tree treating the root as just another device and use
acpi_get_type(), the root shows up as ACPI_TYPE_DEVICE.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch changes the order so we enumerate in the "root, namespace,
functional fixed" order instead of the "root, functional fixed, namespace"
order. When I change acpi_bus_scan() to use acpi_walk_namespace(), it
will use the former order, so this patch isolates the order change for
bisectability.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch changes acpi_bus_scan() to take an acpi_handle rather than an
acpi_device pointer. I plan to use acpi_bus_scan() in the hotplug path,
and I'd rather not assume that notifications only go to nodes that already
have acpi_devices.
This will also help remove the special case for adding the root node. We
currently add the root by hand before acpi_bus_scan(), but using a handle
here means we can start the acpi_bus_scan() directly with the root even
though it doesn't have an acpi_device yet.
Note that acpi_bus_scan() currently adds and/or starts the *children* of
its device argument. It doesn't do anything with the device itself.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds acpi_bus_get_parent(), which ascends the namespace until
it finds a parent with an acpi_device.
Then we use acpi_bus_get_parent() in acpi_add_single_object(), so callers
don't have to figure out or keep track of the parent acpi_device.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_add_single_object() is static, and all callers supply a valid "child"
argument, so we don't need to check it. This patch also remove some
unnecessary initializations.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We now save the ACPI bus "device_type" in the acpi_device structure, so
we don't need to pass it around explicitly anymore.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We only pass the "type" to acpi_device_set_context() so we know whether
the device has a handle to which we can attach the acpi_device pointer.
But it's safer to just check for the handle directly, since it's in the
acpi_device already.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Check the acpi_device device_type rather than the HID.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Most uses of the ACPI bus device_type (ACPI_BUS_TYPE_DEVICE,
ACPI_BUS_TYPE_POWER, etc) are during device initialization, but
we do need it later for notify handler installation, since that
is different for fixed hardware devices vs. namespace devices.
This patch saves the device_type in the acpi_device structure,
so we can check that rather than comparing against the _HID string.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
In several cases, functions take handle and parent device pointers in
addition to acpi_device pointers. But the acpi_device structure contains
both the handle and the parent pointer, so it's pointless and error-prone
to pass them all. This patch removes the unnecessary "handle" and "parent"
arguments.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We never use the "root" argument, so just remove it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add debug output for adding an ACPI device. Enable this with
"acpi.debug_layer=0x00010000" (ACPI_BUS_COMPONENT).
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (57 commits)
drm/i915: Handle ERESTARTSYS during page fault
drm/i915: Warn before mmaping a purgeable buffer.
drm/i915: Track purged state.
drm/i915: Remove eviction debug spam
drm/i915: Immediately discard any backing storage for uneeded objects
drm/i915: Do not mis-classify clean objects as purgeable
drm/i915: Whitespace correction for madv
drm/i915: BUG_ON page refleak during unbind
drm/i915: Search harder for a reusable object
drm/i915: Clean up evict from list.
drm/i915: Add tracepoints
drm/i915: framebuffer compression for GM45+
drm/i915: split display functions by chip type
drm/i915: Skip the sanity checks if the current relocation is valid
drm/i915: Check that the relocation points to within the target
drm/i915: correct FBC update when pipe base update occurs
drm/i915: blacklist Acer AspireOne lid status
ACPI: make ACPI button funcs no-ops if not built in
drm/i915: prevent FIFO calculation overflows on 32 bits with high dotclocks
drm/i915: intel_display.c handle latency variable efficiently
...
Fix up trivial conflicts in drivers/gpu/drm/i915/{i915_dma.c|i915_drv.h}
set_cpus_allowed() is on the way out; replace it with
set_cpus_allowed_ptr().
Reference: http://lkml.org/lkml/2008/11/6/448
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Remove open-coded zalloc_cpumask_var() and zalloc_cpumask_var_node().
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (119 commits)
ACPI: don't pass handle for fixed hardware notifications
ACPI: remove null pointer checks in deferred execution path
ACPI: simplify deferred execution path
acerhdf: additional BIOS versions
acerhdf: convert to dev_pm_ops
acerhdf: fix fan control for AOA150 model
thermal: add missing Kconfig dependency
acpi: switch /proc/acpi/{debug_layer,debug_level} to seq_file
hp-wmi: fix rfkill memory leak on unload
ACPI: remove unnecessary #ifdef CONFIG_DMI
ACPI: linux/acpi.h should not include linux/dmi.h
hwmon driver for ACPI 4.0 power meters
topstar-laptop: add new driver for hotkeys support on Topstar N01
thinkpad_acpi: fix rfkill memory leak on unload
thinkpad-acpi: report brightness events when required
thinkpad-acpi: don't poll by default any of the reserved hotkeys
thinkpad-acpi: Fix procfs hotkey reset command
thinkpad-acpi: deprecate hotkey_bios_mask
thinkpad-acpi: hotkey poll fixes
thinkpad-acpi: be more strict when detecting a ThinkPad
...
Trigger a status update when we change the brightness in the driver, thus
allowing userspace to present appropriate UI.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Vegard Nossum <vegardno@ifi.uio.no>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Alok N Kataria <akataria@vmware.com>
Cc: "Tan Wei Chong" <wei.chong.tan@intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Lin Ming <ming.m.lin@intel.com>
Cc: Bob Moore <robert.moore@intel.com>
LKML-Reference: <1253137123-18047-2-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Fixed hardware devices have no handles, so just pass an explicit
NULL rather than something that looks like it might be meaningful.
acpi_device_notify() doesn't need the handle anyway; the only
reason it takes it as an argument is because the acpi_notify_handler
typedef requires it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Better to oops and learn about a bug than to silently cover it up.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We had two functions, acpi_os_execute_deferred() and
acpi_os_execute_hp_deferred() that differed only in that the
latter did acpi_os_wait_events_complete(NULL) before executing
the deferred function.
This patch consolidates those two functions and uses a flag in
the struct acpi_os_dpc to determine whether to do the wait.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
This driver exposes ACPI 4.0 compliant power meters as hardware monitoring
devices. This second revision of the driver also exports the ACPI string
info as sysfs attributes, a list of the devices that the meter measures,
and will send ACPI notifications over the ACPI netlink socket. This
latest revision only enables the power capping controls if it can be
confirmed that the power cap can be enforced by the hardware and explains
how the notification interfaces work.
[akpm@linux-foundation.org: remove default-y]
[akpm@linux-foundation.org: build fix]
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (75 commits)
PCI hotplug: clean up acpi_run_hpp()
PCI hotplug: acpiphp: use generic pci_configure_slot()
PCI hotplug: shpchp: use generic pci_configure_slot()
PCI hotplug: pciehp: use generic pci_configure_slot()
PCI hotplug: add pci_configure_slot()
PCI hotplug: clean up acpi_get_hp_params_from_firmware() interface
PCI hotplug: acpiphp: don't cache hotplug_params in acpiphp_bridge
PCI hotplug: acpiphp: remove superfluous _HPP/_HPX evaluation
PCI: Clear saved_state after the state has been restored
PCI PM: Return error codes from pci_pm_resume()
PCI: use dev_printk in quirk messages
PCI / PCIe portdrv: Fix pcie_portdrv_slot_reset()
PCI Hotplug: convert acpi_pci_detect_ejectable() to take an acpi_handle
PCI Hotplug: acpiphp: find bridges the easy way
PCI: pcie portdrv: remove unused variable
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
ACPI PM: Replace wakeup.prepared with reference counter
PCI PM: Introduce device flag wakeup_prepared
PCI / ACPI PM: Rework some debug messages
PCI PM: Simplify PCI wake-up code
...
Fixed up conflict in arch/powerpc/kernel/pci_64.c due to OF device tree
scanning having been moved and merged for the 32- and 64-bit cases. The
'needs_freset' initialization added in 6e19314cc ("PCI/powerpc: support
PCIe fundamental reset") is now in arch/powerpc/kernel/pci_of_scan.c.
* 'x86-txt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86, intel_txt: clean up the impact on generic code, unbreak non-x86
x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE
x86, intel_txt: Fix typos in Kconfig help
x86, intel_txt: Factor out the code for S3 setup
x86, intel_txt: tboot.c needs <asm/fixmap.h>
intel_txt: Force IOMMU on for Intel TXT launch
x86, intel_txt: Intel TXT Sx shutdown support
x86, intel_txt: Intel TXT reboot/halt shutdown support
x86, intel_txt: Intel TXT boot support
Some drivers need to know when a lid event occurs and get the current
status. This can be useful for when a platform firmware clobbers some
hardware state at lid time, and a driver needs to restore things when
the lid is opened again.
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Some PCI devices (not PCI Express), like PCI add-on cards, can
generate PME#, but they don't have any special platform wake-up
support. For this reason, even if they generate PME# to wake up the
system from a sleep state, wake-up events are not generated by the
platform.
It turns out that, at least on some systems, PCI bridges and the PCI
host bridge have ACPI GPEs associated with them that, if enabled to
generate wake-up events, allow the system to wake up if one of the
add-on devices asserts PME# while the system is in a sleep state.
Following this observation, if a PCI device without direct ACPI
wake-up support is prepared to wake up the system during a transition
into a sleep state (eg. suspend to RAM), try to configure the bridges
on the path from the device to the root bridge to wake-up the system.
Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The wakeup.prepared flag is used for marking devices that have the
wake-up power already enabled, so that the wake-up power is not
enabled twice in a row for the same device. This assumes, however,
that device wake-up power will only be enabled once, while the device
is being prepared for a system-wide sleep transition, and the second
attempt is made by acpi_enable_wakeup_device_prep().
With the upcoming PCI wake-up rework this assumption will not hold
any more for PCI bridges and the root bridge whose wake-up power
may be enabled as a result of wake-up enable propagation from other
devices (eg. add-on devices that are not associated with any GPEs).
Thus, there may be many attempts to enable wake-up power on a PCI
bridge or the root bridge during a system power state transition
and it's better to replace wakeup.prepared with a reference counter.
Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Move a debug message from acpi_pci_sleep_wake() to
acpi_pm_device_sleep_wake() and use the standard dev_*() macros
in there.
Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We can simplify ACPI drivers if we can tell whether a handle is an
ACPI PCI root or not.
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Add support for execution of an _INI method at the namespace root.
Although not defined in the ACPI specification, this support was
added to Windows around the Vista timeframe. It is added here
for Windows compatibility.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Added strings for Windows server 2008, Windows Vista SP1,
Windows 7, and Windows server 2008 R2.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes a possible memory leak in the interpreter for package
objects if the package initializer list is longer than the
defined size of the package. This apparently can only happen
if the BIOS changes the package size on the fly (seen in a _PSS
object), as both iASL and the other compiler do not allow this.
The interpreter will truncate the package to the defined size
(and issue an error message), but can leave the extra objects
undeleted if they have been pre-created during the argument
processing (such is the case if the package consists of a number
of sub-packages as in the _PSS.) ACPICA BZ 805.
http://www.acpica.org/bugzilla/show_bug.cgi?id=805
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We silently ignore this construct for Windows compatibility
ACPICA BZ 785.
http://www.acpica.org/bugzilla/show_bug.cgi?id=785
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
_DSM can return any type of object, so validation on the return
type cannot be performed. ACPICA BZ 802.
http://www.acpica.org/bugzilla/show_bug.cgi?id=802
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There are cases where full date information is required instead of
just the year. Add month and day parsing to dmi_get_year() and rename
it to dmi_get_date().
As the original function only required '/' followed by any number of
parseable characters at the end of the string, keep that behavior to
avoid upsetting existing users.
The new function takes dates of format [mm[/dd]]/yy[yy]. Year, month
and date are checked to be in the ranges of [1-9999], [1-12] and
[1-31] respectively and any invalid or out-of-range component is
returned as zero.
The dummy implementation is updated accordingly but the return value
is updated to indicate field not found which is consistent with how
other dummy functions behave.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Conflicts:
arch/x86/kernel/reboot.c
security/Kconfig
Merge reason: resolve the conflicts, bump up from rc3 to rc8.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move tboot.h from asm to linux to fix the build errors of intel_txt
patch on non-X86 platforms. Remove the tboot code from generic code
init/main.c and kernel/cpu.c.
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
acpi_device->pnp.hardware_id and unique_id are now allocated pointers,
replacing the previous arrays. acpi_device_install_notify_handler()
oopsed on the NULL hid when probing the video device, and perhaps other
uses are vulnerable too. So initialize those pointers to empty strings
when there is no hid or uid. Also, free hardware_id and unique_id when
when acpi_device is going to be freed.
http://bugzilla.kernel.org/show_bug.cgi?id=14096
Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Similar to commit b6adc195 (PCI hotplug: acpiphp wants a 64-bit
_SUN), pci_slot.ko reads and creates sysfs directories based on
the _SUN method.
Certain HP platforms return 64 bits in _SUN. This change to
pci_slot.ko allows us to see the correct sysfs directories.
Reported-by: Chad Smith <chad.smith@hp.com>
Cc: stable@kernel.org
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
_BQC on some laptops returns an uninitialized value when it's
invoked for the first time.
Set the laptop to the maximum backlight level in this case.
http://bugzilla.kernel.org/attachment.cgi?id=22675
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cdev name is normally used for ether class devices or character
devices so rename member to avoid confusion for casual reader
of the code.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
thermal_cooling_device_register() returns error encoded in a pointer
when it fails in which case we need to explictly set device->cdev
to NULL so we don't try to unregister it when unloading.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
In general, EC transaction should complete in less than 1ms, thus it is possible to merge wait for
1ms in poll mode and 1ms of interrupt transaction timeout.
Still, driver will wait 500ms for EC to complete transaction.
This significantly simplifies driver and makes it immune to problematic EC interrupt
implementations.
It also may lessen kernel start-up time by 500ms.
References: http://bugzilla.kernel.org/show_bug.cgi?id=12949
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Acer Aspire 8930G laptops (and possibly others) report the battery current
as a 16-bit signed negative when it is charging. It also reports it as
0x10000 when the current is 0. This patch adds a quirk for this which
takes the absolute value of the reported current cast to an s16. This is
a DSDT bug present in the latest BIOS revision (the EC register is 16 bits
signed and the DSDT attempts to take the 16-bit two's complement of this,
which works for discharge but not charge. It also breaks zero values
because a 32-bit register is used and the high bits aren't thrown away).
I've enabled this for all Acer systems which report in mA units. This
should be safe since it won't break compliant systems unless they report a
current above 32A, which is insane. The patch also detects the valid
32-bit value -1, which indicates unknown status, and does not attempt the
fix in that case (note that this does not conflict with 16-bit -1, which
is 65535 as read normally and gets translated to 1mA).
Signed-off-by: Hector Martin <hector@marcansoft.com>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
_BQC doesn't return a value listed in _BCL method.
http://bugzilla.kernel.org/show_bug.cgi?id=13511
ingore the buggy _BQC method in this case
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Scott Howard <showard314@gmail.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Allow consumers of the acpi_table_parse()/acpi_table_parse_entries() API
to gracefully handle the acpi_disabled=1 case via return value
rather than checking the global flag themselves.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
Allow writes to reserved ports. This change may eventually be
driven down in to acpi_write and acpi_read.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add limited support for executable AML code that exists outside
of any control method. This type of code has been illegal since
ACPI 2.0. The code must exist in an If/Else/While block. All AML
tables are supported, including tables that are dynamically loaded.
ACPICA BZ 762.
http://acpica.org/bugzilla/show_bug.cgi?id=762
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>
Added 31 new names for ACPI 4.0.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes a problem with the mechanism that prevents problems if the
acpi_terminate interface is inadvertently called more than once
before the ACPICA code is re-initialized. ACPICA BZ 795.
http://acpica.org/bugzilla/show_bug.cgi?id=795
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Added one new package type, a package that contains a revision number and
a variable number of sub-packages. Restructured the module to
put the sub-package list traversal in a separate function.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes a problem where a predefined method is defined to return
a variable-length Package of sub-packages. If the length is one,
the BIOS code occasionally creates a simple single package with
no sub-packages. This code attempts to fix the problem by wrapping
a new package object around the existing package. ACPICA BZ 790.
http://acpica.org/bugzilla/show_bug.cgi?id=790
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
New file is nsrepair.c. This is in preparation for additional
errror correcting code.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_video_put_one_device was attempting to remove sysfs entries and
unregister a backlight device without first checking that said backlight
device structure had been created.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix a compatibility issue when the same buffer or string is
stored to itself. This has been seen in the field. Previously,
ACPICA would zero out the buffer/string. Now, the operation is
treated as a NOP.
http://bugzilla.acpica.org/show_bug.cgi?id=803
Reported-by: Rezwanul Kabir <Rezwanul_Kabir@Dell.com>
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>
device->cap and video->cap are zeroed initially so we don't need to clear
them again.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
http://bugzilla.kernel.org/show_bug.cgi?id=13620
If the dynamic region is created and added to resource list over and over again,
it has the potential to be a memory leak by growing the list every time.
This patch fixes the memory leak, as below
1) add a new field "count" to struct acpi_res_list.
When inserting, if the region(addr, len) is already in the resource
list, we just increase "count", otherwise, the region is inserted
with count=1.
When deleting, the "count" is decreased, if it's decreased to 0,
the region is deleted from the resource list.
With "count", the region with same address and length can only be
inserted to the resource list once, so prevent potential memory leak.
2) add a new function acpi_os_invalidate_address, which is called when
region is deleted.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Added parens around the acpica version/modulename/linenumber to
clearly differentiate this group from the rest of the message.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This fixes a problem where the code that attempts to repair/convert
an object of incorrect type is only executed on the first time the
predefined method is called. The mechanism that disables warnings
on subsequent calls was interfering with the repair mechanism.
ACPICA BZ 781.
http://acpica.org/bugzilla/show_bug.cgi?id=781
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Function acpi_tb_print_table_header. Some ACPI tables contain
non-printable characters in one of the string fields of the the
header - Signature, OemId, OemTableId, or CompilerId. Invalid
characters are replaced by '?'. ACPICA BZ 788.
http://acpica.org/bugzilla/show_bug.cgi?id=788
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Handler was never invoked. Now invoked if/when host node is deleted.
Data object was not automatically deleted when host node was deleted.
Interface to handler had an unused parameter, removed it.
ACPICA BZ 778.
http://acpica.org/bugzilla/show_bug.cgi?id=778
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Adds support for IPMI which is similar to SMBus and uses a bi-directional data buffer.
ACPICA BZ 773.
http://acpica.org/bugzilla/show_bug.cgi?id=773
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>
Fixed a possible leak when an attempt is made to repair a return
object. The only current repair is an automatic buffer to string
conversion.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Completed a major update for the acpi_get_object_info external interface.
Changes include:
- Support for variable, unlimited length HID, UID, and CID strings
- Support Processor objects the same as Devices (HID,UID,CID,ADR,STA, etc.)
- Call the _SxW power methods on behalf of a device object
- Determine if a device is a PCI root bridge
- Change the ACPI_BUFFER parameter to ACPI_DEVICE_INFO.
These changes will require an update to all callers of this interface.
See the ACPICA Programmer Reference for details.
Also, update all invocations of acpi_get_object_info interface
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Two duplicates in acdebug.h.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Needed by drivers for new ACPi tables. Internal versions of
these functions still use 32-bit max transfers, in order to
minimize disruption and stack use for the standard ACPI registers
(FADT-based).
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Some were defined twice, causes a warning with gcc
-Wredundant-decls.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes warnings with gcc -Wcast-qual flag.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This failure is very common on many platforms. Handling it in the ACPI
processor driver is enough, and we don't need a warning message unless
CONFIG_ACPI_DEBUG is set.
Based on a patch from Zhang Rui.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389
Signed-off-by: Frans Pop <elendil@planet.nl>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the BIOS reports an invalid throttling state (which seems to be
fairly common after system boot), a reset is done to state T0.
Because of a check in acpi_processor_get_throttling_ptc(), the reset
never actually gets executed, which results in the error reoccurring
on every access of for example /proc/acpi/processor/CPU0/throttling.
Add a 'force' option to acpi_processor_set_throttling() to ensure
the reset really takes effect.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389
This patch, together with the next one, fixes a regression introduced in
2.6.30, listed on the regression list. They have been available for 2.5
months now in bugzilla, but have not been picked up, despite various
reminders and without any reason given.
Google shows that numerous people are hitting this issue. The issue is in
itself relatively minor, but the bug in the code is clear.
The patches have been in all my kernels and today testing has shown that
throttling works correctly with the patches applied when the system
overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).
Signed-off-by: Frans Pop <elendil@planet.nl>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently clockevents_notify() is called with interrupts enabled at
some places and interrupts disabled at some other places.
This results in a deadlock in this scenario.
cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
cpu C doing set_mtrr() which will try to rendezvous of all the cpus.
This will result in C and A come to the rendezvous point and waiting
for B. B is stuck forever waiting for the spinlock and thus not
reaching the rendezvous point.
Fix the clockevents code so that clockevents_lock is taken with
interrupts disabled and thus avoid the above deadlock.
Also call lapic_timer_propagate_broadcast() on the destination cpu so
that we avoid calling smp_call_function() in the clockevents notifier
chain.
This issue left us wondering if we need to change the MTRR rendezvous
logic to use stop machine logic (instead of smp_call_function) or add
a check in spinlock debug code to see if there are other spinlocks
which gets taken under both interrupts enabled/disabled conditions.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: "Brown Len" <len.brown@intel.com>
LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
If the memory block size is zero, ignore it and don't do the memory hotplug
flowchart. Otherwise it will complain the following warning message:
>System RAM resource 0 - ffffffffffffffff cannot be added
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Don't treat the generic error as ACPI error code. Otherwise when the generic
code is returned, it will complain the following warning messag:
>ACPI Exception (acpi_memhotplug-0171): UNKNOWN_STATUS_CODE,
Cannot get acpi bus device [20080609]
>ACPI: Cannot find driver data
> ACPI Error (utglobal-0127): Unknown exception code: 0xFFFFFFED [20080609]
> Pid: 85, comm: kacpi_notify Not tainted 2.6.27.19-5-default #1
Call Trace:
[<ffffffff8020da29>] show_trace_log_lvl+0x41/0x58
[<ffffffff8049a3da>] dump_stack+0x69/0x6f
.....
At the same time when the generic error code is returned, the ACPI_EXCEPTION
is replaced by the printk.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
On some machines, a software-initiated SMI causes corruption unless the
SMI runs on CPU 0. An SMI can be initiated by any AML, but typically it's
done in GPE-related methods that are run via workqueues, so we can avoid
the known corruption cases by binding the workqueues to CPU 0.
References:
http://bugzilla.kernel.org/show_bug.cgi?id=13751https://bugs.launchpad.net/bugs/157171https://bugs.launchpad.net/bugs/157691
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI 4.0 created the logical "processor aggregator device" as
a mechinism for platforms to ask the OS to force otherwise busy
processors to enter (power saving) idle.
The intent is to lower power consumption to ride-out
transient electrical and thermal emergencies,
rather than powering off the server.
On platforms that can save more power/performance via P-states,
the platform will first exhaust P-states before forcing idle.
However, the relative benefit of P-states vs. idle states
is platform dependent, and thus this driver need not know
or care about it.
This driver does not use the kernel's CPU hot-plug mechanism
because after the transient emergency is over, the system must
be returned to its normal state, and hotplug would permanently
break both cpusets and binding.
So to force idle, the driver creates a power saving thread.
The scheduler will migrate the thread to the preferred CPU.
The thread has max priority and has SCHED_RR policy,
so it can occupy one CPU. To save power, the thread will
invoke the deep C-state entry instructions.
To avoid starvation, the thread will sleep 5% of the time
time for every second (current RT scheduler has threshold
to avoid starvation, but if other CPUs are idle,
the CPU can borrow CPU timer from other,
which makes the mechanism not work here)
Vaidyanathan Srinivasan has proposed scheduler enhancements
to allow injecting idle time into the system. This driver doesn't
depend on those enhancements, but could cut over to them
when they are available.
Peter Z. does not favor upstreaming this driver until
the those scheduler enhancements are in place. However,
we favor upstreaming this driver now because it is useful
now, and can be enhanced over time.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This fixes regression (battery "vanishing" on resume) introduced by
commit d0c71fe7eb ("ACPI Suspend: Enable
ACPI during resume if SCI_EN is not set") and also the issue with
the "screaming" IRQ 9.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13745
Reported-and-tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: stable@kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Len Brown <lenb@kernel.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Support for graceful handling of sleep states (S3/S4/S5) after an Intel(R) TXT launch.
Without this patch, attempting to place the system in one of the ACPI sleep
states (S3/S4/S5) will cause the TXT hardware to treat this as an attack and
will cause a system reset, with memory locked. Not only may the subsequent
memory scrub take some time, but the platform will be unable to enter the
requested power state.
This patch calls back into the tboot so that it may properly and securely clean
up system state and clear the secrets-in-memory flag, after which it will place
the system into the requested sleep state using ACPI information passed by the kernel.
arch/x86/kernel/smpboot.c | 2 ++
drivers/acpi/acpica/hwsleep.c | 3 +++
kernel/cpu.c | 7 ++++++-
3 files changed, 11 insertions(+), 1 deletion(-)
Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
ref: http://thread.gmane.org/gmane.linux.kernel/857228/focus=857468
When the ACPI video driver initializes, it does a namespace walk
looking for for supported devices. When we find an appropriate
handle, we walk up the ACPI tree looking for a PCI root bus, and
then walk back down the PCI bus, assuming that every device
inbetween is a P2P bridge.
This assumption is not correct, and is reported broken on at
least:
Dell Latitude E6400
ThinkPad X61
Dell XPS M1330
Add a NULL deref check to prevent boot panics.
Reported-by: Alessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: Troy Moure <twmoure@szypr.net>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
No drivers use the .stop method, so remove it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch folds the .stop() method into .remove().
acpi_ec_stop() is only called via acpi_device_probe() and
acpi_device_remove(), and in both cases it is called immediately before
acpi_ec_remove(), so there's no need to have it be a separate method.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch folds the .start() method into .add().
acpi_ec_start() is always called immediately after acpi_ec_add(),
so there's no need to have it be a separate method.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch rearranges ec_install_handlers() and acpi_ec_start() so
acpi_ec_start() ends up just after acpi_ec_add(). A subsequent patch
will merge them.
Code movement only; no functional change.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch folds the .start() method into .add().
The .start() method is called in two paths: boot-time device enumeration
and run-time node addition, currently via container_device_add(). In both
cases, .start() is called immediately after .add(), so there's no reason
to make them separate methods.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Yasunori Goto <y-goto@jp.fujitsu.com>
CC: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
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>
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>
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>
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>
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>
Now that new interface is available,
convert to using it rather than creating a new kernel thread.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Sometimes both acpi video and i915 driver are compiled as modules.
And there exists the strict dependency between the two drivers.
The acpi video bus will be unloaded in course of unloading the i915 driver.
If we unload the acpi video driver, then the kernel oops will be triggered.
Add the reference count to avoid unloading the ACPI video bus twice.
The reference count should be checked before unregistering the acpi video bus.
If the reference count is already zero, it won't unregister it again.
And after the acpi video bus is already unregistered, the reference count
will be set to zero.
http://bugzilla.kernel.org/show_bug.cgi?id=13396
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Linux claims Vista compatibility to the BIOS for a number of
reasons, but this brings hard lockup on some Sony laptops.
Disable Vista compatibility via DMI for these laptops unless
we can figure out what Vista is doing for this platform.
http://bugzilla.kernel.org/show_bug.cgi?id=12904
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
we used to run the hotplug code in keventd_wq.
But when hot removing the ACPI battery device,
power_supply_unregister invokes flush_scheduled_work.
This causes a deadlock. i.e
1. When dock is unplugged, all the hotplug code is run on kevent_wq.
2. the hotplug code removes all the child devices of dock device.
3. removing the child device may invoke flush_scheduled_work
4. flush_scheduled_work waits until all the work on kevent_wq to be
finished, while this will never be true because the hotplug code
is running on keventd_wq...
Introduce a new workqueue for hotplug in this patch.
http://bugzilla.kernel.org/show_bug.cgi?id=13533
Tested-by: Paul Martin <pm@debian.org>
Tested-by: Vojtech Gondzala <vojtech.gondzala@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Create symbol link from backlight class device to ACPI video device.
More and more laptops are shipped with multiple ACPI
video devices, while we export only one of them to userspace.
With this patch applied, we can know which ACPI video device
is used by "cat /sys/class/backlight/acpi_video0/device/path".
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (74 commits)
PCI: make msi_free_irqs() to use msix_mask_irq() instead of open coded write
PCI: Fix the NIU MSI-X problem in a better way
PCI ASPM: remove get_root_port_link
PCI ASPM: cleanup pcie_aspm_sanity_check
PCI ASPM: remove has_switch field
PCI ASPM: cleanup calc_Lx_latency
PCI ASPM: cleanup pcie_aspm_get_cap_device
PCI ASPM: cleanup clkpm checks
PCI ASPM: cleanup __pcie_aspm_check_state_one
PCI ASPM: cleanup initialization
PCI ASPM: cleanup change input argument of aspm functions
PCI ASPM: cleanup misc in struct pcie_link_state
PCI ASPM: cleanup clkpm state in struct pcie_link_state
PCI ASPM: cleanup latency field in struct pcie_link_state
PCI ASPM: cleanup aspm state field in struct pcie_link_state
PCI ASPM: fix typo in struct pcie_link_state
PCI: drivers/pci/slot.c should depend on CONFIG_SYSFS
PCI: remove redundant __msi_set_enable()
PCI PM: consistently use type bool for wake enable variable
x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded
...
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>
We never use the PCI device & function number, so remove it to make
it clear that it's not needed. Many PCI host bridges don't even
appear in config space, so it's meaningless to look at stuff from
_ADR, which doesn't exist in that case.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Using list_for_each_entry() makes traversing the root list easier.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There's no need to search the list to find the acpi_pci_root
structure. We saved it as device->driver_data when we added
the device.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
By looking up the segment & bus number earlier, we don't have to
worry about cleaning up if it fails.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
To find a host bridge's downstream bus number, we currently look at _BBN
first. If _BBN returns a bus number we've already seen, we conclude that
_BBN was wrong and look for a bus number in _CRS.
However, the spec[1] (figure 5-5 and the example in sec 9.12.1) and an ACPI
FAQ[2] suggest that the OS should use _CRS to discover the bus number
range, and that _BBN is really intended to bootstrap _CRS methods that
reference PCI opregions.
This patch makes us always look at _CRS first. If _CRS doesn't supply a
bus number, we look at _BBN. If _BBN doesn't exist, we default to zero.
This makes the behavior consistent regardless of device discovery order.
Previously, if A and B had duplicate _BBNs and we found A first, we'd only
look at B's _CRS, whereas if we found B first, we'd only look at A's _CRS.
I'm told that Windows discovers host bridge bus numbers using _CRS, so
it should be fairly safe to rely on this BIOS functionality.
This patch also removes two misleading messages: we printed the "Wrong _BBN
value, reboot and use option 'pci=noacpi'" message before looking at _CRS,
so we would likely find the bus number in _CRS, the system would work fine,
and the user would be confused. The "PCI _CRS %d overrides _BBN 0" message
incorrectly assumes _BBN was zero, and it's useless anyway because we
print the segment/bus number a few lines later.
References:
[1] http://www.acpi.info/DOWNLOADS/ACPIspec30b.pdf
[2] http://www.acpi.info/acpi_faq.htm _BBN/_CRS discussion
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05005_WinHEC05.ppt (slide 17)
http://bugzilla.kernel.org/show_bug.cgi?id=1662 ASUS PR-DLS
http://bugzilla.kernel.org/show_bug.cgi?id=1127 ASUS PR-DLSW
http://bugzilla.kernel.org/show_bug.cgi?id=1741 ASUS PR-DLS533
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Shaohua Li <shaohua.li@intel.com>
CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There is no way to interact with a physical PCI slot without
sysfs, so encode the dependency and prevent this build error:
drivers/pci/slot.c: In function 'pci_hp_create_module_link':
drivers/pci/slot.c:327: error: 'module_kset' undeclared
This patch _should_ make pci-sysfs.o depend on CONFIG_SYSFS too,
but we cannot (yet) because the PCI core merrily assumes the
existence of sysfs:
drivers/built-in.o: In function `pci_bus_add_device':
drivers/pci/bus.c:89: undefined reference to `pci_create_sysfs_dev_files'
drivers/built-in.o: In function `pci_stop_dev':
drivers/pci/remove.c:24: undefined reference to `pci_remove_sysfs_dev_files'
So do the minimal bit for now and figure out how to untangle it
later.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fix-suggested-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
cosmetic only. The lapic_timer workaround routines
are specific to the lapic_timer, and are not acpi-generic.
old:
acpi_timer_check_state()
acpi_propagate_timer_broadcast()
acpi_state_timer_broadcast()
new:
lapic_timer_check_state()
lapic_timer_propagate_broadcast()
lapic_timer_state_broadcast()
also, simplify the code in acpi_processor_power_verify()
so that lapic_timer_check_state() is simply called
from one place for all valid C-states, including C1.
Signed-off-by: Len Brown <len.brown@intel.com>
This patch changes the global system notification path so it uses the
acpi_handle, not the acpi_device.
System notifications often deal with device presence and status change.
In these cases, we may not have an acpi_device. For example, we may
get a Device Check notification on an object that previously was not
present. Since the object was not present, we would not have had an
acpi_device for it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Remove return values from acpi_bus_check_device() and acpi_bus_check_scope()
since nobody looks at them.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Remove "status_changed" return from acpi_bus_check_device(). Nobody
does anything useful based on its value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This replaces several messages that depend on the acpi_device struct
with a single message that uses just the acpi_handle. We should be
able to deal with notifications to objects that do not yet have an
acpi_device struct.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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.
This driver apparently relies on seeing ALL notify events, not just
device-specific ones (because it used ACPI_ALL_NOTIFY). We use the
ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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.
This driver apparently relies on seeing ALL notify events, not just
device-specific ones (because it used ACPI_ALL_NOTIFY). We use the
ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
System notify events (0x00-0x7f) are common across all device types
and should be handled in Linux/ACPI, not in drivers. However, some
BIOSes use system notify events in device-specific ways that require
the driver to be involved.
This patch adds a ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag. When a
driver sets this flag and supplies a .notify method, Linux/ACPI calls
the .notify method for ALL notify events on the device, not just the
device-specific (0x80-0xff) events.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_get_pci_dev() is (hopefully) better, and all callers have been
converted, so let's get rid of this duplicated functionality.
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Now that acpi_get_pci_dev is available, let's use it instead of
acpi_get_physical_pci_device()
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_get_pci_dev() is better, and all callers have been converted, so
eliminate acpi_get_pci_id().
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
In acpi_pci_bind, we set device->ops.bind and device->ops.unbind, but
never clear them out.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There is no need to pass a segment/bus tuple to this API, as the callsite
always has a struct pci_bus. We can derive segment/bus from the
struct pci_bus, so let's take this opportunit to simplify the API and
make life easier for the callers.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
A PCI domain cannot change as you descend down subordinate buses, which
makes the 'segment' argument to acpi_pci_irq_add_prt() useless.
Change the interface to take a struct pci_bus *, from whence we can derive
the bus number and segment. Reducing the number of arguments makes life
simpler for callers.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Now that we can dynamically convert an ACPI CA handle to a
struct pci_dev at runtime, there's no need to statically bind
them during boot.
acpi_pci_bind/unbind are vastly simplified, and are only used
to evaluate _PRT methods on P2P bridges and non-bridge children.
This patch also changes the time-space tradeoff ever so slightly.
Looking up the ACPI-PCI binding is never in the performance path, and by
eliminating this caching, we save 24 bytes for each _ADR device in the
ACPI namespace.
This patch lays further groundwork to eventually eliminate
the acpi_driver_ops.bind callback.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This is a pure code movement patch that does $subject in order
to make the following patch easier to read and review.
No functional change.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Convert an ACPI CA handle to a struct pci_dev.
Performing this lookup dynamically allows us to get rid of the
ACPI-PCI binding code, which:
- eliminates struct acpi_device vs struct pci_dev lifetime issues
- lays more groundwork for eliminating .start from acpi_device_ops
and thus simplifying ACPI drivers
- whacks out a lot of code
This change lays the groundwork for eliminating much of pci_bind.c.
Although pci_root.c may not be the most logical place for this
change, putting it here saves us from having to export acpi_pci_find_root.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Returns whether an ACPI CA node is a PCI root bridge or not.
This API is generically useful, and shouldn't just be a hotplug function.
The implementation becomes much simpler as well.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_pci_root_add() explicitly assigns device->ops.bind, and later
calls acpi_pci_bind_root(), which also does the same thing.
We don't need to repeat ourselves; removing the explicit assignment
allows us to make acpi_pci_bind() static.
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Align labels in column 0, adjust spacing in 'if' statements, eliminate
trailing and superfluous whitespaces.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There is no apparent reason for acpi_device_register() to manually
register a new device in two steps (initialize then add).
Just call device_register() directly.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits)
ACPICA: Update version to 20090521.
ACPICA: Disable preservation of SCI enable bit (SCI_EN)
ACPICA: Region deletion: Ensure region object is removed from handler list
ACPICA: Eliminate extra call to NsGetParentNode
ACPICA: Simplify internal operation region interface
ACPICA: Update Load() to use operation region interfaces
ACPICA: New: AcpiInstallMethod - install a single control method
ACPICA: Invalidate DdbHandle after table unload
ACPICA: Fix reference count issues for DdbHandle object
ACPICA: Simplify and optimize NsGetNextNode function
ACPICA: Additional validation of _PRT packages (resource mgr)
ACPICA: Fix DebugObject output for DdbHandle objects
ACPICA: Fix allowable release order for ASL mutex objects
ACPICA: Mutex support: Fix release ordering issue and current sync level
ACPICA: Update version to 20090422.
ACPICA: Linux OSL: cleanup/update/merge
ACPICA: Fix implementation of AML BreakPoint operator (break to debugger)
ACPICA: Fix miscellaneous warnings under gcc 4+
ACPICA: Miscellaneous lint changes
ACPICA: Fix possible dereference of null pointer
...
* 'irq-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (76 commits)
x86, apic: Fix dummy apic read operation together with broken MP handling
x86, apic: Restore irqs on fail paths
x86: Print real IOAPIC version for x86-64
x86: enable_update_mptable should be a macro
sparseirq: Allow early irq_desc allocation
x86, io-apic: Don't mark pin_programmed early
x86, irq: don't call mp_config_acpi_gsi() if update_mptable is not enabled
x86, irq: update_mptable needs pci_routeirq
x86: don't call read_apic_id if !cpu_has_apic
x86, apic: introduce io_apic_irq_attr
x86/pci: add 4 more return parameters to IO_APIC_get_PCI_irq_vector(), fix
x86: read apic ID in the !acpi_lapic case
x86: apic: Fixmap apic address even if apic disabled
x86: display extended apic registers with print_local_APIC and cpu_debug code
x86: read apic ID in the !acpi_lapic case
x86: clean up and fix setup_clear/force_cpu_cap handling
x86: apic: Check rev 3 fadt correctly for physical_apic bit
x86/pci: update pirq_enable_irq() to setup io apic routing
x86/acpi: move setup io apic routing out of CONFIG_ACPI scope
x86/pci: add 4 more return parameters to IO_APIC_get_PCI_irq_vector()
...
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>
Conflicts:
arch/mips/sibyte/bcm1480/irq.c
arch/mips/sibyte/sb1250/irq.c
Merge reason: we gathered a few conflicts plus update to latest upstream fixes.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Commit 4973b22a ("ACPI processor: reset the throttling state once it's
invalid") introduced a new warning which prints a spurious newline.
The ACPI_WARNING macro that is used already takes care of adding a
newline, after adding ACPI_CA_VERSION to the message. Remove the newline
to avoid the message getting split into two lines.
Signed-off-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Len Brown <len.brown@intel.com>
Currently acpi_video_exit() is exported as well as using __exit which causes:
WARNING: drivers/acpi/video.o(__ksymtab+0x0): Section mismatch in reference from the variable __ksymtab_acpi_video_exit to the function .exit.text:acpi_video_exit()
The symbol acpi_video_exit is exported and annotated __exit
Fix this by removing the __exit annotation of acpi_video_exit or drop the export.
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When BIOS SETUP is changed to disable EIST, some BIOS
hand the OS an un-initialized _PSS:
Name (_PSS, Package (0x06)
{
Package (0x06)
{
0x80000000, // frequency [MHz]
0x80000000, // power [mW]
0x80000000, // latency [us]
0x80000000, // BM latency [us]
0x80000000, // control
0x80000000 // status
},
...
These are outrageous values for frequency,
power and latency, raising the question where to draw
the line between legal and illegal. We tend to survive
garbage in the power and latency fields, but we can BUG_ON
when garbage is in the frequency field.
Cpufreq multiplies the frequency by 1000 and stores it in a u32 KHz.
So disregard a _PSS with a frequency so large
that it can't be represented by cpufreq.
https://bugzilla.redhat.com/show_bug.cgi?id=500311
Signed-off-by: Len Brown <len.brown@intel.com>
ARB_DISABLE is a NOP on all of the recent Intel platforms.
For such platforms, reduce contention on c3_lock
by skipping the fake ARB_DISABLE.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We used to evaluate _STA to check the power state of a device after
running _ON or _OFF. But as far as I can tell, there's no benefit
to evaluating _STA, and sometimes we trip over bugs when BIOSes don't
implement _STA correctly.
Yakui says Windows XP doesn't evaluate _STA during power transition.
So let's skip it in Linux, too. It's conceivable that we'll need to
check _STA in the future for some reason, but until we do, I don't
see a reason to clutter this code path.
References:
http://bugzilla.kernel.org/show_bug.cgi?id=13243http://marc.info/?l=linux-acpi&m=124166053803753&w=2http://marc.info/?l=linux-acpi&m=124175761408256&w=2http://marc.info/?l=linux-acpi&m=124210593114061&w=2
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
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>
The 'dev' field of struct acpi_pci_data is having a pointer to struct
pci_dev without incrementing the reference counter. Because of this, I
got the following kernel oops when I was doing some pci hotplug
operations. This patch fixes this bug by replacing wrong hand-made
pci_find_slot() with pci_get_slot() in acpi_pci_bind().
BUG: unable to handle kernel NULL pointer dereference at 00000000000000e8
IP: [<ffffffff803f0e9b>] acpi_pci_unbind+0xb1/0xdd
Call Trace:
[<ffffffff803ecee4>] acpi_bus_remove+0x54/0x68
[<ffffffff803ecf6d>] acpi_bus_trim+0x75/0xe3
[<ffffffffa0345ddd>] acpiphp_disable_slot+0x16d/0x1e0 [acpiphp]
[<ffffffffa03441f0>] disable_slot+0x20/0x60 [acpiphp]
[<ffffffff803cfc18>] power_write_file+0xc8/0x110
[<ffffffff803c6a54>] pci_slot_attr_store+0x24/0x30
[<ffffffff803469ce>] sysfs_write_file+0xce/0x140
[<ffffffff802e94e7>] vfs_write+0xc7/0x170
[<ffffffff802e9aa0>] sys_write+0x50/0x90
[<ffffffff8020bd6b>] system_call_fastpath+0x16/0x1b
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Tested-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Preserving this bit breaks some machines. Not preserving this bit
seems to work OK in all cases, even though this goes against the
ACPI spec.
http://bugzilla.kernel.org/show_bug.cgi?id=13289
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Prevents a possible fault when a dynamic operation region is
deleted. ACPICA BZ 507.
http://acpica.org/bugzilla/show_bug.cgi?id=507
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>
Was called twice in the same function with the same parameter.
Alex Chiang.
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Changed address parameter to a simple offset. This removes the
need for the caller to access the region object to obtain the
physical address.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Replace memory mapping with region access calls. Now, all region
accesses go through the region handler as they should.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This interface enables the override or creation of a single
control method. Useful to repair a bug or install a missing method.
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>
Mark the DdbHandle as invalid after the table it refers to is
unloaded. This is needed because the handle itself may not be
deleted after the table unload, depending on whether it has been
stored in a named object by the caller.
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>
Fix a problem where the DdbHandle could be prematurely deleted,
possibly causing a fault.
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>
Reduced parameter count and reduced code for this frequently
used function.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes a possible fault when parsing an ill-formed _PRT package.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Was putting several extra spaces on the next line.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI 4.0 specification has been changed to make the SyncLevel
for mutex objects more useful. When releasing a mutex, the
synclevel of the mutex must now be the same as the current sync
level. This makes more sense. This change updates the code to
match the spec.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixes a problem where if multiple mutexes of the same sync level
are acquired but then not released in strict opposite order, the
current sync level becomes confused and can cause errors.
ACPICA BZ 471.
http://acpica.org/bugzilla/show_bug.cgi?id=471
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The AML BreakPoint opcode will now cause a break into the AML
debugger if it is present/configured. This matches the expected
behavior per the ACPI specification. Previously, only a message
was output.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Some possible warnings with gcc 4+, especially with extended warnings
enabled
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com
Signed-off-by: Len Brown <len.brown@intel.com>
Unused variables/headers, casting, etc.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix dereference of possibly null pointer "Predefined" in the case
where the method is not one of the predefined methods.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix warnings caused by size_t and ACPI_SIZE changing to 64 bits.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Warnings can be generated for printf-like statements that output
the ACPI_THREAD_ID on 64-bit builds, since this type can expand
to 64-bits depending on how it is defined. Use the %p format
specifier to allow the output to automatically expand to 64 bits.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Remove two unused/obsolete variables.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When copying these internal objects, cannot simply copy the
underlying OS object. A new OS object must be created.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Mostly for acpiexec, one in the core subsystem.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Moved the module name and line number to the end of the message.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When AMD C1E is enabled, local APIC timer will stop even in C1. To avoid
suspend/resume hang, this patch removes C1 and replace it with a cpu_relax() in
suspend/resume path. This hasn't any impact in runtime path.
http://bugzilla.kernel.org/show_bug.cgi?id=13233
[ impact: avoid suspend/resume hang in AMD CPU with C1E enabled ]
Tested-by: Dmitry Lyzhyn <thisistempbox@yahoo.com>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When AMD C1E is enabled, local APIC timer will stop even in C1.
This patch uses broadcast IPI to replace local APIC timer in C1.
http://bugzilla.kernel.org/show_bug.cgi?id=13233
[ impact: avoid boot hang in AMD CPU with C1E enabled ]
Tested-by: Dmitry Lyzhyn <thisistempbox@yahoo.com>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Processor idle power states C2 and C3 stop the TSC on many machines.
Linux recognizes this situation and marks the TSC as unstable:
Marking TSC unstable due to TSC halts in idle
But if those same machines are booted with "processor.max_cstate=1",
then there is no need to validate C2 and C3, and no need to
disable the TSC, which can be reliably used as a clocksource.
Signed-off-by: Len Brown <len.brown@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
A previous 2.6.30 patch, a71e4917dc,
(ACPI: idle: mark_tsc_unstable() at init-time, not run-time)
erroneously disabled the TSC on systems that did not actually
have valid deep C-states.
Move the check after the deep-C-states are validated,
via new helper, tsc_check_state(), hich replaces tsc_halts_in_c().
Signed-off-by: Len Brown <len.brown@intel.com>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Frans Pop <elendil@planet.nl>
If the BIOS hands us an invalid throttling state,
write a valid state.
http://bugzilla.kernel.org/show_bug.cgi?id=13259
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Introduce module parameter processor.ignore_tpc.
Some laptops are shipped with buggy _TPC,
this module parameter is used to to disable the buggy support.
http://bugzilla.kernel.org/show_bug.cgi?id=13259
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
In 2.6.29,
31878dd86b
"ACPI: remove BM_RLD access from idle entry path"
moved BM_RLD initialization to init-time from run time.
But we discovered that some BIOS do not restore BM_RLD
after suspend, causing device errors on C3 and C4
after resume. So now the kernel restores BM_RLD.
http://bugzilla.kernel.org/show_bug.cgi?id=13032
Signed-off-by: Len Brown <len.brown@intel.com>
The BIOS bug workaround mistakenly got disabled
when we followed the ACPI specification more closely
by ignoring OS updates to that bit.
(The BIOS is supposed to update SCI_EN, not the OS)
http://bugzilla.kernel.org/show_bug.cgi?id=13289
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Merge reason: both topics modify the APIC code but were able to do it in
parallel so far. An upcoming patch generates a conflict so
merge them to avoid the conflict.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
"Transitioning device [%s] to D%d" is not correct.
We print this line when we attempted to transition
the device, and it failed.
So instead, print
"Device [%s] failed to transition to D%d\n"
This can happen under two conditions:
1. acpi_power_transition() fails when trying to handle the
_ON/_OFF for associated power resource.
2. acpi_evaluate_object() on the explicit _PS0/_PS3
for that actual device could fail.
this change clarifies, but doesn't fix
http://bugzilla.kernel.org/show_bug.cgi?id=13243
Signed-off-by: Len Brown <len.brown@intel.com>
Add acpi/acpica/*.c to the acpi.* modparam namespace
so that any modparams we stick into ACPICA do not
expose ACPICA filenames to users.
There are currently only two modparams in ACPICA,
just recently added for
http://bugzilla.kernel.org/show_bug.cgi?id=13041
With this change, they become
acpi.gts=1
acpi.bfs=1
rather than
hwsleep.gts=1
hwsleep.bfs=1
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_rs_get_pci_routing_table_length is not performing sufficient
validation on the package returned from _PRT. It assumes a package of
packages and fails/faults if this is not the case.
We should validate each subpackage when extracted from the parent
package, and not accept objects of the wrong type, since that will just
cause the scanning to fail (likely with a kernel oops).
This can only happen with a serious BIOS bug, and is accompanied by a
warning something like this:
ACPI Warning (nspredef-0949): \_SB_.PCI0.PEG4._PRT: Return Package type mismatch at index 0 - found Integer, expected Package [20090320]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
drm/i915: fix up error path leak in i915_cmdbuffer
drm/i915: fix unpaired i915 device mutex on entervt failure.
drm/i915: add support for G41 chipset
drm/i915: Enable ASLE if present
drm/i915: Unregister ACPI video driver when exiting
drm/i915: Register ACPI video even when not modesetting
drm/i915: fix transition to I915_TILING_NONE
drm/i915: Don't let an oops get triggered from irq_emit without dma init.
drm/i915: allow tiled front buffers on 965+
We want to use dev_to_node() later on, to be aware of the 'home node'
of the GSI in question.
[ Impact: cleanup, prepare the IRQ code to be more NUMA aware ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Len Brown <lenb@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Len Brown <lenb@kernel.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-acpi@vger.kernel.org
Cc: linux-ia64@vger.kernel.org
LKML-Reference: <49F65560.20904@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
On Acer Aspire 5720, _BQC always returns a value 9 smaller than
the actual brightness level. Add dmi quirk for this laptop.
http://bugzilla.kernel.org/show_bug.cgi?id=13121
Tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit fdbdc7fc79.
That temporary quick-fix is no longer necessary,
as the previous patch, a65131e942,
"I/O port protection: update for windows compatibility"
should handle this issue for all ports, including this one.
Signed-off-by: Len Brown <len.brown@intel.com>
For windows compatibility,
1) On a port protection violation, simply ignore the request and
do not return an exception (allow the control method to continue execution.)
2) If only part of the request overlaps a protected port,
read/write the individual ports that are not protected.
http://bugzilla.kernel.org/show_bug.cgi?id=13036
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>
When resuming from standby (on a laptop) I see the following message in
my kernel.log:
"ACPI: EC: non-query interrupt received, switching to interrupt mode"
This apparently prevented sony-laptop to properly restore the brightness
level on resume.
The cause: In drivers/acpi/ec.c the acpi_ec_suspend function clears the
GPE mode bit, but this is not restored in acpi_ec_resume (the function
below it). The patch below fixes this by properly restoring the GPE_MODE
bit. Tested and confirmed to work.
Signed-off-by: Almer S. Tigelaar <almer@gnome.org>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
As processor.max_cstate is an init-time-only modparam,
sanity checking it at init-time is sufficient.
http://bugzilla.kernel.org/show_bug.cgi?id=13142
Signed-off-by: Len Brown <len.brown@intel.com>
Linux tells ICH4 users that they can (manually) invoke
"hpet=force" to enable the undocumented ICH-4M HPET.
The HPET becomes available for both clocksource and clockevents.
But as of ff69f2bba6
(acpi: fix of pmtimer overflow that make Cx states time incorrect)
the HPET may be used via clocksource for idle accounting, and
hpet=force on an ICH4 box hangs boot.
It turns out that touching the MMIO HPET withing
the ARB_DIS part of C3 will hang the hardware.
The fix is to simply move the timer access outside
the ARB_DIS region. This is a no-op on modern hardware
because ARB_DIS is no longer used.
http://bugzilla.kernel.org/show_bug.cgi?id=13087
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Linux-2.6.29 deleted the legacy ACPI idle handler, leaving
the CPU_IDLE handler, which does not track bus master activity.
So delete the unused bm_activity field -- it is confusing to
print an always zero value.
This patch could break programs that parse
/proc/acpi/processor/*/power, since it deletes this
line from that file:
bus master activity: 00000000
http://bugzilla.kernel.org/show_bug.cgi?id=13145
is not fixed by this patch, but provoked this patch.
Signed-off-by: Len Brown <len.brown@intel.com>
The c2 and c3 idle handlers check tsc_halts_in_c()
after every time they return from idle. Um, when?:-)
Move this check to init-time to remove the unnecessary
run-time overhead, and also to have the check complete before
the first entry into the idle handler.
ff69f2bba6
(acpi: fix of pmtimer overflow that make Cx states time incorrect)
replaced the hard-coded use of the PM-timer inside idle,
with ktime_get_readl(), which possibly uses the TSC --
so it is now especially prudent to detect a broken TSC
before entering idle.
http://bugzilla.kernel.org/show_bug.cgi?id=13087
Signed-off-by: Len Brown <len.brown@intel.com>
when the brightness level on AC and brightness level on Battery
are same, the level_ac_battery is 1 in the current code,
which is wrong.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Commit 900af0d973 (PM: Change suspend
code ordering) changed the ordering of suspend code in such a way
that the platform .prepare() callback is now executed after the
device drivers' late suspend callbacks have run. Unfortunately, this
turns out to break ARM platforms that need to talk via I2C to power
control devices during the .prepare() callback.
For this reason introduce two new platform suspend callbacks,
.prepare_late() and .wake(), that will be called just prior to
disabling non-boot CPUs and right after bringing them back on line,
respectively, and use them instead of .prepare() and .finish() for
ACPI suspend. Make the PM core execute the .prepare() and .finish()
platform suspend callbacks where they were executed previously (that
is, right after calling the regular suspend methods provided by
device drivers and right before executing their regular resume
methods, respectively).
It is not necessary to make analogous changes to the hibernation
code and data structures at the moment, because they are only used
by ACPI platforms.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Len Brown <len.brown@intel.com>
The polling interval (in deciseconds) was accidently interpreted as
being in milliseconds in one codepath, resulting in excessively frequent
polling. Ensure that the conversion is performed.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Executing BIOS code paths not exercised by Windows
tends to get Linux into trouble.
However, if a system does benefit from _GTS or _BFS,
acpi.gts=1 an acpi.bfs=1 are now available to enable them.
http://bugzilla.kernel.org/show_bug.cgi?id=13041
Signed-off-by: Len Brown <len.brown@intel.com>
The i915 DRM triggers registration of the ACPI video driver on load. It
should unregister it at unload in order to avoid generating backtraces on
being reloaded.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This reverts commit 5d38258ec0, since the
underlying problem got fixed properly in the previous commit ("async:
Fix module loading async-work regression").
Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In the current code, for a box with an indexed _BQC method, we
1. get the current brightness level by evaluating _BQC
2. set the value gotten in step 1 to _BCM
3. get the current brightness level again
4. set the _BQC_use_index flag if the results gotten
in step 1 and in step 3 don't equal.
But this logic doesn't work actually, because the _BQC_use_index
is not set when acpi_video_device_lcd_set_level is invoked.
This results in a failure in step 2.
http://bugzilla.kernel.org/show_bug.cgi?id=12249#c83
Now, we set the _BQC_use_index flag after invoking _BQC for the first
time. And reevaluate the _BQC to get the correct brightness level.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch removes the driver distinction between control method (CM)
and fixed hardware (FF) buttons. We previously needed that so we
could install either a fixed event handler or a notify handler, but
the Linux/ACPI code now handles that for us, so we don't need to
worry about it.
Note that this removes the FF/CM annotation from the "info" files
in /proc. For example,
/proc/acpi/button/PWRF/info:
-type: Power Button (FF)
+type: Power Button
I don't think there's anything meaningful user-space can do by
knowing whether a button is a control method or a fixed hardware
button, so nobody should be looking at the FF/CM.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We no longer need a pointer from struct acpi_button back to the
struct acpi_device. Everywhere we used that pointer, we either
already have, or can easily get, the acpi_device pointer without
using the copy from acpi_button. So this patch removes the
structure element.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds temporaries to cache the acpi_device_hid(),
acpi_device_name(), and acpi_device_class() pointers so we
don't have to clutter the code with so many uses of those
interfaces.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
It's typical and slightly more compact to look up the driver_data
structure by initializing the automatic variable at its definition.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Better to oops and learn about a bug than to silently cover it up.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch changes a bit of whitespace to follow Linux conventions.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add support for Always Running APIC timer, CPUID_0x6_EAX_Bit2.
This bit means the APIC timer continues to run even when CPU is
in deep C-states.
The advantage is that we can use LAPIC timer on these CPUs
always, and there is no need for "slow to read and program"
external timers (HPET/PIT) and the timer broadcast logic
and related code in C-state entry and exit.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Sony laptops apparently write 4-bytes (rather than 1 byte)
to debug port 0x80, which spews error messages:
Denied AML access to port 0x00000080/4 (DMA1 0x0081-0x0083) [20090320]
http://bugzilla.kernel.org/show_bug.cgi?id=13036
Signed-off-by: Len Brown <len.brown@intel.com>
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>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
Signed-off-by: Len Brown <len.brown@intel.com>
> BUG: unable to handle kernel NULL pointer dereference at (null)
What happens is that the battery module's init sections are being freed
before the async callback (which was marked __init) has run. This theory
is supported by the fact that the bad RIP value is a vmalloc address.
The immediate fix is to make this a non-init call.
(A better long-term fix is of course to wait with init-section unloading
until a module's async initcalls have been run, which would allow us to
discard this function which is still only run once, after all. Perhaps a
new async_initcall() function for the async/module API, if this is needed
for other modules in the future?)
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Tested-by: Alessandro Suardi <alessandro.suardi@gmail.com>
Tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI: pci_slot: grab refcount on slot's bus
PCI Hotplug: acpiphp: grab refcount on p2p subordinate bus
PCI: allow PCI core hotplug to remove PCI root bus
PCI: Fix oops in pci_vpd_truncate
PCI: don't corrupt enable_cnt when doing manual resource alignment
PCI: annotate pci_rescan_bus as __ref, not __devinit
PCI-IOV: fix missing kernel-doc
PCI: Setup disabled bridges even if buses are added
PCI: SR-IOV quirk for Intel 82576 NIC
Asus boards have an ACPI interface for interacting with the hwmon (fan,
temperatures, voltages) subsystem; this driver exposes the relevant
information via the standard sysfs interface.
There are two different ACPI interfaces:
- an old one (based on RVLT/RFAN/RTMP)
- a new one (GGRP/GITM)
Both may be present but there a few cases (my board, sigh) where the
new interface is just an empty stub; the driver defaults to the old one
when both are present.
The old interface has received a considerable testing, but I'm still
awaiting confirmation from my tester that the new one is working as
expected (hence the debug code is still enabled).
Currently all the attributes are read-only, though a (partial) control
should be possible with a bit more work.
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The exact offset between Kelvin and degree Celsius is 273.15. However
ACPI handles temperature values with a single decimal place. As a
consequence, some implementations use an offset of 273.1 and others
use an offset of 273.2. Try to find out which one is being used, to
present the most accurate and visually appealing number.
Tested on a Sony Vaio PGC-GR214EP (which uses 273.1) and a Lenovo
Thinkpad T60p (which uses 273.2).
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Convert acpi_device_lock to a mutex to avoid
a potential race upon access to /proc/acpi/wakeup
Delete the lock entirely in wakeup.c
since it is not necessary (and can not sleep)
Found-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
If a logical hot unplug (remove) is performed on a physical PCI slot's
parent bridge, and then pci_slot is unloaded, we will encounter an oops:
[<ffffffff803a788a>] kobject_release+0x9a/0x290
[<ffffffff803a77f0>] ? kobject_release+0x0/0x290
[<ffffffff803a8ce7>] kref_put+0x37/0x80
[<ffffffff803a76f7>] kobject_put+0x27/0x60
[<ffffffff803bebcc>] ? pci_destroy_slot+0x3c/0xc0
[<ffffffff803bebd5>] pci_destroy_slot+0x45/0xc0
[<ffffffffa000f05c>] acpi_pci_slot_remove+0x5c/0x91 [pci_slot]
[<ffffffff8040064b>] acpi_pci_unregister_driver+0x4b/0x62
[<ffffffffa000f5c8>] acpi_pci_slot_exit+0x10/0x12 [pci_slot]
[<ffffffff80276ce1>] sys_delete_module+0x161/0x250
We need to grab a reference to the parent PCI bus, which will pin
the bus and prevent it from being released until pci_slot is unloaded.
Cc: lenb@kernel.org
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reported-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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>
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.
Note that events from fixed hardware buttons now show up as a special
notify event, so to preserve user-space backward compatibility, we
convert that back to ACPI_BUTTON_NOTIFY_STATUS.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds support for ACPI device driver .notify() methods. If
such a method is present, Linux/ACPI installs a handler for device
notifications (but not for system notifications such as Bus Check,
Device Check, etc). When a device notification occurs, Linux/ACPI
passes it on to the driver's .notify() method.
In most cases, this removes the need for drivers to install their own
handlers for device-specific notifications.
For fixed hardware devices like some power and sleep buttons, there's
no notification value because there's no control method to execute a
Notify opcode. When a fixed hardware device generates an event, we
handle it the same as a regular device notification, except we send
a ACPI_FIXED_HARDWARE_EVENT value. This is outside the normal 0x0-0xff
range used by Notify opcodes.
Several drivers install their own handlers for system Bus Check and
Device Check notifications so they can support hot-plug. This patch
doesn't affect that usage.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The battery driver tends to take quite some time to initialize
(100ms-300ms is quite typical).
This patch initializes the batter driver asynchronously, so that other
things in the kernel can initialize in parallel to this 300 msec.
As part of this, the battery driver had to move to the back
of the ACPI init order (hence the Makefile change).
Without this move, the next ACPI driver would just block
on the ACPI/devicee layer semaphores until the battery driver was
done anyway, not gaining any boot time.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_video_device_write_state() and friends now return ssize_t,
while the constify patch assumed it was still int.
Signed-off-by: Len Brown <len.brown@intel.com>
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>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (28 commits)
trivial: Update my email address
trivial: NULL noise: drivers/mtd/tests/mtd_*test.c
trivial: NULL noise: drivers/media/dvb/frontends/drx397xD_fw.h
trivial: Fix misspelling of "Celsius".
trivial: remove unused variable 'path' in alloc_file()
trivial: fix a pdlfush -> pdflush typo in comment
trivial: jbd header comment typo fix for JBD_PARANOID_IOFAIL
trivial: wusb: Storage class should be before const qualifier
trivial: drivers/char/bsr.c: Storage class should be before const qualifier
trivial: h8300: Storage class should be before const qualifier
trivial: fix where cgroup documentation is not correctly referred to
trivial: Give the right path in Documentation example
trivial: MTD: remove EOL from MODULE_DESCRIPTION
trivial: Fix typo in bio_split()'s documentation
trivial: PWM: fix of #endif comment
trivial: fix typos/grammar errors in Kconfig texts
trivial: Fix misspelling of firmware
trivial: cgroups: documentation typo and spelling corrections
trivial: Update contact info for Jochen Hein
trivial: fix typo "resgister" -> "register"
...
dock_remove() calls kfree() on dock_station so we should use
list_for_each_entry_safe() to avoid dereferencing freed memory.
Found by smatch (http://repo.or.cz/w/smatch.git/). Compile tested.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The recent ACPICA patch
(ACPICA: FADT: Favor 32-bit register addresses for compatibility)
makes machine to use the right FADT HW addresses
and C-states now work fine.
http://bugzilla.kernel.org/show_bug.cgi?id=8246
Signed-off-by: Thomas Renninger <trenn@suse.de>
Tested-by: Mark Doughty <me@markdoughty.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
The Pansonic CF51-2L requires "acpi_sleep=old_ordering",
so invoke it automatically via DMI.
http://bugzilla.kernel.org/show_bug.cgi?id=12561
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Enforce strict resource checking - disallowing access by native
drivers to IO ports and memory regions claimed by ACPI firmware.
The patch is mainly aimed to block native hwmon drivers from touching
monitoring chips that ACPI thinks it own.
If this causes a regression, boot with "acpi_enforce_resources=lax"
which was the previous default.
http://bugzilla.kernel.org/show_bug.cgi?id=12376http://bugzilla.kernel.org/show_bug.cgi?id=12541
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Impact: cleanup
Rather than overriding MODULE_PARAM_PREFIX, build via acpi.o so
KBUILD_MODNAME is set to "acpi".
This is the logical way to do it, even though acpi cannot be a module
due to these config options being bool. Those parts of ACPI which can
be modular are not built into the acpi "module".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (88 commits)
PCI: fix HT MSI mapping fix
PCI: don't enable too much HT MSI mapping
x86/PCI: make pci=lastbus=255 work when acpi is on
PCI: save and restore PCIe 2.0 registers
PCI: update fakephp for bus_id removal
PCI: fix kernel oops on bridge removal
PCI: fix conflict between SR-IOV and config space sizing
powerpc/PCI: include pci.h in powerpc MSI implementation
PCI Hotplug: schedule fakephp for feature removal
PCI Hotplug: rename legacy_fakephp to fakephp
PCI Hotplug: restore fakephp interface with complete reimplementation
PCI: Introduce /sys/bus/pci/devices/.../rescan
PCI: Introduce /sys/bus/pci/devices/.../remove
PCI: Introduce /sys/bus/pci/rescan
PCI: Introduce pci_rescan_bus()
PCI: do not enable bridges more than once
PCI: do not initialize bridges more than once
PCI: always scan child buses
PCI: pci_scan_slot() returns newly found devices
PCI: don't scan existing devices
...
Fix trivial append-only conflict in Documentation/feature-removal-schedule.txt
If ECDT info is not valid, we have last chance to configure
EC driver properly at this point, don't miss it.
http://bugzilla.kernel.org/show_bug.cgi?id=12461
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
MSI notebooks require very strict delays, while all others
are happy with msleep().
References: http://bugzilla.kernel.org/show_bug.cgi?id=9998
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
A few comments say "Celcius"; this fixes them. No code changes.
Signed-off-by: Adam Buchbinder <adam.buchbinder@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
ACPI backlight control w/o _BQC support is kinda firmware bug.
Add a warning if _BQC is not implemented.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI has smart batteries, which work in units of energy and measure
rate of (dis)charge as power, thus it is not appropriate to export it
as a current_now. Current_now will still be exported to allow
for userland applications to match.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Intel graphics hardware that implements the ACPI IGD OpRegion spec
requires that the list of display devices be populated before any ACPI
video methods are called. Detect when this is the case and defer
registration until the opregion code calls it. Fixes crashes on HP
laptops.
http://bugzilla.kernel.org/show_bug.cgi?id=11259
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Some buggy BIOSes implements _BCQ instead of _BQC.
Male ACPI video driver support these buggy BIOS.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The input/output of _BQC/_BCL/_BCM control methods should be represented
by a number between 0 and 100, and can be thought of as a percentage.
But some buggy _BQC/_BCL/_BCM methods use the index values instead.
http://bugzilla.kernel.org/show_bug.cgi?id=12302http://bugzilla.kernel.org/show_bug.cgi?id=12249http://bugzilla.kernel.org/show_bug.cgi?id=12037
Add the functionality to support such kind of BIOSes in ACPI video driver.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Many buggy BIOSes don't export the brightness levels when machine
is on AC/Battery in the _BCL method.
Reformat the _BCL package for these laptops:
now the elements in device->brightness->levels[] are like:
levels[0]: brightness level when on AC power.
levels[1]: brightness level when on Battery power.
levels[2]: supported brightness level 1.
levels[3]: supported brightness level 2.
...
levels[n]: supported brightness level n-1.
levels[n + 1]: supported brightness level n.
So if there are n supported brightness levels on this laptop,
we will have n+2 entries in device->brightnes->levels[].
level[0] and level[1] are invalid on the laptops that don't
export the brightness levels on AC/Battery.
Fortunately, we never use these two values at all, even for the
valid ones.
http://bugzilla.kernel.org/show_bug.cgi?id=12249
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
When cpufreq driver call acpi_processor_preregister_performance() , function
will clean up pr->performance even if there is possibly already registered
other cpufreq driver. The patch fix this potential problem. It also remove
double checks in P domain basic validity code and move these checks to function
where _PSD data is captured.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
> drivers/acpi/thermal.c: In function 'thermal_notify':
> drivers/acpi/thermal.c:768: error: 'struct device' has no member named 'bus_id'
>
> Caused by commit b1569e99c7 ("ACPI: move
> thermal trip handling to generic thermal layer") interacting with commit
> d4a078fca590911cdf87a8eaffee1b6e643c2558 ("driver core: get rid of struct
> device's bus_id string array").
>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch removes the suggestion that ec.o link order is important,
because it doesn't matter since acpi_ec_init() is no longer an initcall.
And it puts together most of the core modules that are not configurable.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call acpi_wakeup_device_init() directly.
Previously, acpi_wakeup_device_init() was a late_initcall (sequence 7).
acpi_wakeup_device_init() depends on acpi_wakeup_device_list, which
is populated when ACPI devices are enumerated by acpi_init() ->
acpi_scan_init(). Using late_initcall is certainly enough to make
sure acpi_wakeup_device_list is populated, but it is more than
necessary. We can just as easily call acpi_wakeup_device_init()
directly from acpi_init(), which avoids the initcall magic.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call acpi_sleep_proc_init() directly.
Previously, acpi_sleep_proc_init() was a late_initcall (sequence 7),
apparently to make sure that the /proc hierarchy already exists:
2003/02/13 12:38:03-06:00 mochel
acpi sleep: demote sleep proc file creation.
- Make acpi_sleep_proc_init() a late_initcall(), and not called from
acpi_sleep_init(). This guarantees that the acpi proc hierarchy is at
least there when we create the dang file.
This should no longer be an issue because acpi_bus_init() (called early
in acpi_init()) creates acpi_root_dir (/proc/acpi).
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call init_acpi_device_notify() directly.
Previously, init_acpi_device_notify() was an arch_initcall (sequence 3),
so it was called before acpi_init() (a subsys_initcall at sequence 4).
init_acpi_device_notify() sets the platform_notify and
platform_notify_remove function pointers. These pointers
are not used until acpi_init() enumerates ACPI devices in
this path:
acpi_init()
acpi_scan_init()
acpi_bus_scan()
acpi_add_single_object()
acpi_device_register()
device_add()
<use platform_notify>
So it is sufficient to have acpi_init() call init_acpi_device_notify()
directly before it enumerates devices.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call acpi_debug_init() directly.
Previously, both were subsys_initcalls. acpi_debug_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call acpi_system_init() directly.
Previously, both were subsys_initcalls. acpi_system_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call acpi_power_init() directly.
Previously, both were subsys_initcalls. acpi_power_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call acpi_ec_init() directly.
Previously, both were subsys_initcalls. acpi_ec_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() call acpi_scan_init() directly.
Previously, both acpi_init() and acpi_scan_init() were subsys_initcalls,
and acpi_init() was called first based on the link order from the
makefile (bus.o before scan.o).
acpi_scan_init() registers the ACPI bus type, creates the root device,
and enumerates fixed-feature and namespace devices. All of this must
be done after acpi_init(), and it's better to call acpi_scan_init()
explicitly rather than rely on the link ordering.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes acpi_init() exit early when ACPI is disabled.
This skips a DMI check that affects ACPI power management. The
DMI check prints a notice that is misleading when ACPI is disabled.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
For predefined method validation. Index value in warning message
could be off by one.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
If both the 32-bit and 64-bit addresses are non-null, use the
32-bit address. Provides Windows compatibility.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Use the 32-bit register addresses whenever they are non-zero. This
means that the 32-bit addresses are favored over the 64-bit
(GAS) addresses. The 64-bit addresses are only used if the 32-bit
addresses are zero. This change provides compatibility with all
versions of Windows. The worst case that this solves is when both
the 32-bit and 64-bit addresses are non-zero, but only the 32-bit
addresses are actually valid. This appears to happen in some
BIOSes because in this case, Windows uses the 32-bit addresses.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Microsoft website uses 0xCF8-0xD00. Should be 0xCF8-0xCFF (Two
32-bit registers.)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
One entry in the protected port table eliminated. Added extra
comments to describe each table entry.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Removed unused code for dump of args and locals. General cleanup
and splitting of long lines.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Affects PM1 Control register only. When reading the register, zero
the write-only bits as per the ACPI spec. ACPICA BZ 443. Lin Ming.
http://www.acpica.org/bugzilla/show_bug.cgi?id=443
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>
This interface is no longer necessary. Requests should be validated
on a per-field basis, not on the entire operation region.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Protect certain I/O ports from reads/writes. Provides MS
compatibility. New module, hwvalid.c
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
As per the ACPI specification, preserve (read/modify/write) all
bits that are defined as either reserved or ignored (PM control
control registers only.)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Ignored bits must be preserved according to the ACPI spec.
Usually this means a read/modify/write when writing to the
register. However, for status registers, writing a one means
clear the event. Writing a zero means preserve the event (do not
clear.) This behavior is clarified in the ACPI 4.0 spec, and the
ACPICA code now simply always writes a zero to the ignored bit.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Added a reader/writer locking mechanism to allow multiple
concurrent namespace walks (readers), but a dynamic table unload
will have exclusive access to the namespace. This fixes a problem
where a table unload could delete the portion of the namespace that
is currently being examined by a walk. Adds a new file, utlock.c
that implements the reader/writer lock mechanism. ACPICA BZ 749.
http://www.acpica.org/bugzilla/show_bug.cgi?id=749
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Incorrect register length mismatch between the 32 and 64 bit
registers in some cases. Code was was checking the wrong pointer
for non-zero, should be looking at the address within the GAS
structure.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Split long lines, update comments.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add and deploy constants for the PM status/enable/control
registers.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cleanup table header output.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Update code for acpi_read_bit_register and acpi_write_bit_register.
Simplified code path, condensed duplicate code.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Rename acpi_get_register and acpi_set_register to clarify the
purpose of these functions. New names are acpi_read_bit_register
and acpi_write_bit_register.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Removed locking for reads from the ACPI bit registers in PM1
Status, Enable, Control, and PM2 Control. The lock is not required
when reading the single-bit registers. The acpi_get_register_unlocked
function is no longer needed and has been removed. This will
improve performance for reads on these registers. ACPICA BZ 760.
http://www.acpica.org/bugzilla/show_bug.cgi?id=760
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Split some long lines.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Removed some of the extraneous debug prints using the DB_INFO
level. This should make the DB_INFO more useful.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Print input strings and the result (supported or not supported)
for invocations of the _OSI method.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This function is only needed on 64-bit host operating systems.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Remove all instances of this obsolete macro, since it is now a
simple reference to ->common.type. There were about 150 invocations
of the macro across 41 files. ACPICA BZ 755.
http://www.acpica.org/bugzilla/show_bug.cgi?id=755
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Added acpi_hw_write_pm1_control. This function writes both of the PM1
control registers (A/B). These registers are different than than
the PM1 A/B status and enable registers in that different values
can be written to the A/B registers. Most notably, the SLP_TYP
bits can be different, as per the values returned from the _Sx
predefined methods.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This type is the same as TYPE_A. Removed this and all related
instances. Renamed SLEEP_TYPE_A to simply SLEEP_TYPE.
ACPICA BZ 754.
http://www.acpica.org/bugzilla/show_bug.cgi?id=754
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Now return AE_BAD_PARAMETER if the input register pointer is
null, and AE_BAD_ADDRESS if the register has an address of zero.
Previously, these cases simply returned AE_OK. For optional
registers such as PM1B status/enable/control, the caller should
check for a valid register address before calling. ACPICA BZ 748.
http://www.acpica.org/bugzilla/show_bug.cgi?id=748
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The PM1B registers are mirrors of the PM1A registers with
different bits actually implemented. From the ACPI specification:
"Although the bits can be split between the two register blocks
(each register block has a unique pointer within the FADT), the bit
positions are maintained. The register block with unimplemented
bits (that is, those implemented in the other register block)
always returns zeros, and writes have no side effects"
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This function was writing an optional PM1B status register
twice. The existing call to the low-level acpi_hw_register_write
automatically handles a possibly split PM1 A/B register.
ACPICA BZ 751.
http://www.acpica.org/bugzilla/show_bug.cgi?id=751
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
On read, shift B register bits above the A bits. On write,
shift B bits down to zero before writing the B register. New:
acpi_hw_read_multiple, acpi_hw_write_multiple. These two functions now
transparently handle the (possible) split registers for PM1 Status,
Enable, and Control.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Enhance the explanations of the various package return types
for clarity.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add new globals for the PM1 status registers (A/B), similar to the
way the PM1 enable registers are handled. Instead of overloading
the FADT Event Register blocks. This makes the code clearer and
less prone to error.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add a call to acpi_os_table_override during the installation of a
dynamic table (loaded via the Load or LoadTable AML operators).
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Removed the Flags parameter from several internal functions since
it was not being used.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Previously, the table override mechanism was implemented for the
DSDT only. Now, any table in the RSDT/XSDT can be replaced by
the host OS. (including the DSDT).
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add check for invalid handle in acpi_ns_dump_one_object.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch implements uevent suppress in kobject and removes it
from struct device, based on the following ideas:
1,Uevent sending should be one attribute of kobject, so suppressing it
in kobject layer is more natural than in device layer. By this way,
we can do it for other objects embedded with kobject.
2,It may save several bytes for each instance of struct device.(On my
omap3(32bit ARM) based box, can save 8bytes per device object)
This patch also introduces dev_set|get_uevent_suppress() helpers to
set and query uevent_suppress attribute in case to help kobject
as private part of struct device in future.
[This version is against the latest driver-core patch set of Greg,please
ignore the last version.]
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
- Rename pci_osc_control_set() to acpi_pci_osc_control_set() according
to the other API names in drivers/acpi/pci_root.c.
- Move _OSC related definitions to include/linux/acpi.h because _OSC
related API is implemented in drivers/acpi/pci_root.c now.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reviewed-by: Andrew Patterson <andrew.patterson@hp.com>
Tested-by: Andrew Patterson <andrew.patterson@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Move PCI _OSC management code from drivers/pci/pci-acpi.c to
drivers/acpi/pci_root.c. The benefits are
- We no longer need struct osc_data and its management code (contents
are moved to struct acpi_pci_root). This simplify the code, and we
no longer care about kmalloc() failure.
- We can make pci_acpi_osc_support() be a static function, which is
called only from drivers/acpi/pci_root.c.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reviewed-by: Andrew Patterson <andrew.patterson@hp.com>
Tested-by: Andrew Patterson <andrew.patterson@hp.com>
Acked-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
A number of things that shouldn't be exposed outside the ACPI core
were declared in include/acpi/acpi_drivers.h, where anybody can
see them. This patch moves those declarations to a new "internal.h"
inside drivers/acpi.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Use "help" (not "---help---") consistently throughout.
ACPI can't be a module, so if both ACPI & APM are configured,
we use ACPI.
Update pointers to ACPI CA and Linux ACPI projects.
Replace "Compaq" with "Hewlett-Packard" in the spec developer list.
Fix typo in /sys/module path.
The user-space daemon is "acpid", not "acpi".
Add standard "To compile this driver as a module ..." help text.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Use the generic pci_swizzle_interrupt_pin() instead of ACPI-specific code.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We don't need a struct containing a count and a list_head; a simple
list_head is sufficient. The list iterators handle empty lists
fine.
Furthermore, we don't need to check for null list entries because we
only add non-null entries.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Better to oops and learn about a bug than to silently cover it up.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch makes whitespace and indentation more consistent.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We found Cx states time abnormal in our some of machines which have 16
LCPUs, the C0 take too many time while system is really idle when kernel
enabled tickless and highres. powertop output is below:
PowerTOP version 1.9 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) (40.5%) 2.53 Ghz 0.0%
C1 0.0ms ( 0.0%) 2.53 Ghz 0.0%
C2 128.8ms (59.5%) 2.40 Ghz 0.0%
1.60 Ghz 100.0%
Wakeups-from-idle per second : 4.7 interval: 20.0s
no ACPI power usage estimate available
Top causes for wakeups:
41.4% ( 24.9) <interrupt> : extra timer interrupt
20.2% ( 12.2) <kernel core> : usb_hcd_poll_rh_status
(rh_timer_func)
After tacking detailed for this issue, Yakui and I find it is due to 24
bit PM timer overflows when some of cpu sleep more than 4 seconds. With
tickless kernel, the CPU want to sleep as much as possible when system
idle. But the Cx sleep time are recorded by pmtimer which length is
determined by BIOS. The current Cx time was gotten in the following
function from driver/acpi/processor_idle.c:
static inline u32 ticks_elapsed(u32 t1, u32 t2)
{
if (t2 >= t1)
return (t2 - t1);
else if (!(acpi_gbl_FADT.flags & ACPI_FADT_32BIT_TIMER))
return (((0x00FFFFFF - t1) + t2) & 0x00FFFFFF);
else
return ((0xFFFFFFFF - t1) + t2);
}
If pmtimer is 24 bits and it take 5 seconds from t1 to t2, in above
function, just about 1 seconds ticks was recorded. So the Cx time will be
reduced about 4 seconds. and this is why we see above powertop output.
To resolve this problem, Yakui and I use ktime_get() to record the Cx
states time instead of PM timer as the following patch. the patch was
tested with i386/x86_64 modes on several platforms.
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Tested-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Yakui.zhao <yakui.zhao@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
It is hardly (if ever) possible but in case of broken _PXM entry we could
reach out of pxm_to_node_map array bounds in acpi_map_pxm_to_node() call.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
There was a misplaced status test (two consequent tests without a
statement in between) in acpi_bus_init for ages. Remove it, since the
function which should be checked (acpi_os_initialize1) has BUG_ONs on
failure paths.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit 5ec5d38a1c.
because it caused spurious dmesg warmings.
We'll implement the check for off-limit ports
in a more clever way in the future.
http://bugzilla.kernel.org/show_bug.cgi?id=12758
Signed-off-by: Len Brown <len.brown@intel.com>
Switch the Asus Pundit P1-AH2 (M2N8L motherboard) to the old ACPI 1.0
sleep ordering by default. Without this it will not suspend/resume
correctly.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Tested-by: Dustin Kirkland <kirkland@canonical.com>
Signed-off-by: Len Brown <len.brown@intel.com>
SSDT tables may be loaded at runtime.
create sysfs I/F for these dynamic tables in
/sys/firmware/acpi/tables/dynamic/.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
early_acpi_os_unmap_memory() is an __init function, and
acpi_os_unmap_memory() is allowed to access an __init function
until acpi_gbl_permanent_mmap is set up.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Remove CONFIG_ACPI_SYSTEM. It was always set the same as CONFIG_ACPI,
and it had no menu label, so there was no way to set it to anything
other than "y".
Some things under CONFIG_ACPI_SYSTEM (acpi_irq_handled, acpi_os_gpe_count(),
event_is_open, register_acpi_notifier(), etc.) are used unconditionally
by the CA, the OSPM, and drivers, so we depend on them always being
present.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
On hardware like the T61 it can take a couple of seconds for the battery
to start charging after the power is connected, and we incorrectly tell
userspace that we are fully charged, and then go back to charging.
Only mark a battery as fully charged when the preset charge matches either
the last full charge, or the design charge.
http://bugzilla.kernel.org/show_bug.cgi?id=12632
Signed-off-by: Richard Hughes <hughsient@gmail.com>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI code currently carries its own thermal trip handling, meaning that
any other thermal implementation will need to reimplement it. Move the code
to the generic thermal layer.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The thermal API currently uses strings to pass values to userspace. This
makes it difficult to use from within the kernel. Change the interface
to use integers and fix up the consumers.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Impact: cleanup
There are two allocated per-cpu accessor macros with almost identical
spelling. The original and far more popular is per_cpu_ptr (44
files), so change over the other 4 files.
tj: kill percpu_ptr() and update UP too
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: mingo@redhat.com
Cc: lenb@kernel.org
Cc: cpufreq@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
to prevent wrongly overwriting fixmap that still want to use.
ACPI used to rely on low mappings being all linearly mapped and
grew a habit: it never really unmapped certain kinds of tables
after use.
This can cause problems - for example the hypothetical case
when some spurious access still references it.
v2: remove prev_map and prev_size in __apci_map_table
v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
early_acpi_os_unmap_memory
v4: fix typo in one acpi_get_table_with_size calling
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
On x86, __acpi_map_table uses early_ioremap() to create the mapping,
replacing the previous mapping with a new one. Once enough of the
kernel is up an running it switches to using normal ioremap(). At
that point, we need to clean up the final mapping to avoid a warning
from the early_ioremap subsystem.
This can be removed after all the instances in the ACPI code are fixed
that rely on early-ioremap's implicit overmapping of previously
mapped tables.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
During early boot, ACPI RSDT/XSDT table entries are gathered into the
'initial_tables[]' array. This array is currently statically defined (see
./drivers/acpi/tables.c). When there are more table entries than can be
held in the 'initial_tables[]' array, the message "Truncating N table
entries!" is output. As currently implemented, this message will always
erroneously calculate N as 0.
This patch fixes the calculation that determines how many table entries
will be missing (truncated).
This modification may be used under either the GPL or the BSD-style
license used for Intel ACPI CA code.
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the missing peaces here for the acpi subsystem.
Signed-off-by: Frank Seidel <frank@f-seidel.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Some devices trigger a DEVICE_CHECK on every evalutation of _STA. This
can also be seen in commit 8b59560a3b
(ACPI: dock: avoid check _STA method). If an undock is processed, the
dock driver sends a uevent and userspace might read the show_docked
property in sysfs. This causes an evaluation of _STA of the particular
device which causes the dock driver to immediately dock again.
In any case, evaluation of _STA (show_docked) does not necessarily mean
that we are docked, so check with the internal device structure.
http://bugzilla.kernel.org/show_bug.cgi?id=12360
Signed-off-by: Holger Macht <hmacht@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
When ACPI is disabled in the BIOS of this VIA C3 box,
it invalidates the RSDP, which Linux notices:
ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926]
Bug Linux neglected to disable ACPI at that stage,
and later scribbled on smp_found_config:
ACPI: No APIC-table, disabling MPS
But this box doesn't run well in legacy PIC mode,
it needed IOAPIC mode to perform correctly:
http://lkml.org/lkml/2009/2/5/39
So exit ACPI mode cleanly when we first detect
that it is hopeless.
Signed-off-by: Len Brown <len.brown@intel.com>
CPU_IDLE=y has been default for ACPI=y since Nov-2007,
and has shipped in many distributions since then.
Here we delete the CPU_IDLE=n ACPI idle code, since
nobody should be using it, and we don't want to
maintain two versions.
Signed-off-by: Len Brown <len.brown@intel.com>
Currently, netlink_broadcast() reports errors to the caller if no
messages at all were delivered:
1) If, at least, one message has been delivered correctly, returns 0.
2) Otherwise, if no messages at all were delivered due to skb_clone()
failure, return -ENOBUFS.
3) Otherwise, if there are no listeners, return -ESRCH.
With this patch, the caller knows if the delivery of any of the
messages to the listeners have failed:
1) If it fails to deliver any message (for whatever reason), return
-ENOBUFS.
2) Otherwise, if all messages were delivered OK, returns 0.
3) Otherwise, if no listeners, return -ESRCH.
In the current ctnetlink code and in Netfilter in general, we can add
reliable logging and connection tracking event delivery by dropping the
packets whose events were not successfully delivered over Netlink. Of
course, this option would be settable via /proc as this approach reduces
performance (in terms of filtered connections per seconds by a stateful
firewall) but providing reliable logging and event delivery (for
conntrackd) in return.
This patch also changes some clients of netlink_broadcast() that
may report ENOBUFS errors via printk. This error handling is not
of any help. Instead, the userspace daemons that are listening to
those netlink messages should resync themselves with the kernel-side
if they hit ENOBUFS.
BTW, netlink_broadcast() clients include those that call
cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
internally call netlink_broadcast() and return its error value.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
They were long enough set deprecated...
Update Documentation/cpu-freq/users-guide.txt:
The deprecated files listed there seen not to exist for some time anymore
already.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPICA exports acpi_os_validate_address() so the OS
can prevent BIOS AML from accessing specified addresses.
Start using this interface to prevent AML from accessing
some well known IO addresses that the OS "owns".
Signed-off-by: Len Brown <len.brown@intel.com>
on boot, print out the OSI strings the BIOS uses to query the OS.
To see this output...
build with CONFIG_ACPI_DEBUG
boot with
"acpi.debug_level=4" (ACPI_LV_INFO) (enabled by default)
and
"acpi.debug_level=1" (ACPI_UTILITIES) (default is 0)
example output:
ACPI: BIOS _OSI(Windows 2001) supported
ACPI: BIOS _OSI(Windows 2001 SP1) supported
ACPI: BIOS _OSI(Windows 2001 SP2) supported
ACPI: BIOS _OSI(Windows 2006) supported
ACPI: BIOS _OSI(Linux) not-supported
ACPI: BIOS _OSI(FreeBSD) not-supported
Signed-off-by: Len Brown <len.brown@intel.com>
According to the Spec the first two elements in the _BCL package won't be
regarded as the available brightness level. The first is the brightness when
full power is connected to the box(It means that the AC adapter is plugged).
The second is the brightness level when the box is on battery.
If the first two elements are still used while finding the next brightness
level, it will fall back to the lowest level when keeping on pressing
hotkey. (On some boxes the brightness will be changed twice when hotkey is
pressed once. One is in the ACPI video driver. The other is changed by sys I/F.
In the ACPI video driver the first two elements will be used while changing
the brightness. But the first two elements is skipped while using sys I/F.
In such case there exists the inconsistency).
So he first two elements had better be skipped while showing the available
brightness or finding the next brightness level.
http://bugzilla.kernel.org/show_bug.cgi?id=12450
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
It is true that BM_RLD needs to be set to enable
bus master activity to wake an older chipset (eg PIIX4) from C3.
This is contrary to the erroneous wording the ACPI 2.0, 3.0
specifications that suggests that BM_RLD is an indicator
rather than a control bit.
ACPI 1.0's correct wording should be restored in ACPI 4.0:
http://www.acpica.org/bugzilla/show_bug.cgi?id=689
But the kernel should not have to clear BM_RLD
when entering a non C3-type state just to set
it again when entering a C3-type C-state.
We should be able to set BM_RLD at boot time
and leave it alone -- removing the overhead of
accessing this IO register from the idle entry path.
Signed-off-by: Len Brown <len.brown@intel.com>
PM1a_STS and PM1b_STS are twins that get OR'd together
on reads, and all writes are repeated to both.
The fields in PM1x_STS are single bits only,
there are no multi-bit fields.
So it is not necessary to lock PM1x_STS reads against
writes because it is impossible to read an intermediate
value of a single bit. It will either be 0 or 1,
even if a write is in progress during the read.
Reads are asynchronous to writes no matter if a lock
is used or not.
Signed-off-by: Len Brown <len.brown@intel.com>
This patch fixes the crash I experienced in 2.6.29-rc2.
Tested on ASUS M50vm.
Signed-off-by: Tero Roponen <tero.roponen@gmail.com>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
