linux/drivers/acpi/fan_core.c

464 lines
11 KiB
C
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-27 14:55:06 +08:00
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* fan_core.c - ACPI Fan core Driver
*
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
* Copyright (C) 2022 Intel Corporation. All rights reserved.
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/uaccess.h>
#include <linux/thermal.h>
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-03 08:49:16 +08:00
#include <linux/acpi.h>
#include <linux/platform_device.h>
#include <linux/sort.h>
#include "fan.h"
static const struct acpi_device_id fan_device_ids[] = {
ACPI_FAN_DEVICE_IDS,
{"", 0},
};
MODULE_DEVICE_TABLE(acpi, fan_device_ids);
/* thermal cooling device callbacks */
static int fan_get_max_state(struct thermal_cooling_device *cdev, unsigned long
*state)
{
struct acpi_device *device = cdev->devdata;
struct acpi_fan *fan = acpi_driver_data(device);
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
if (fan->acpi4) {
if (fan->fif.fine_grain_ctrl)
*state = 100 / fan->fif.step_size;
else
*state = fan->fps_count - 1;
} else {
*state = 1;
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
}
return 0;
}
int acpi_fan_get_fst(struct acpi_device *device, struct acpi_fan_fst *fst)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_status status;
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
int ret = 0;
status = acpi_evaluate_object(device->handle, "_FST", NULL, &buffer);
if (ACPI_FAILURE(status)) {
dev_err(&device->dev, "Get fan state failed\n");
return -ENODEV;
}
obj = buffer.pointer;
if (!obj || obj->type != ACPI_TYPE_PACKAGE ||
obj->package.count != 3 ||
obj->package.elements[1].type != ACPI_TYPE_INTEGER) {
dev_err(&device->dev, "Invalid _FST data\n");
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
ret = -EINVAL;
goto err;
}
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
fst->revision = obj->package.elements[0].integer.value;
fst->control = obj->package.elements[1].integer.value;
fst->speed = obj->package.elements[2].integer.value;
err:
kfree(obj);
return ret;
}
static int fan_get_state_acpi4(struct acpi_device *device, unsigned long *state)
{
struct acpi_fan *fan = acpi_driver_data(device);
struct acpi_fan_fst fst;
int status, i;
status = acpi_fan_get_fst(device, &fst);
if (status)
return status;
if (fan->fif.fine_grain_ctrl) {
/* This control should be same what we set using _FSL by spec */
if (fst.control > 100) {
dev_dbg(&device->dev, "Invalid control value returned\n");
goto match_fps;
}
*state = (int) fst.control / fan->fif.step_size;
return 0;
}
match_fps:
for (i = 0; i < fan->fps_count; i++) {
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
if (fst.control == fan->fps[i].control)
break;
}
if (i == fan->fps_count) {
dev_dbg(&device->dev, "Invalid control value returned\n");
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
return -EINVAL;
}
*state = i;
return status;
}
static int fan_get_state(struct acpi_device *device, unsigned long *state)
{
int result;
int acpi_state = ACPI_STATE_D0;
result = acpi_device_update_power(device, &acpi_state);
if (result)
return result;
ACPI / PM: Rework device power management to follow ACPI 6 The ACPI 6 specification has made some changes in the device power management area. In particular: * The D3hot power state is now supposed to be always available (instead of D3cold) and D3cold is only regarded as valid if the _PR3 object is present for the given device. * The required ordering of transitions into power states deeper than D0 is now such that for a transition into state Dx the _PSx method is supposed to be executed first, if present, and the states of the power resources the device depends on are supposed to be changed after that. * It is now explicitly forbidden to transition devices from lower-power (deeper) into higher-power (shallower) power states other than D0. Those changes have been made so the specification reflects the Windows' device power management code that the vast majority of systems using ACPI is validated against. To avoid artificial differences in ACPI device power management between Windows and Linux, modify the ACPI device power management code to follow the new specification. Add comments explaining the code flow in some unclear places. This only may affect some real corner cases in which the OS behavior expected by the firmware is different from the Windows one, but that's quite unlikely. The transition ordering change affects transitions to D1 and D2 which are rarely used (if at all) and into D3hot and D3cold for devices actually having _PR3, but those are likely to be validated against Windows anyway. The other changes may affect code calling acpi_device_get_power() or acpi_device_update_power() where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD (that's why the ACPI fan driver needs to be updated too) and since transitions into ACPI_STATE_D3_HOT may remove power now, it is better to avoid this one in acpi_pm_device_sleep_state() if the "no power off" PM QoS flag is set. The only existing user of acpi_device_can_poweroff() really cares about the case when _PR3 is present, so the change in that function should not cause any problems to happen too. A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT now and the compatibility with older systems should be covered automatically. In any case, if any real problems result from this, it still will be better to follow the Windows' behavior (which now is reflected by the specification too) in general and handle the cases when it doesn't work via quirks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-16 07:55:35 +08:00
*state = acpi_state == ACPI_STATE_D3_COLD
|| acpi_state == ACPI_STATE_D3_HOT ?
0 : (acpi_state == ACPI_STATE_D0 ? 1 : -1);
return 0;
}
static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long
*state)
{
struct acpi_device *device = cdev->devdata;
struct acpi_fan *fan = acpi_driver_data(device);
if (fan->acpi4)
return fan_get_state_acpi4(device, state);
else
return fan_get_state(device, state);
}
static int fan_set_state(struct acpi_device *device, unsigned long state)
{
if (state != 0 && state != 1)
return -EINVAL;
return acpi_device_set_power(device,
state ? ACPI_STATE_D0 : ACPI_STATE_D3_COLD);
}
static int fan_set_state_acpi4(struct acpi_device *device, unsigned long state)
{
struct acpi_fan *fan = acpi_driver_data(device);
acpi_status status;
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
u64 value = state;
int max_state;
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
if (fan->fif.fine_grain_ctrl)
max_state = 100 / fan->fif.step_size;
else
max_state = fan->fps_count - 1;
if (state > max_state)
return -EINVAL;
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
if (fan->fif.fine_grain_ctrl) {
value *= fan->fif.step_size;
/* Spec allows compensate the last step only */
if (value + fan->fif.step_size > 100)
value = 100;
} else {
value = fan->fps[state].control;
}
status = acpi_execute_simple_method(device->handle, "_FSL", value);
if (ACPI_FAILURE(status)) {
dev_dbg(&device->dev, "Failed to set state by _FSL\n");
return -ENODEV;
}
return 0;
}
static int
fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
{
struct acpi_device *device = cdev->devdata;
struct acpi_fan *fan = acpi_driver_data(device);
if (fan->acpi4)
return fan_set_state_acpi4(device, state);
else
return fan_set_state(device, state);
}
static const struct thermal_cooling_device_ops fan_cooling_ops = {
.get_max_state = fan_get_max_state,
.get_cur_state = fan_get_cur_state,
.set_cur_state = fan_set_cur_state,
};
/* --------------------------------------------------------------------------
* Driver Interface
* --------------------------------------------------------------------------
*/
static bool acpi_fan_is_acpi4(struct acpi_device *device)
{
return acpi_has_method(device->handle, "_FIF") &&
acpi_has_method(device->handle, "_FPS") &&
acpi_has_method(device->handle, "_FSL") &&
acpi_has_method(device->handle, "_FST");
}
static int acpi_fan_get_fif(struct acpi_device *device)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_fan *fan = acpi_driver_data(device);
struct acpi_buffer format = { sizeof("NNNN"), "NNNN" };
u64 fields[4];
struct acpi_buffer fif = { sizeof(fields), fields };
union acpi_object *obj;
acpi_status status;
status = acpi_evaluate_object(device->handle, "_FIF", NULL, &buffer);
if (ACPI_FAILURE(status))
return status;
obj = buffer.pointer;
if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
dev_err(&device->dev, "Invalid _FIF data\n");
status = -EINVAL;
goto err;
}
status = acpi_extract_package(obj, &format, &fif);
if (ACPI_FAILURE(status)) {
dev_err(&device->dev, "Invalid _FIF element\n");
status = -EINVAL;
goto err;
}
fan->fif.revision = fields[0];
fan->fif.fine_grain_ctrl = fields[1];
fan->fif.step_size = fields[2];
fan->fif.low_speed_notification = fields[3];
ACPI: fan: Properly handle fine grain control When _FIF object specifies support for fine grain control, then fan speed can be set from 0 to 100% with the recommended minimum "step size" via _FSL object. Here the control value doesn't need to match any value from _FPS object. Currently we have a simple solution implemented which just pick maximum control value from _FPS to display the actual state, but this is not optimal when there is a big window between two control values in _FPS. Also there is no way to set to any speed which doesn't match control values in _FPS. The system firmware can start the fan at speed which doesn't match any control value. To support fine grain control (when supported) via thermal sysfs: - cooling device max state is not _FPS state count but it will be 100 / _FIF.step_size Step size can be from 1 to 9. - cooling device current state is _FST.control / _FIF.step_size - cooling device set state will set the control value cdev.curr_state * _FIF.step_size plus any adjustment for 100%. By the spec, when control value do not sum to 100% because of _FIF.step_size, OSPM may select an appropriate ending Level increment to reach 100%. There is no rounding during calculation. For example if step size is 6: thermal sysfs cooling device max_state = 100/6 = 16 So user can set any value from 0-16. If the system boots with a _FST.control which is not multiples of step_size, the thermal sysfs cur_state will be based on the range. For example for step size = 6: _FST.control thermal sysfs cur_state ------------------------------------------------ 0-5 0 6-11 1 .. .. 90-95 15 96-100 16 While setting the _FST.control, the compensation will be at the last step for cur_state = 16, which will set the _FST.control to 100. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-12 07:27:42 +08:00
/* If there is a bug in step size and set as 0, change to 1 */
if (!fan->fif.step_size)
fan->fif.step_size = 1;
/* If step size > 9, change to 9 (by spec valid values 1-9) */
else if (fan->fif.step_size > 9)
fan->fif.step_size = 9;
err:
kfree(obj);
return status;
}
static int acpi_fan_speed_cmp(const void *a, const void *b)
{
const struct acpi_fan_fps *fps1 = a;
const struct acpi_fan_fps *fps2 = b;
return fps1->speed - fps2->speed;
}
static int acpi_fan_get_fps(struct acpi_device *device)
{
struct acpi_fan *fan = acpi_driver_data(device);
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_status status;
int i;
status = acpi_evaluate_object(device->handle, "_FPS", NULL, &buffer);
if (ACPI_FAILURE(status))
return status;
obj = buffer.pointer;
if (!obj || obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2) {
dev_err(&device->dev, "Invalid _FPS data\n");
status = -EINVAL;
goto err;
}
fan->fps_count = obj->package.count - 1; /* minus revision field */
treewide: devm_kzalloc() -> devm_kcalloc() The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc(). This patch replaces cases of: devm_kzalloc(handle, a * b, gfp) with: devm_kcalloc(handle, a * b, gfp) as well as handling cases of: devm_kzalloc(handle, a * b * c, gfp) with: devm_kzalloc(handle, array3_size(a, b, c), gfp) as it's slightly less ugly than: devm_kcalloc(handle, array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: devm_kzalloc(handle, 4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. Some manual whitespace fixes were needed in this patch, as Coccinelle really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...". The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ expression HANDLE; type TYPE; expression THING, E; @@ ( devm_kzalloc(HANDLE, - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | devm_kzalloc(HANDLE, - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression HANDLE; expression COUNT; typedef u8; typedef __u8; @@ ( devm_kzalloc(HANDLE, - sizeof(u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ expression HANDLE; type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ expression HANDLE; identifier SIZE, COUNT; @@ - devm_kzalloc + devm_kcalloc (HANDLE, - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression HANDLE; expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression HANDLE; expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ expression HANDLE; identifier STRIDE, SIZE, COUNT; @@ ( devm_kzalloc(HANDLE, - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression HANDLE; expression E1, E2, E3; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression HANDLE; expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, sizeof(THING) * C2, ...) | devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...) | devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, C1 * C2, ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * E2 + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * (E2) + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-13 05:07:58 +08:00
fan->fps = devm_kcalloc(&device->dev,
fan->fps_count, sizeof(struct acpi_fan_fps),
GFP_KERNEL);
if (!fan->fps) {
dev_err(&device->dev, "Not enough memory\n");
status = -ENOMEM;
goto err;
}
for (i = 0; i < fan->fps_count; i++) {
struct acpi_buffer format = { sizeof("NNNNN"), "NNNNN" };
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
struct acpi_buffer fps = { offsetof(struct acpi_fan_fps, name),
&fan->fps[i] };
status = acpi_extract_package(&obj->package.elements[i + 1],
&format, &fps);
if (ACPI_FAILURE(status)) {
dev_err(&device->dev, "Invalid _FPS element\n");
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
goto err;
}
}
/* sort the state array according to fan speed in increase order */
sort(fan->fps, fan->fps_count, sizeof(*fan->fps),
acpi_fan_speed_cmp, NULL);
err:
kfree(obj);
return status;
}
static int acpi_fan_probe(struct platform_device *pdev)
{
int result = 0;
struct thermal_cooling_device *cdev;
struct acpi_fan *fan;
struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
char *name;
fan = devm_kzalloc(&pdev->dev, sizeof(*fan), GFP_KERNEL);
if (!fan) {
dev_err(&device->dev, "No memory for fan\n");
return -ENOMEM;
}
device->driver_data = fan;
platform_set_drvdata(pdev, fan);
if (acpi_fan_is_acpi4(device)) {
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
result = acpi_fan_get_fif(device);
if (result)
return result;
result = acpi_fan_get_fps(device);
if (result)
return result;
result = devm_acpi_fan_create_hwmon(device);
if (result)
return result;
result = acpi_fan_create_attributes(device);
if (result)
return result;
fan->acpi4 = true;
} else {
result = acpi_device_update_power(device, NULL);
if (result) {
dev_err(&device->dev, "Failed to set initial power state\n");
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
goto err_end;
}
}
if (!strncmp(pdev->name, "PNP0C0B", strlen("PNP0C0B")))
name = "Fan";
else
name = acpi_device_bid(device);
cdev = thermal_cooling_device_register(name, device,
&fan_cooling_ops);
if (IS_ERR(cdev)) {
result = PTR_ERR(cdev);
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
goto err_end;
}
dev_dbg(&pdev->dev, "registered as cooling_device%d\n", cdev->id);
fan->cdev = cdev;
result = sysfs_create_link(&pdev->dev.kobj,
&cdev->device.kobj,
"thermal_cooling");
if (result)
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management updates from Zhang Rui: "Sorry that I missed the merge window as there is a bug found in the last minute, and I have to fix it and wait for the code to be tested in linux-next tree for a few days. Now the buggy patch has been dropped entirely from my next branch. Thus I hope those changes can still be merged in 3.18-rc2 as most of them are platform thermal driver changes. Specifics: - introduce ACPI INT340X thermal drivers. Newer laptops and tablets may have thermal sensors and other devices with thermal control capabilities that are exposed for the OS to use via the ACPI INT340x device objects. Several drivers are introduced to expose the temperature information and cooling ability from these objects to user-space via the normal thermal framework. From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui. - introduce a new thermal governor, which just uses a hysteresis to switch abruptly on/off a cooling device. This governor can be used to control certain fan devices that can not be throttled but just switched on or off. From: Peter Feuerer. - introduce support for some new thermal interrupt functions on i.MX6SX, in IMX thermal driver. From: Anson, Huang. - introduce tracing support on thermal framework. From: Punit Agrawal. - small fixes in OF thermal and thermal step_wise governor" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits) Thermal: int340x thermal: select ACPI fan driver Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs Thermal: int340x_thermal: expose acpi thermal relationship tables Thermal: introduce int3403 thermal driver Thermal: introduce INT3402 thermal driver Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h ACPI / Fan: support INT3404 thermal device ACPI / Fan: add ACPI 4.0 style fan support ACPI / fan: convert to platform driver ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant ACPI / fan: remove no need check for device pointer ACPI / fan: remove unused macro Thermal: int3400 thermal: register to thermal framework Thermal: int3400 thermal: add capability to detect supporting UUIDs Thermal: introduce int3400 thermal driver ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package() ACPI: make acpi_create_platform_device() an external API thermal: step_wise: fix: Prevent from binary overflow when trend is dropping ACPI: introduce ACPI int340x thermal scan handler thermal: Added Bang-bang thermal governor ...
2014-10-25 02:21:43 +08:00
dev_err(&pdev->dev, "Failed to create sysfs link 'thermal_cooling'\n");
result = sysfs_create_link(&cdev->device.kobj,
&pdev->dev.kobj,
"device");
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
if (result) {
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management updates from Zhang Rui: "Sorry that I missed the merge window as there is a bug found in the last minute, and I have to fix it and wait for the code to be tested in linux-next tree for a few days. Now the buggy patch has been dropped entirely from my next branch. Thus I hope those changes can still be merged in 3.18-rc2 as most of them are platform thermal driver changes. Specifics: - introduce ACPI INT340X thermal drivers. Newer laptops and tablets may have thermal sensors and other devices with thermal control capabilities that are exposed for the OS to use via the ACPI INT340x device objects. Several drivers are introduced to expose the temperature information and cooling ability from these objects to user-space via the normal thermal framework. From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui. - introduce a new thermal governor, which just uses a hysteresis to switch abruptly on/off a cooling device. This governor can be used to control certain fan devices that can not be throttled but just switched on or off. From: Peter Feuerer. - introduce support for some new thermal interrupt functions on i.MX6SX, in IMX thermal driver. From: Anson, Huang. - introduce tracing support on thermal framework. From: Punit Agrawal. - small fixes in OF thermal and thermal step_wise governor" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits) Thermal: int340x thermal: select ACPI fan driver Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs Thermal: int340x_thermal: expose acpi thermal relationship tables Thermal: introduce int3403 thermal driver Thermal: introduce INT3402 thermal driver Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h ACPI / Fan: support INT3404 thermal device ACPI / Fan: add ACPI 4.0 style fan support ACPI / fan: convert to platform driver ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant ACPI / fan: remove no need check for device pointer ACPI / fan: remove unused macro Thermal: int3400 thermal: register to thermal framework Thermal: int3400 thermal: add capability to detect supporting UUIDs Thermal: introduce int3400 thermal driver ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package() ACPI: make acpi_create_platform_device() an external API thermal: step_wise: fix: Prevent from binary overflow when trend is dropping ACPI: introduce ACPI int340x thermal scan handler thermal: Added Bang-bang thermal governor ...
2014-10-25 02:21:43 +08:00
dev_err(&pdev->dev, "Failed to create sysfs link 'device'\n");
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
goto err_end;
}
return 0;
err_end:
if (fan->acpi4)
acpi_fan_delete_attributes(device);
return result;
}
static void acpi_fan_remove(struct platform_device *pdev)
{
struct acpi_fan *fan = platform_get_drvdata(pdev);
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
if (fan->acpi4) {
struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
acpi_fan_delete_attributes(device);
ACPI: fan: Expose fan performance state information When _FPS indicates variable speed fan support, the thermal cooling device for fan shows max performance state count as "max_state" (greater than or equal to 1). But the thermal cooling device doesn't expose the properties of each performance state. This is not enough for smart fan control user space software, which also considers speed, power and noise level. This change exposes the properties of the fan performance states in the sysfs directory of the ACPI device representing the fan, that is /sys/bus/acpi/devices/devices/INT3404:00 or /sys/bus/platform/devices/PNP0C0B:00. For example: $ ls /sys/bus/acpi/devices/INT3404\:00 description path state0 state11 state4 state7 status hid physical_node state1 state2 state5 state8 subsystem modalias power state10 state3 state6 state9 uevent uid wakeup where each state* attribute lists the properties of a fan performance state in the following format: control_percent:trip_point:speed_rpm:noise_level_mdb:power_mw $ cat /sys/bus/acpi/devices/INT3404\:00/state10 95:0:11600:47500:4500 as documented in Documentation/admin-guide/acpi/fan_performance_states.rst While at it, return the correct error code from acpi_fan_probe() when acpi_fan_get_fps() or acpi_fan_get_fif() fails. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject, changelog, documentation ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-14 07:48:40 +08:00
}
sysfs_remove_link(&pdev->dev.kobj, "thermal_cooling");
sysfs_remove_link(&fan->cdev->device.kobj, "device");
thermal_cooling_device_unregister(fan->cdev);
}
#ifdef CONFIG_PM_SLEEP
static int acpi_fan_suspend(struct device *dev)
{
struct acpi_fan *fan = dev_get_drvdata(dev);
if (fan->acpi4)
return 0;
acpi_device_set_power(ACPI_COMPANION(dev), ACPI_STATE_D0);
return AE_OK;
}
static int acpi_fan_resume(struct device *dev)
{
int result;
struct acpi_fan *fan = dev_get_drvdata(dev);
if (fan->acpi4)
return 0;
result = acpi_device_update_power(ACPI_COMPANION(dev), NULL);
if (result)
dev_err(dev, "Error updating fan power state\n");
return result;
}
static const struct dev_pm_ops acpi_fan_pm = {
.resume = acpi_fan_resume,
.freeze = acpi_fan_suspend,
.thaw = acpi_fan_resume,
.restore = acpi_fan_resume,
};
#define FAN_PM_OPS_PTR (&acpi_fan_pm)
#else
#define FAN_PM_OPS_PTR NULL
#endif
static struct platform_driver acpi_fan_driver = {
.probe = acpi_fan_probe,
.remove_new = acpi_fan_remove,
.driver = {
.name = "acpi-fan",
.acpi_match_table = fan_device_ids,
.pm = FAN_PM_OPS_PTR,
},
};
module_platform_driver(acpi_fan_driver);
MODULE_AUTHOR("Paul Diefenbaugh");
MODULE_DESCRIPTION("ACPI Fan Driver");
MODULE_LICENSE("GPL");