Skip to content
Snippets Groups Projects
Select Git revision
  • a8a6c04586233e12551552c292797cb56b31dade
  • lcd_v4.8 default
  • llvm_v4.8
  • dev_smp_nullb
  • dev_smp
  • dev_nullb
  • dev_foobar
  • dev_ixgbe
  • dev_netdummy
  • depriv
  • dev_idl_4.8_no_channels
  • dev_idl_4.8
  • dev_idl
  • temp_lcd_v4.8
  • idl_fixes
  • lcd
  • lcd_stack_protector
  • irq
  • pmfs
  • dev_nvme
  • async
  • sosp-19
  • v3.11.3
  • v3.10.14
  • v3.4.64
  • v3.0.98
  • v3.12-rc3
  • v3.11.2
  • v3.10.13
  • v3.4.63
  • v3.0.97
  • v3.12-rc2
  • v3.12-rc1
  • v3.11.1
  • v3.10.12
  • v3.4.62
  • v3.0.96
  • v3.2.51
  • v3.10.11
  • v3.4.61
  • v3.0.95
41 results

thermal

user avatar
Jean Delvare authored and Len Brown committed
THERMAL_HWMON is implemented inside the thermal_sys driver and has no
effect on drivers implementing thermal zones, so they shouldn't see
anything related to it in <linux/thermal.h>.  Making the THERMAL_HWMON
implementation fully internal has two advantages beyond the cleaner
design:

* This avoids rebuilding all thermal drivers if the THERMAL_HWMON
  implementation changes, or if CONFIG_THERMAL_HWMON gets enabled or
  disabled.

* This avoids breaking the thermal kABI in these cases too, which should
  make distributions happy.

The only drawback I can see is slightly higher memory fragmentation, as
the number of kzalloc() calls will increase by one per thermal zone.  But
I doubt it will be a problem in practice, as I've never seen a system with
more than two thermal zones.

Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
Cc: Rene Herman <rene.herman@gmail.com>
Acked-by: default avatarGuenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
31f5396a
History
Name Last commit Last update
..