- 15 7月, 2013 1 次提交
-
-
由 Jiang Liu 提交于
Introduce helper function acpi_execute_simple_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: NJiang Liu <jiang.liu@huawei.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 26 4月, 2013 1 次提交
-
-
由 Zhang Rui 提交于
Commit 4ae46bef "Thermal: Introduce thermal_zone_trip_update()" introduced a regression causing the fan to be always on even when the system is idle. My original idea in that commit is that: - when the current temperature is above the trip point, keep the fan on, even if the temperature is dropping. - when the current temperature is below the trip point, turn on the fan when the temperature is raising, turn off the fan when the temperature is dropping. But this is what the code actually does: - when the current temperature is above the trip point, the fan keeps on. - when the current temperature is below the trip point, the fan is always on because thermal_get_trend() in driver/acpi/thermal.c returns THERMAL_TREND_RAISING. Thus the fan keeps running even if the system is idle. Fix this in drivers/acpi/thermal.c. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=56591 References: https://bugzilla.kernel.org/show_bug.cgi?id=56601 References: https://bugzilla.kernel.org/show_bug.cgi?id=50041#c45Signed-off-by: NZhang Rui <rui.zhang@intel.com> Tested-by: NMatthias <morpheusxyz123@yahoo.de> Tested-by: NVille Syrjälä <syrjala@sci.fi> Cc: 3.7+ <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 26 1月, 2013 3 次提交
-
-
由 Rafael J. Wysocki 提交于
The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NJiang Liu <jiang.liu@huawei.com> Acked-by: NToshi Kani <toshi.kani@hp.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Srinivas Pandruvada 提交于
As per documentation, "mode" sysfs interface should be able to enable/disable thermal processing in the kernel, so that user space is able to take more control. Currently, ACPI thermal driver is not following this setting, so modify it to match the interface documentation. Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Colin Ian King 提交于
ACPI_EXCEPTION() already appends a newline, so there is no need for the thermal trip point message to include one too. Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 11月, 2012 1 次提交
-
-
由 Zhang Rui 提交于
On some platforms, _TMP and _CRT/_HOT/_PSV/_ACx have dependency. And there is no way for OS to detect this dependency. commit 9bcb8118 shows us a problem that _TMP must be evaluate after _CRT/_HOT/_PSV/_ACx, or else firmware will shutdown the system. But the machine in https://bugzilla.kernel.org/show_bug.cgi?id=43284 shows us that _PSV would return valid value only if _TMP has been evaluated once. With this patch, all of the control methods will be evaluated once, in the _CRT/_HOT/_PSV/_CRT/_TMP order, before they are actually used. [rjw: Added a local variable for the handle and modified the loop slightly.] Signed-off-by: NZhang Rui <rui.zhang@intel.com> Tested-by: Nkatabami <katabami@lavabit.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 05 11月, 2012 1 次提交
-
-
由 Durgadoss R 提交于
This patch adds the thermal zone parameter as an argument to the tzd_register() function call; and updates other drivers using this function. Signed-off-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 24 9月, 2012 4 次提交
-
-
由 Zhang Rui 提交于
This function is used to update the cooling state of all the cooling devices that are bound to an active trip point. This will be used for passive cooling as well, in the future patches. as both active and passive cooling can share the same algorithm, which is 1. if the temperature is higher than a trip point, a. if the trend is THERMAL_TREND_RAISING, use higher cooling state for this trip point b. if the trend is THERMAL_TREND_DROPPING, use lower cooling state for this trip point 2. if the temperature is lower than a trip point, use lower cooling state for this trip point. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl> Reviewed-by: NEduardo Valentin <eduardo.valentin@ti.com>
-
由 Zhang Rui 提交于
Remove tc1/tc2 in generic thermal layer. .get_trend() callback starts to take effect from this patch. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl> Reviewed-by: NValentin, Eduardo <eduardo.valentin@ti.com>
-
由 Zhang Rui 提交于
According to ACPI spec, tc1 and tc2 are used by OSPM to anticipate the temperature trends. We introduced the same concept to the generic thermal layer for passive cooling, but now it seems that these values are hard to be used on other platforms. So We introduce .get_trend() as a more general solution. For the platform thermal drivers that have their own way to anticipate the temperature trends, they should provide their own .get_trend() callback. Or else, we will calculate the temperature trends by simply comparing the current temperature and the cached previous temperature reading. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl> Reviewed-by: NValentin, Eduardo <eduardo.valentin@ti.com>
-
由 Zhang Rui 提交于
set upper and lower limits when binding a thermal cooling device to a thermal zone device. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl> Reviewed-by: NEduardo Valentin <eduardo.valentin@ti.com>
-
- 10 8月, 2012 1 次提交
-
-
由 Rafael J. Wysocki 提交于
According to compiler warnings, several suspend/resume functions in ACPI drivers are not used for CONFIG_PM_SLEEP unset, so add #ifdefs to prevent them from being built in that case. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 25 7月, 2012 2 次提交
-
-
由 Zhang Rui 提交于
With commit 6503e5df, the value of /sys/class/thermal/thermal_zoneX/mode has been changed from user/kernel to enabled/disabled. Update the documentation so that users won't be confused. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Durgadoss R 提交于
Some of the thermal drivers using the Generic Thermal Framework require (all/some) trip points to be writeable. This patch makes the trip point temperatures writeable on a per-trip point basis, and modifies the required function call in thermal.c. This patch also updates the Documentation to reflect the new change. Signed-off-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 01 7月, 2012 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Make the ACPI thermal driver define its PM callbacks through a struct dev_pm_ops object rather than by using legacy PM hooks in struct acpi_device_ops. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 30 3月, 2012 1 次提交
-
-
由 Matthew Garrett 提交于
An HP laptop (Pavilion G4-1016tx) has the following code in _TMP: Store (\_SB.PCI0.LPCB.EC0.RTMP, Local0) If (LGreaterEqual (Local0, S4TP)) { Store (One, HTS4) } S4TP is initialised at 0 and not programmed further until either _HOT or _CRT is called. If we evaluate _TMP before the trip points then HTS4 will always be set, causing the firmware to generate a message on boot complaining that the system shut down because of overheating. The simplest solution is just to reverse the checking of trip points and _TMP in thermal init. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 7月, 2011 1 次提交
-
-
由 Vasiliy Kulikov 提交于
Structs battery_file, acpi_dock_ops, file_operations, thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops are not changed in runtime. It is safe to make them const. register_hotplug_dock_device() was altered to take const "ops" argument to respect acpi_dock_ops' const notion. Signed-off-by: NVasiliy Kulikov <segoon@openwall.com> Acked-by: NJeff Garzik <jgarzik@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 12 1月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Use the new function acpi_bus_update_power() for manipulating power resources used by ACPI fan devices, which allows them to be put into the right state during initialization and resume. Consequently, remove the flags.force_power_state field from struct acpi_device, which is not necessary any more. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 10月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
Remove the deprecated ACPI thermal driver procfs I/F, as stated in the changelog of commit 43d9f87b sysfs I/F is available at /sys/class/thermal/thermal_zoneX/ Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 15 8月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
Mark the ACPI thermal procfs I/F deprecated, because /sys/class/thermal/ is already available and has been working for years w/o any problem. The ACPI thermal procfs I/F will be removed in 2.6.37. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 23 2月, 2010 1 次提交
-
-
由 Thomas Renninger 提交于
V2: Corrected integer/long conversion. Some BIOSes return a negative value for the critical trip point. Especially since Windows 2006... We currently invalidate the whole thermal zone in this case. But it may still be needed for cooling, also without critical trip point. This patch invalidates the critical trip point if no _CRT function is found or if it returns negative values, but does not invalidate the whole thermal zone in this case. Reference: http://bugzilla.novell.com/show_bug.cgi?id=531547Signed-off-by: NThomas Renninger <trenn@suse.de> Tested-by: clarkt@cnsp.com Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 19 2月, 2010 1 次提交
-
-
由 Thomas Renninger 提交于
ACPI spec says (11.5 Thermal Zone Interface Requirements): A thermal zone must contain at least one trip point (critical, near critical, active, or passive) Check this once at init time. Signed-off-by: NThomas Renninger <trenn@suse.de> Tested-by: clarkt@cnsp.com Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 12月, 2009 1 次提交
-
-
由 Frans Pop 提交于
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: NFrans Pop <elendil@planet.nl> Acked-by: NZhang Rui <rui.zhang@intel.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 06 11月, 2009 1 次提交
-
-
由 Frans Pop 提交于
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: NFrans Pop <elendil@planet.nl> Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 29 8月, 2009 1 次提交
-
-
由 Len Brown 提交于
Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 18 4月, 2009 1 次提交
-
-
由 Matthew Garrett 提交于
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: NMatthew Garrett <mjg@redhat.com> Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 08 4月, 2009 1 次提交
-
-
由 Bjorn Helgaas 提交于
This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> CC: Zhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 07 4月, 2009 1 次提交
-
-
由 Jean Delvare 提交于
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: NJean Delvare <khali@linux-fr.org> Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 31 3月, 2009 1 次提交
-
-
由 Alexey Dobriyan 提交于
Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy as correctly noted at bug #12454. Someone can lookup entry with NULL ->owner, thus not pinning enything, and release it later resulting in module refcount underflow. We can keep ->owner and supply it at registration time like ->proc_fops and ->data. But this leaves ->owner as easy-manipulative field (just one C assignment) and somebody will forget to unpin previous/pin current module when switching ->owner. ->proc_fops is declared as "const" which should give some thoughts. ->read_proc/->write_proc were just fixed to not require ->owner for protection. rmmod'ed directories will be empty and return "." and ".." -- no harm. And directories with tricky enough readdir and lookup shouldn't be modular. We definitely don't want such modular code. Removing ->owner will also make PDE smaller. So, let's nuke it. Kudos to Jeff Layton for reminding about this, let's say, oversight. http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
-
- 30 3月, 2009 1 次提交
-
-
由 Adam Buchbinder 提交于
A few comments say "Celcius"; this fixes them. No code changes. Signed-off-by: NAdam Buchbinder <adam.buchbinder@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 28 3月, 2009 1 次提交
-
-
由 Stephen Rothwell 提交于
> 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 b1569e99 ("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: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 21 2月, 2009 1 次提交
-
-
由 Matthew Garrett 提交于
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: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 2月, 2009 1 次提交
-
-
由 Matthew Garrett 提交于
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: NMatthew Garrett <mjg@redhat.com> Acked-by: NZhang Rui <rui.zhang@intel.com> Acked-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 1月, 2009 1 次提交
-
-
由 Zhang Rui 提交于
ACPI thermal driver only re-evaluate VALID trip points. For the broken BIOS show in http://bugzilla.kernel.org/show_bug.cgi?id=8544 the active[0] is set to invalid at boot time and it will not be re-evaluated again. We can still get a single warning message at boot time. http://marc.info/?l=linux-kernel&m=120496222629983&w=2 http://bugzilla.kernel.org/show_bug.cgi?id=12203 Signed-off-by: Zhang Rui<rui.zhang@intel.com> Tested-by: NMárton Németh <nm127@freemail.hu> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 08 11月, 2008 1 次提交
-
-
由 Bjorn Helgaas 提交于
Move all the component definitions for drivers to a single shared place, include/acpi/acpi_drivers.h. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 07 11月, 2008 1 次提交
-
-
由 Kay Sievers 提交于
This patch is part of a larger patch series which will remove the "char bus_id[20]" name string from struct device. The device name is managed in the kobject anyway, and without any size limitation, and just needlessly copied into "struct device". To set and read the device name dev_name(dev) and dev_set_name(dev) must be used. If your code uses static kobjects, which it shouldn't do, "const char *init_name" can be used to statically provide the name the registered device should have. At registration time, the init_name field is cleared, to enforce the use of dev_name(dev) to access the device name at a later time. We need to get rid of all occurrences of bus_id in the entire tree to be able to enable the new interface. Please apply this patch, and possibly convert any remaining remaining occurrences of bus_id. We want to submit a patch to -next, which will remove bus_id from "struct device", to find the remaining pieces to convert, and finally switch over to the new api, which will remove the 20 bytes array and does no longer have a size limitation. Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 23 10月, 2008 1 次提交
-
-
由 Lin Ming 提交于
ACPI_DB_ERROR and ACPI_DB_WARN were removed from ACPICA core. So replace ACPI_DEBUG_PRINT((ACPI_DB_ERROR, ...) with printk(KERN_ERR PREFIX ...) and ACPI_DEBUG_PRINT((ACPI_DB_WARN, ...) with printk(KERN_WARNING PREFIX ...) We do not use ACPI_ERROR/ACPI_WARNING since they're not exported, see ------------------------------------------------------------- commit 6468463a Author: Len Brown <len.brown@intel.com> Date: Mon Jun 26 23:41:38 2006 -0400 ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...) Signed-off-by: NLen Brown <len.brown@intel.com> ------------------------------------------------------------- Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 10月, 2008 1 次提交
-
-
由 Zhang Rui 提交于
http://bugzilla.kernel.org/show_bug.cgi?id=9129 lenb: Note that overriding a critical trip point may simply fool the user into thinking that they have control that they do not actually have. For it is EC firmware that decides when the EC sends Linux temperature change events, and the EC may or may not decide to send Linux these events anywhere in the neighborhood of the fake override trip points. Beware. note also that thermal.nocrt is already available to disable crtical trip point actios, and thermal.crt=-1 is already available to disabled critical trip points entirely. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 11 10月, 2008 1 次提交
-
-
由 Matthew Wilcox 提交于
As of version 2.0, ACPI can return 64-bit integers. The current acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms. Change the argument to take a pointer to an acpi_integer so we support 64-bit integers on all platforms. lenb: replaced use of "acpi_integer" with "unsigned long long" lenb: fixed bug in acpi_thermal_trips_update() Signed-off-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-