Use existing dmi_get_system_info(),
Delete duplicate dmi_get_slot()
Spotted-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Len Brown <len.brown@intel.com>
dmi_check_system() does sub-string matching using strstr(),
rather than exact string compares with !strcmp().
So delete the longer of the Acer blacklist entries, as its
function is just a redundant console message.
Spotted-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
According to ACPI spec, the _TSD object provides T-state control cross
logical processor dependency information to OSPM. So the t-state
coordination should be considered when T-state for one cpu is changed.
According to ACPI spec, three types of coordination are defined.
SW_ALL, SW_ANY and HW_ALL.
SW_ALL: it means that OSPM needs to initiate T-state transition on
all processors in the domain. It is necessary to call throttling set function
for all affected cpus.
SW_ANY: it means that OSPM may initiate T-state transition on any processor in
the domain.
HW_ALL: Spec only says that hardware will perform the coordination and doesn't
recommend how OSPM coordinate T-state among the affected cpus. So it is treated
as the type of SW_ALL. It means that OSPM needs to initiate t-state transition
on all the processors in the domain.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The t-state coordination should be considered when T-state for one cpu
is changed.It means that OSPM should select one proper target T-state for
the all affected cpus before updating T-state.
So the function of acpi_processor_throttling_notifier is added.
Before updating T-state it can be called for all the affected cpus to get
the proper target T-state, which can meet the requirement of thermal, user and
_TPC. After updating T-state, it can be called to update T-state flag.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Accordint to ACPI spec, the _TSD object provides T-state control cross
logical processor dependency information to OSPM.
After the _TSD data for all cpus are obtained, OSPM will set up
the T-state coordination between CPUs.
Of course if the _TSD doesn't exist or _TSD data is incorrect , it is
assumed that there is no T-state coordination and T-state is changed
independently.
Now there is no proper solution to update T-state coordination after
one cpu is hotplugged. So this patch won't support hotplugged cpu very well.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
It is necessary to check the parameter when calling the function of
acpi_processor_get/set_throttling function so as to avoid the NULL
pointer reference in pr or throttling.
http://bugzilla.kernel.org/show_bug.cgi?id=9747
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Vendors often ship machines with a choice of integrated or discrete
graphics, and use the same DSDT for both. As a result, the ACPI video
module will locate devices that may not exist on this specific platform.
Attempt to determine whether the device exists or not, and abort the
device creation if it doesn't.
http://bugzilla.kernel.org/show_bug.cgi?id=9614
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The alias name may be used in _PSL, _ALx and _TZD,
so we bind the cooling device only if the acpi_device node matches.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix an imprecision in CELSIUS_TO_KELVIN and move these
two macroes to a proper place.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Intel menlow driver needs to get the pointer of themal_zone_device
structure of an ACPI thermal zone.
Attach this to each ACPI thermal zone device object.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Register ACPI video device as thermal cooling devices as they may be listed
in _TZD method and the backlight control can be used for throttling.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Register ACPI processor as thermal cooling devices.
A combination of processor T-state and P-state are used for thermal throttling.
the processor will reduce the frequency first and then set the T-state.
we use cpufreq_thermal_reduction_pctg to calculate the cpufreq limit,
and call cpufreq_verify_with_limit to set the cpufreq limit.
if cpufreq driver is loaded, then we have four cooling state for cpufreq control.
cooling state 0: cpufreq limit == max_freq
cooling state 1: cpufreq limit == max_freq * 80%
cooling state 2: cpufreq limit == max_freq * 60%
cooling state 3: cpufreq limit == max_freq * 40%
after the cpufreq limit is set to 40 percentage of the max_freq,
we use T-state for cooling.
eg. a processor has P-state support, and it has 8 T-state (T0-T7),
the max_state of the proceesor is 10:
state cpufreq-limit T-state
0: max_freq T0
1: max_freq * 80% T0
2: max_freq * 60% T0
3: max_freq * 40% T0
4: max_freq * 40% T1
5: max_freq * 40% T2
6: max_freq * 40% T3
7: max_freq * 40% T4
8: max_freq * 40% T5
9: max_freq * 40% T6
10: max_freq * 40% T7
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Register ACPI Fan as thermal cooling device.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Change the ACPI thermal action upon notification 0x81 and 0x82.
According to the ACPI spec, we should:
re-evaluate _PSV and _ACx methods upon notification 0x81
re-evaluate _PSL and _ALx and _TZD upon notificaiton 0x82.
But the current code re-evaluates all the trip points for 0x81 while
only re-evaluates _TZD for 0x82.
Fix this violation of ACPI spec.
TODO: devices in _PSL, _ALx and _TZD may change after a notification 0x82.
At this time, we need to re-bind the cooling devices with the thermal zone.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Register ACPI thermal zone as thermal zone device.
the new sys I/F for ACPI thermal zone will be like this:
/sys/class/thermal:
|thermal_zone1:
|-----type: "ACPI thermal zone". RO
|-----temp: the current temperature. RO
|-----mode: the current working mode. RW.
the default value is "kernel" which means thermal
management is done by ACPI thermal driver.
"echo user > mode" prevents all the ACPI thermal driver
actions upon any trip points.
|-----trip_point_0_temp: the threshold of trip point 0. RO.
|-----trip_point_0_type: "critical". RO.
the type of trip point 0
This may be one of critical/hot/passive/active[x]
for an ACPI thermal zone.
...
|-----trip_point_3_temp:
|-----trip_point_3_type: "active[1]"
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Sujith <sujith.thomas@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The sysfs backlight class provides no mechanism for querying the
acceptable brightness for a backlight. The ACPI spec states that values
are only valid if they are reported as available by the firmware. Since
we can't provide that information to userspace, instead collapse the
range to the number of actual values that can be set.
http://bugzilla.kernel.org/show_bug.cgi?id=9277
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Make acpi_sleep_prepare() static and cause it to print a message
specifying the ACPI system sleep state to be entered (helpful for
debugging the suspend/hibernation code).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI 1.0 specification wants us to put devices into low power
states after executing the _PTS global control method, while ACPI
2.0 and later want us to do that in the reverse order. The current
hibernation code follows ACPI 2.0 in that respect which may cause some
ACPI 1.0x systems to hang during hibernation (ref.
http://bugzilla.kernel.org/show_bug.cgi?id=9528).
Make the hibernation code execute _PTS before putting devices into
low power states (ie. in accordance with ACPI 1.0x) with the
possibility to override that using the 'acpi_new_pts_ordering' kernel
command line option.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Introduce global hibernation callback .end() and rename global
hibernation callback .start() to .begin(), in analogy with the
recent modifications of the global suspend callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI 1.0 specification wants us to put devices into low power
states after executing the _PTS global control method, while ACPI
2.0 and later want us to do that in the reverse order. The current
suspend code follows ACPI 2.0 in that respect which causes some
ACPI 1.0x systems to hang during suspend (ref.
http://bugzilla.kernel.org/show_bug.cgi?id=9528).
Make the suspend code execute _PTS before putting devices into low
power states (ie. in accordance with ACPI 1.0x) and provide a command
line option to override the default if need be.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
The preparation to enter an ACPI system sleep state is now tied to
the disabling of GPEs, but the GPEs should not be disabled before
suspending devices. Since on ACPI 1.0x systems the _PTS global
control method should be executed before suspending devices, we
need to disable GPEs separately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
The execution of ACPI global control methods _GTS and _BFS is
currently tied to the preparation to enter a sleep state and to the
leaving of the sleep state, respectively. However, these functions
are called before disabling the nonboot CPUs and after enabling
them, respectively (in fact, on ACPI 1.0x systems the first of them
ought to be called before suspending devices), while according to the
ACPI specification, _GTS is to be executed right prior to entering
the system sleep state and _BFS is to be executed right after the
platfor firmware has returned control to the OS on wake up.
Move the execution of _GTS and _BFS to the right places.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
On ACPI systems the target state set by acpi_pm_set_target() is
reset by acpi_pm_finish(), but that need not be called if the
suspend fails. All platforms that use the .set_target() global
suspend callback are affected by analogous issues.
For this reason, we need an additional global suspend callback that
will reset the target state regardless of whether or not the suspend
is successful. Also, it is reasonable to rename the .set_target()
callback, since it will be used for a different purpose on ACPI
systems (due to ACPI 1.0x code ordering requirements).
Introduce the global suspend callback .end() to be executed at the
end of the suspend sequence and rename the .set_target() global
suspend callback to .begin().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Wakeup GPE hasn't a handler. If system is waked up by such GPE like a
USB hotplug, I saw a lot of error reporting the GPE hasn't handler.
acpi_leave_sleep_state will clear the GPE but it's too late, we should
do it before interrupt is re-enabled.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Some code in acpi_hibernation_finish() was moved to acpi_hibernation_leave(),
but the old copy had been left (it's harmless, but also useless). Remove it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI code currently disables TSC use in any C2 and C3
states. But the AMD Fam10h BKDG documents that the TSC
will never stop in any C states when the CONSTANT_TSC bit is
set. Make this disabling conditional on CONSTANT_TSC
not set on AMD.
I actually think this is true on Intel too for C2 states
on CPUs with p-state invariant TSC, but this needs
further discussions with Len to really confirm :-)
So far it is only enabled on AMD.
Cc: lenb@kernel.org
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Aviod TLB flush IPIs during C3 states by voluntary leave_mm()
before entering C3.
The performance impact of TLB flush on C3 should not be significant with
respect to C3 wakeup latency. Also, CPUs tend to flush TLB in hardware while in
C3 anyways.
On a 8 logical CPU system, running make -j2, the number of tlbflush IPIs goes
down from 40 per second to ~ 0. Total number of interrupts during the run
of this workload was ~1200 per second, which makes it ~3% savings in wakeups.
There was no measurable performance or power impact however.
[ akpm@linux-foundation.org: symbol export fixes. ]
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
All kobjects require a dynamically allocated name now. We no longer
need to keep track if the name is statically assigned, we can just
unconditionally free() all kobject names on cleanup.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stop using kobject_register for this static kobject, as it's overkill.
This way is much simpler.
Cc: Len Brown <len.brown@intel.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There is no firmware "subsystem" it's just a directory in /sys that
other portions of the kernel want to hook into. So make it a kobject
not a kset to help alivate anyone who tries to do some odd kset-like
things with this.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We don't need a kset here, a simple kobject will do just fine, so
dynamically create the kobject and use it.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We don't need a "default" ktype for a kset. We should set this
explicitly every time for each kset. This change is needed so that we
can make ksets dynamic, and cleans up one of the odd, undocumented
assumption that the kset/kobject/ktype model has.
This patch is based on a lot of help from Kay Sievers.
Nasty bug in the block code was found by Dave Young
<hidave.darkstar@gmail.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The "DEBUG" symbol needs to be defined before #including <linux/kernel.h> to
get the pr_debug() working.
Signed-off-by: Márton Németh <nm127@freemail.hu>
Signed-off-by: Len Brown <len.brown@intel.com>
Add leading zeros to pr_debug() calls. For example if x=0x0a, the format
"0x%2x" will result the string "0x a", the format "0x%2.2x" will result "0x0a".
Signed-off-by: Márton Németh <nm127@freemail.hu>
Signed-off-by: Len Brown <len.brown@intel.com>
This DMI blacklist reduces the console messages
on systems which have a BIOS that invokes OSI(Linux).
As the DMI blacklist already knows about these systems,
the request for DMI info itself is disabled.
Further, if OSI(Linux) has already been determined
to have no beneift, we disable the console message
requesting acpi_osi=Linux test results.
Signed-off-by: Len Brown <len.brown@intel.com>
If BIOS invokes _OSI(Linux), the kernel response
depends on what the ACPI DMI list knows about the system,
and that is reflectd in dmesg:
1) System unknown to DMI:
ACPI: BIOS _OSI(Linux) query ignored
ACPI: DMI System Vendor: LENOVO
ACPI: DMI Product Name: 7661W1P
ACPI: DMI Product Version: ThinkPad T61
ACPI: DMI Board Name: 7661W1P
ACPI: DMI BIOS Vendor: LENOVO
ACPI: DMI BIOS Date: 10/18/2007
ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
2) System known to DMI, but effect of OSI(Linux) unknown:
ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
3) System known to DMI, which disables _OSI(Linux):
ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI
4) System known to DMI, which enable _OSI(Linux):
ACPI: DMI detected: Lenovo ThinkPad T61
ACPI: Added _OSI(Linux)
...
ACPI: BIOS _OSI(Linux) query honored via DMI
cmdline overrides take precidence over the built-in
default and the DMI prescribed default.
cmdline "acpi_osi=Linux" results in:
ACPI: BIOS _OSI(Linux) query honored via cmdline
Signed-off-by: Len Brown <len.brown@intel.com>
Linux does not want BIOS writers to invoke _OSI(Linux) -
for in the field it causes more Windows incompatibility problems
than it solves.
So when it is seen in the BIOS for an Intel Customer Reference Board,
Linux should ignore its effect by default, and should complain loudly.
Otherwise, the reference BIOS will go unfixed, and the bad BIOS
will spread to the field.
Users of this board can get the old behavior with "acpi_osi=Linux"
As this was the only entry, delete acpi_osl_dmi_table[].
Signed-off-by: Len Brown <len.brown@intel.com>
The callback function acpi_ns_get_device_callback called from
acpi_get_devices() will check CID's if the HID does not match. This code
has a bug where it requires that all CIDs match the HID. Changed the code
so that any CID match will do.
Signed-off-by: Andrew Patterson <andrew.patterson@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
According to http://bugzilla.kernel.org/show_bug.cgi?id=6933
The latest BIOS for the P2B-S works fine.
Remove it from the blacklist.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix acpi_pm_device_sleep_state() to return the value returned
by _SxD if the device is supposed to wake up the system from
given sleep state and the evaluation of _SxW fails (e.g. _SxW
is not present).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI and APM used "pm_active" to guarantee that
they would not be simultaneously active.
But pm_active was recently moved under CONFIG_PM_LEGACY,
so that without CONFIG_PM_LEGACY, pm_active became a NOP --
allowing ACPI and APM to both be simultaneously enabled.
This caused unpredictable results, including boot hangs.
Further, the code under CONFIG_PM_LEGACY is scheduled
for removal.
So replace pm_active with pm_flags.
pm_flags depends only on CONFIG_PM,
which is present for both CONFIG_APM and CONFIG_ACPI.
http://bugzilla.kernel.org/show_bug.cgi?id=9194
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
When PCI IDE controller works in legacy mode and no PRT entry is found
in ACPI PRT table, OSPM will neither read the irq number from the IDE
PCI configuration space nor call the function of acpi_register_gsi to
register gsi.
http://bugzilla.kernel.org/show_bug.cgi?id=5637
Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Burst mode temporary (50 ms) locks EC to do only transactions with
driver, without it some hardware returns abstract garbage.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Specification allows only byte access for EC region, so
make it separate from bug-compatible multi-byte access.
Also do not allow return of garbage in supplied *value.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI Exception (acpi_processor-0677): AE_NOT_FOUND, Processor Device is not
present [20060707]
According to the ACPI spec 6.3.7,
"If a device object (including the processor object) does not have an
_STA object, then OSPM assumes that all of the above bits are set,
(in other words, the device is present, enabled, shown in the UI
and funtioning)".
is_processor_present shoud return 1 if the processor device object exists
while it doesn't have an _STA object.
http://bugzilla.kernel.org/show_bug.cgi?id=8570
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This was writeable in 2.6.23 but the cpuidle merge made it read-only. But
some people's scripts (ie: Mark's) were writing to it.
As an unhappy compromise, make max_cstate writeable again if the kernel was
configured without CONFIG_CPU_IDLE.
http://bugzilla.kernel.org/show_bug.cgi?id=9683
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Mark Lord <lkml@rtr.ca>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Some _STA methods called during bus_scan() might require EC region handler,
which might be enabled later in the scan.
Enable it explicitly before scan to avoid errors.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9627
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
There have been fixes using _PPC, which seem to unhide a problem
on HP nx6125 (double cpufreq switch freezes the machine for
several seconds).
This one should provide a workaround for the nx6125 and for
possible other machines that show any weird _PPC behaviour.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
/proc/acpi/alarm can't be set correctly, here is a sample:
[root@localhost /]# echo "2006 09" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
2007-12-09 09:09:09
[root@localhost /]# echo "2006 04" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
2007-12-04 04:04:04
[root@localhost /]#
Obviously, it is wrong, it should consider it as an invalid input.
after this patch:
[root@localhost /]# echo "2008 09" > /proc/acpi/alarm
-bash: echo: write error: Invalid argument
[root@localhost /]#
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
In function acpi_system_write_alarm in file drivers/acpi/sleep/proc.c,
big sec, min, hr, mo, day and yr are counted twice to get reasonable
values, that is very superfluous, we can do that only once.
In additon, /proc/acpi/alarm can set a related value which can be
specified as YYYY years MM months DD days HH hours MM minutes SS
senconds, it isn't a date, so you can specify as +0000-00-00 96:00:00
, that means 3 days later, current code can't handle such a case.
This patch removes unnecessary code and does with the aforementioned
situation.
Before applying this patch:
[root@localhost /]# cat /proc/acpi/alarm
2007-12-00 00:00:00
[root@localhost /]# echo "0000-00-00 96:180:180" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
0007-12-02 **:**:**
[root@localhost /]#
After applying this patch:
[root@localhost ~]# echo "2007-12-00 00:00:00" > /proc/acpi/alarm
[root@localhost ~]# cat /proc/acpi/alarm
2007-12-00 00:00:00
[root@localhost ~]# echo "0000-00-00 96:180:180" > /proc/acpi/alarm
[root@localhost ~]# cat /proc/acpi/alarm
0007-12-04 03:03:00
[root@localhost ~]#
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
klaptopd assumes rate to be in same units as capacity.
http://bugzilla.kernel.org/show_bug.cgi?id=9362
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Alarm bit should be cleared in order for other alarms to be sent.
http://bugzilla.kernel.org/show_bug.cgi?id=9362
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI tables follow a tree structure in memory.
The root of the tree is the RSDP (Root System Description Pointer).
To find the RSDP, the OS searches for the signature "RSD PTR "
in well known physical memory locations. Then the OS computes
a table checksum to verify that the signature is really part
of a valid table header.
Some systems have a proper signature but an invalid checksum;
followed elsewhere by a proper signature with valid checksum.
http://bugzilla.kernel.org/show_bug.cgi?id=9444
The Linux RSDP scanning code bailed out on those systems
and as a result they booted with ACPI disabled.
Fix this by deleting the Linux RSDP scanning code and
plugging in the ACPICA RSDP scanning code.
Signed-off-by: Len Brown <len.brown@intel.com>
More aggressively request deep C-states.
Note that the job of the OS is to minimize latency
impact to expected break events such as interrupts.
It is not the job of the OS to try to calculate if
the C-state will reach energy break-even.
The platform doesn't give the OS enough information
for it to make that calculation. Thus, it is up
to the platform to decide if it is worth it to
go as deep as the OS requested it to, or if it
should internally demote to a more shallow C-state.
But the converse is not true. The platform can not
promote into a deeper C-state than the OS requested
else it may violate latency constraints. So it is
important that the OS be aggressive in giving the
platform permission to enter deep C-states.
Signed-off-by: Len Brown <len.brown@intel.com>
for sn2_defconfig:
WARNING: vmlinux.o(.text+0x4b8601): Section mismatch: reference to .init.data:node_to_pxm_map (between '__acpi_map_pxm_to_node' and 'acpi_get_pxm')
WARNING: vmlinux.o(.text+0x4b8741): Section mismatch: reference to .init.data:pxm_to_node_map (between 'acpi_map_pxm_to_node' and 'acpi_get_node')
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Len Brown <len.brown@intel.com>
.. as it it used only during early boot.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
arch/ia64/kernel/acpi.c | 2 +-
arch/x86/kernel/acpi/boot.c | 4 ++--
drivers/acpi/osl.c | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
Signed-off-by: Len Brown <len.brown@intel.com>
The ->cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
list_head fields. This resulted in silent corruption without
CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
the proper bounds to the memset() calls and thereby correct the bugs.
Signed-off-by: William Irwin <wli@holomorphy.com>
Acked-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Len Brown <len.brown@intel.com>
References: https://bugzilla.novell.com/show_bug.cgi?id=302482
Signed-off-by: Thomas Renninger <trenn@novell.com>
Signed-off-by: Kay Sievers <kasievers@novell.com>
Signed-off-by: Frank Seidel <fseidel@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
References: https://bugzilla.novell.com/show_bug.cgi?id=302482
Due to the new autloading of acpi drivers, the dock driver
wasn't loaded anymore as there is no HID to identify it with
(dock is needed if ACPI has a _DCK method).
This patch is a workaround for this, original by Thomas Renninger,
revised first by Kay Sievers and last by Frank Seidel.
V2 of this patch fixed problems on systems without a defined _CID for
the docking devices.
Signed-off-by: Thomas Renninger <trenn@novell.com>
Signed-off-by: Kay Sievers <kasievers@novell.com>
Signed-off-by: Frank Seidel <fseidel@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
The timer broadcast code might access HPET, which should not be
accessed after the busmaster disable.
In acpi_idle_enter_simple() this change also prevents, that we modify
the busmaster state without going actually idle. This might leave the
ACPI bm state in a stale state, when we leave the function early in
the need_resched() check.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
module parameter is used to prevent the thermal_zone action upon
critical trip points.
But exporting this notification to userspace is still useful.
By setting nocrt with this patch applied, ACPI will take no action
but exporting the events to userspace upon critical/hot trip points.
http://bugzilla.kernel.org/show_bug.cgi?id=9139
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
At least some systems report technology information with trailing spaces:
{pts/1}% cat -E /var/tmp/bat/2.6.23 | grep type
battery type: Li-ION $
Use strncasecmp to compare model string to skip trailing part
Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Level GPE should not be enabled until all work caused by it is done,
e.g. all Notify() methods are completed.
This can be accomplished by appending enable_gpe function to the end
of notify queue.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Changed resolution of named references in packages
Fixed a problem with the Package operator where all named
references were created as object references and left otherwise
unresolved. According to the ACPI specification, a Package can
only contain Data Objects or references to control methods. The
implication is that named references to Data Objects (Integer,
Buffer, String, Package, BufferField, Field) should be resolved
immediately upon package creation. This is the approach taken
with this change. References to all other named objects (Methods,
Devices, Scopes, etc.) are all now properly created as reference objects.
http://bugzilla.kernel.org/show_bug.cgi?id=5328http://bugzilla.kernel.org/show_bug.cgi?id=9429
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The IRQ operation(enable/disable) should be avoided when throttling is
controlled via PTC method. It is replaced by the migration of task.
This fixes an oops on T61 -- a regression due to
f79f06ab9f b/c FixedHW support tried to read remote MSR with interrupts disabled.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI uses NR_CPUS in various loops and in some it accesses per cpu data of
processors that are not present(!) and that will never be present.
The pointers to per cpu data are typically not initialized for processors
that are not present. So we seem to be reading something here from offset
0 in memory.
Make ACPI use nr_cpu_ids instead. That stops at the end of the possible
processors.
Convert one loop to NR_CPUS to use the cpu_possible map instead. That way
ranges of processor that can never be brought online are skipped during the
loop.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Cc: Len Brown <lenb@kernel.org>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
x86: fix APIC related bootup crash on Athlon XP CPUs
time: add ADJ_OFFSET_SS_READ
x86: export the symbol empty_zero_page on the 32-bit x86 architecture
x86: fix kprobes_64.c inlining borkage
pci: use pci=bfsort for HP DL385 G2, DL585 G2
x86: correctly set UTS_MACHINE for "make ARCH=x86"
lockdep: annotate do_debug() trap handler
x86: turn off iommu merge by default
x86: fix ACPI compile for LOCAL_APIC=n
x86: printk kernel version in WARN_ON and other dump_stack users
ACPI: Set max_cstate to 1 for early Opterons.
x86: fix NMI watchdog & 'stopped time' problem
AMD Opteron processors before CG revision don't like C-states > 1.
This solves the long standing bugzilla #5303 and probably some more
on affected machines:
http://bugzilla.kernel.org/show_bug.cgi?id=5303
[ tglx@linutronix.de: reworked the patch so it does not wreck ia64 ]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Some controllers fail to send confirmation GPE after address or data write.
Detect this and don't expect such confirmation in future.
This is a generalization of previous workaround
(66c5f4e736), which did only read address.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9327
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
Tested-by: Mats Johannesson
Signed-off-by: Len Brown <len.brown@intel.com>
Sometimes it is usefull to see raw protocol dump.
Uncomment '#define DEBUG' at the beginning of file to make EC
really verbose.
Signed-off-by: Márton Németh <nm127@freemail.hu>
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
In cases where acpi_pci_bind() does not
attach device data, acpi_pci_unbind()
complains via an ACPI exception about the missing data when
the device is removed. For example, acpi_pci_bind() does not
attach data for non-existent device functions so when the device
is removed using the ACPI PCI hotplug driver 'acpiphp' an ACPI
exception is logged for every non-existent function. This patch
avoids the confusing log messages by removing the unnecessary
ACPI exception.
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
GPEs are disabled depending on their type --
WAKE, WAKE_RUN, and RUNTIME. An error is returned
if we are asked to disable a GPE that has no type.
But at least one system exists that enables a GPE from AML
that is not the EC GPE, and has no _Lxx/_Exx AML handler,
and is thus never initialized.
In this case, when an external CRT is plugged in,
the GPE fires, we attempt to disable the GPE,
but instead just return an error.
So the GPE stays asserted and an ACPI interrupt storm follows.
The fix is to disable a firing GPE,
even if it comes from outer space.
http://bugzilla.kernel.org/show_bug.cgi?id=6217
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=9355
cpuidle always used to fallback to C2 if there is some bm activity while
entering C3. But, presence of C2 is not always guaranteed. Change cpuidle
algorithm to detect a safe_state to fallback in case of bm_activity and
use that state instead of C2.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Port 2aa44d0567
(sched: sched_clock_idle_[sleep|wakeup]_event()) to cpuidle.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Port 18eab85503
(Enable C3 even when PM2_control is zero) to cpuidle.
Without this patch, some systems will notice a regression
when enabling CPU_IDLE -- C3 would no longer be available.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add debug tracing support during certain AML method execution.
Four more module parameters are created under /sys/module/acpi/parameters/:
trace_method_name: the AML method name that user wants to trace
trace_debug_layer: the temporary debug_layer used when tracing the method.
Using 0xffffffff by default if it is 0.
trace_debug_level: the temporary debug_level used when tracing the method.
Using 0x00ffffff by default if it is 0.
trace_state: The status of the tracing feature.
"enabled" means this feature is enabled
and the AML method is traced every time it's executed.
"1" means this feature is enabled and the AML method
will only be traced during the next execution.
"disabled" means this feature is disabled.
Users can enable/disable this debug tracing feature by
"echo string > /sys/module/acpi/parameters/trace_state".
"string" should be one of "enable", "disable" and "1".
http://bugzilla.kernel.org/show_bug.cgi?id=6629
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Introduce new ACPI_PROCFS_POWER (default Yes) config option and move
procfs code in battery, ac, and sbs drivers under it.
This is done to allow ACPI_PROCFS to be default No.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
In order to be able to write the value "100"
to /proc/acpi/video/.../brightness, we have to allocate 5 bytes:
4 characters will be written (1, 0, 0 plus null byte),
and 1 byte should be buffer for a terminating NULL character.
http://bugzilla.kernel.org/show_bug.cgi?id=9278
Signed-off-by: Danny Baumann <dannybaumann@web.de>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Some controllers fail to send confirmation GPE after address write.
Detect this and don't expect such confirmation in future.
This is a generalization of previous workaround
(66c5f4e736), which did only read address.
http://bugzilla.kernel.org/show_bug.cgi?id=9327
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
drivers/acpi/sbs.c: In function acpi_battery_add:
drivers/acpi/sbs.c:811: warning: ignoring return value of device_create_file,
declared with attribute warn_unused_result
Additional cleanups:
* use struct acpi_battery in acpi_battery_remove() to clean up function
calls, just like acpi_battery_add() already does.
* put braces around unregister call, as it depends on dev being not NULL.
* remove unneeded braces
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Add throttling control via MSR when T-states uses
the FixHW Control Status registers.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Previously _PDC was evaluated later, and thus we'd not get
the chance to tell the BIOS that we can suport FixedHW registers (MSRs)
and the BIOS would always ask us to use System I/O access
for throttling.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
_TSS was erroneously ignored, in favor of the FADT.
When TSS is used, the access width is included in the PTC control/status
register. So it is unnecessary that the access bit width is multiplied by 8.
At the same time the bit_offset should be considered for system I/O Access.
It should be checked the bit_width and bit_offset of PTC regsiter in order to
avoid the failure of system I/O access. It means that bit_width plus
bit_offset can't be greater than 32.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Change the function interface for throttling control via PTC.
The following functions are concerned:
acpi_read_throttling_status()
acpi_write_throttling_state()
acpi_get_throttling_value()
acpi_get_throttling_state()
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Factor out legacy FADT.duty_width code
and run it only in the non _TSS case.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We've run into BIOS that hand us 4-bit access width requests
for T-state control when the code expected only multipls of 8-bits.
Round up.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When a T-state limit change notification is received,
Linux must evaluate _TPC and change its current
T-state immediately to comply with the new limit.
Previously, Linux would notice the new limit
only upon the next throttling change.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Check if AC state has changed across resume and notify userspace if so.
Fixes "[2.6.24-rc1 regression] AC adapter state does not change after resume"
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Andrey Borzenkov <arvidjaar@mail.ru>
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>
Do not provide /proc/acpi/ac_adapter if ACPI_PROCFS is not defined. This
eliminates duplicated power adapters in HAL and makes it consistent with
battery module
Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Zillions of people are getting my-battery-monitor-doesnt-work problems
(including me).
Lessen the damage by making ACPI_PROCFS default to on.
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
list_for_each_safe() only protects list from list alterations
performed by the same thread. One still needs to implement
proper locking when list is being accessed from several threads.
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>
If input_register_device() fails input_free_device() must
be called to release memory allocated for the device.
Also consolidate error handling in acpi_bus_video_add()
and handle input_allocate_device() failures.
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>
Properly set up parent on input device registered by the video driver.
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>
get_property() should not call battery_update(), it also should call
get_status() only if battery is present to avoid cycle and oops.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Acked-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add documentation in Kconfig help about the move of /proc/acpi/battery
to /sys/class/power_supply when selecting ACPI_PROCFS. This will impact
a lot of users and should be documented.
Signed-off-by: Jerome Pinot <ngc891@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If a battery is at a critical charge level and not being charged or
discharged, then the ACPI _BST method will return a state of 4, and
the current acpi_battery_get_property() code will not set any property
value for POWER_SUPPLY_PROP_STATUS. This will cause an oops in
power_supply_show_property() when it reads off the end of the
status_text array. This actually was causing a 100% reproducible
crash on boot on my laptop with two batteries, when one battery was
completely drained and the laptop was not plugged in.
Fix this by making sure acpi_battery_get_property() returns
POWER_SUPPLY_STATUS_UNKNOWN for any battery state it doesn't already
handle explicitly. There doesn't seem to be any status enum value
defined that makes more sense than 'unknown' for a battery at a
critical charge level.
Signed-off-by: Roland Dreier <roland@digitalvampire.org>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <lenb@t61.(none)>
Current description for CONFIG_ACPI includes the word "Support" twice. One
effect of this is that in menuconfig the "--->" that indicates the presence
of sub-options will not show up unless you have a very wide console.
Signed-off-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
POWER_SUPPLY is needed for AC, battery, and SBS sysfs support. Use
'select' instead of 'depends on', as it is will not be selected by anything
else, leading to confusion.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Some machines return integer instead of expected string.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Andrey Borzenkov <arvidjaar@mail.ru>
Tested-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Len Brown <len.brown@intel.com>
Support Li-Ion as possible name for technology.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Make sure no power_supply object is present unless we actualy detect
presence of battery. This fixes ghost batteries detected by HAL
Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This fixes some totally illogical and wrong code that converts things to
and from BCD mode essentially randomly, does math on values in BCD mode
etc etc. Introduce a few helper functions to make it a bit more obvious
what is going on, and make sure that we always do all the arithmetic
(and anythign else, for that matter) in binary, not BCD.
Tested by Mark Lord, who found the problem originally, and also pushed
the patch back and reminded me about it.
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
