[GIT PULL] RESEND: thermal for v5.9-rc1

[GIT PULL] RESEND: thermal for v5.9-rc1

[Daniel Lezcano]

The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68:

  Linux 5.8-rc3 (2020-06-28 15:00:24 -0700)

are available in the Git repository at:


ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git
tags/thermal-v5.9-rc1

for you to fetch changes up to c569e805c7bcebdd069e5c97ce5f8543f6d02433:

  thermal: intel: intel_pch_thermal: Add Cannon Lake Low Power PCH
support (2020-08-04 10:43:03 +0200)

----------------------------------------------------------------
- Add support to enable/disable the thermal zones resulting on core code and
  drivers cleanup (Andrzej Pietrasiewicz)

- Add generic netlink support for userspace notifications: events,
temperature
  and discovery commands (Daniel Lezcano)

- Fix redundant initialization for a ret variable (Colin Ian King)

- Remove the clock cooling code as it is used nowhere (Amit Kucheria)

- Add the rcar_gen3_thermal's r8a774e1 support (Marian-Cristian Rotariu)

- Replace all references to thermal.txt in the documentation to the
  corresponding yaml files (Amit Kucheria)

- Add maintainer entry for the IPA (Lukasz Luba)

- Add support for MSM8939 for the tsens (Shawn Guo)

- Update power allocator and devfreq cooling to SPDX licensing (Lukasz Luba)

- Add Cannon Lake Low Power PCH support (Sumeet Pawnikar)

- Add tsensor support for V2 mediatek thermal system (Henry Yen)

- Fix thermal zone lookup by ID for the core code (Thierry Reding)

----------------------------------------------------------------
Amit Kucheria (2):
      thermal/drivers/clock_cooling: Remove clock_cooling code
      dt-bindings: thermal: Get rid of thermal.txt and replace references

Andrzej Pietrasiewicz (14):
      acpi: thermal: Fix error handling in the register function
      thermal: Store thermal mode in a dedicated enum
      thermal: Add current mode to thermal zone device
      thermal: Store device mode in struct thermal_zone_device
      thermal: remove get_mode() operation of drivers
      thermal: Add mode helpers
      thermal: Use mode helpers in drivers
      thermal: Explicitly enable non-changing thermal zone devices
      thermal: core: Stop polling DISABLED thermal devices
      thermal: Simplify or eliminate unnecessary set_mode() methods
      thermal: Rename set_mode() to change_mode()
      acpi: thermal: Don't call thermal_zone_device_is_enabled()
      thermal: imx: Use driver's local data to decide whether to run a
measurement
      thermal: Make thermal_zone_device_is_enabled() available to core only

Anson Huang (1):
      thermal: imx8mm: Support module autoloading

Colin Ian King (1):
      thermal: core: remove redundant initialization of variable ret

Dan Carpenter (1):
      thermal: ti-soc-thermal: Fix reversed condition in
ti_thermal_expose_sensor()

Daniel Lezcano (9):
      thermal: core: Add helpers to browse the cdev, tz and governor list
      thermal: core: Get thermal zone by id
      thermal: core: genetlink support for events/cmd/sampling
      thermal: core: Add notifications call in the framework
      thermal: netlink: Fix compilation error when CONFIG_NET=n
      net: genetlink: Move initialization to core_initcall
      thermal: netlink: Improve the initcall ordering
      thermal: core: Move initialization after core initcall
      thermal: core: Add thermal zone enable/disable notification

Henry Yen (2):
      thermal: mediatek: Prepare to add support for other platforms
      thermal: mediatek: Add tsensor support for V2 thermal system

Konrad Dybcio (1):
      dt-bindings: tsens: qcom: Document MSM8939 compatible

Lukas Bulwahn (1):
      MAINTAINERS: update entry to thermal governors file name prefixing

Lukasz Luba (2):
      MAINTAINERS: Add maintenance information for IPA
      thermal: Update power allocator and devfreq cooling to SPDX licensing

Marian-Cristian Rotariu (1):
      thermal: rcar_gen3_thermal: Add r8a774e1 support

Niklas Söderlund (1):
      thermal: rcar_gen3_thermal: Do not shadow thcode variable

Shawn Guo (1):
      thermal: qcom: tsens-v0_1: Add support for MSM8939

Sumeet Pawnikar (2):
      thermal: int340x: processor_thermal: fix: update Jasper Lake PCI id
      thermal: intel: intel_pch_thermal: Add Cannon Lake Low Power PCH
support

Thierry Reding (1):
      thermal: core: Fix thermal zone lookup by ID

 Documentation/devicetree/bindings/arm/arm,scmi.txt |   2 +-
 Documentation/devicetree/bindings/arm/arm,scpi.txt |   2 +-
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  |   2 +-
 .../arm/marvell/ap80x-system-controller.txt        |   2 +-
 .../arm/marvell/cp110-system-controller.txt        |   2 +-
 .../devicetree/bindings/cpufreq/cpufreq-dt.txt     |   3 +-
 .../bindings/cpufreq/cpufreq-mediatek.txt          |   4 +-
 .../bindings/cpufreq/nvidia,tegra20-cpufreq.txt    |   2 +-
 .../devicetree/bindings/hwmon/gpio-fan.txt         |   3 +-
 Documentation/devicetree/bindings/hwmon/lm90.txt   |   4 +-
 .../bindings/thermal/allwinner,sun8i-a83t-ths.yaml |   2 +-
 .../bindings/thermal/amazon,al-thermal.txt         |   2 +-
 .../bindings/thermal/brcm,avs-ro-thermal.yaml      |   2 +-
 .../bindings/thermal/brcm,bcm2835-thermal.txt      |   2 +-
 .../bindings/thermal/hisilicon-thermal.txt         |   2 +-
 .../bindings/thermal/max77620_thermal.txt          |   6 +-
 .../bindings/thermal/mediatek-thermal.txt          |   2 +-
 .../bindings/thermal/nvidia,tegra124-soctherm.txt  |  10 +-
 .../thermal/nvidia,tegra186-bpmp-thermal.txt       |   2 +-
 .../bindings/thermal/qcom-spmi-temp-alarm.txt      |   2 +-
 .../devicetree/bindings/thermal/qcom-tsens.yaml    |   1 +
 .../bindings/thermal/rockchip-thermal.txt          |   2 +-
 .../devicetree/bindings/thermal/tango-thermal.txt  |   2 +-
 .../bindings/thermal/thermal-generic-adc.txt       |   2 +-
 .../devicetree/bindings/thermal/thermal.txt        | 586
-------------------
 MAINTAINERS                                        |   8 +
 drivers/acpi/thermal.c                             |  76 +--
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.c |   8 +
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |  91 +--
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c        |   9 +-
 drivers/platform/x86/acerhdf.c                     |  33 +-
 drivers/platform/x86/intel_mid_thermal.c           |   6 +
 drivers/power/supply/power_supply_core.c           |   9 +-
 drivers/thermal/Kconfig                            |  20 +-
 drivers/thermal/Makefile                           |   6 +-
 drivers/thermal/armada_thermal.c                   |   6 +
 drivers/thermal/clock_cooling.c                    | 445 --------------
 drivers/thermal/da9062-thermal.c                   |  16 +-
 drivers/thermal/devfreq_cooling.c                  |  10 +-
 drivers/thermal/dove_thermal.c                     |   6 +
 drivers/thermal/gov_power_allocator.c              |   9 +-
 drivers/thermal/hisi_thermal.c                     |   6 +-
 drivers/thermal/imx8mm_thermal.c                   |   1 +
 drivers/thermal/imx_thermal.c                      |  60 +-
 .../intel/int340x_thermal/int3400_thermal.c        |  38 +-
 .../intel/int340x_thermal/int340x_thermal_zone.c   |   5 +
 .../int340x_thermal/processor_thermal_device.c     |   2 +-
 drivers/thermal/intel/intel_pch_thermal.c          |   8 +
 drivers/thermal/intel/intel_quark_dts_thermal.c    |  34 +-
 drivers/thermal/intel/intel_soc_dts_iosf.c         |   3 +
 drivers/thermal/intel/x86_pkg_temp_thermal.c       |   6 +
 drivers/thermal/kirkwood_thermal.c                 |   7 +
 drivers/thermal/mtk_thermal.c                      | 234 ++++++--
 drivers/thermal/qcom/tsens-v0_1.c                  | 144 ++++-
 drivers/thermal/qcom/tsens.c                       |   3 +
 drivers/thermal/qcom/tsens.h                       |   2 +-
 drivers/thermal/rcar_gen3_thermal.c                |  10 +-
 drivers/thermal/rcar_thermal.c                     |   9 +-
 drivers/thermal/rockchip_thermal.c                 |   6 +-
 drivers/thermal/spear_thermal.c                    |   7 +
 drivers/thermal/sprd_thermal.c                     |   6 +-
 drivers/thermal/st/st_thermal.c                    |   5 +
 drivers/thermal/thermal_core.c                     | 174 +++++-
 drivers/thermal/thermal_core.h                     |  15 +
 drivers/thermal/thermal_helpers.c                  |  13 +-
 drivers/thermal/thermal_netlink.c                  | 647
+++++++++++++++++++++
 drivers/thermal/thermal_netlink.h                  | 104 ++++
 drivers/thermal/thermal_of.c                       |  41 +-
 drivers/thermal/thermal_sysfs.c                    |  52 +-
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |   2 +-
 include/linux/clock_cooling.h                      |  57 --
 include/linux/devfreq_cooling.h                    |   9 +-
 include/linux/thermal.h                            |  31 +-
 include/uapi/linux/thermal.h                       |  89 ++-
 net/netlink/genetlink.c                            |   2 +-
 75 files changed, 1632 insertions(+), 1609 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 delete mode 100644 drivers/thermal/clock_cooling.c
 create mode 100644 drivers/thermal/thermal_netlink.c
 create mode 100644 drivers/thermal/thermal_netlink.h
 delete mode 100644 include/linux/clock_cooling.h

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [GIT PULL] RESEND: thermal for v5.9-rc1

[pr-tracker-bot]

The pull request you sent on Thu, 6 Aug 2020 22:18:59 +0200:

> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git tags/thermal-v5.9-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/96e3f3c16b7aedcd71502ccfc5778dddfc2e7b15

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] RESEND: thermal for v5.9-rc1

[Linus Torvalds]

On Thu, Aug 6, 2020 at 1:19 PM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
>
> - Add generic netlink support for userspace notifications: events,
> temperature
>   and discovery commands (Daniel Lezcano)

This is "default y".

Why?

The help text doesn't explain either.

Please explain, or remove the default y. We don't add new features and
then try to force people to use them by enabling them by default.

"default y" is mainly for when something unconditional gets split up
and becomes conditional (so now "default y" means that you don't break
peoples setups when they don't even know what it is).

Alternatively, "default y" is for things that are make peoples lives
immeasurably better somehow, and it would be a crime to not enable it
because it's _so_ wonderful.

So far, I'm not convinced we've ever hit that second case.

Convince me that the thermal layer is so magical that it really
warrants it. Tell me why and how my life is improved by enabling it.

             Linus

Re: [GIT PULL] RESEND: thermal for v5.9-rc1

[Daniel Lezcano]

Hi Linus,


On 07/08/2020 04:43, Linus Torvalds wrote:
> On Thu, Aug 6, 2020 at 1:19 PM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>>
>> - Add generic netlink support for userspace notifications: events,
>> temperature
>>   and discovery commands (Daniel Lezcano)
> 
> This is "default y".
> 
> Why?
> 
> The help text doesn't explain either.
> 
> Please explain, or remove the default y. We don't add new features and
> then try to force people to use them by enabling them by default.
> 
> "default y" is mainly for when something unconditional gets split up
> and becomes conditional (so now "default y" means that you don't break
> peoples setups when they don't even know what it is).
> 
> Alternatively, "default y" is for things that are make peoples lives
> immeasurably better somehow, and it would be a crime to not enable it
> because it's _so_ wonderful.

Well, I won't argue the netlink notification is so that fantastic but it
is a feature that was needed since a long time. A previous partial
implementation was directly compiled-in and then removed [1] because
there were no user as it is and we wanted to introduce a clean new
notification framework based in our previous discussion at Linux
Plumbers Conference [2] but that needed some cleanups of the thermal
core code before.

This netlink framework fulfills the needs of the thermal daemons for
Intel, Android HAL and SoC vendors which are hacking the thermal
framework or constantly polling the temperature.

Because the compilation failed if CONFIG_NET=n, the Kconfig option was
introduced afterwards [3]. It could have been directly handled in the
code with a 'ifdef' directive without option but it sounded more
convenient to at least give the opportunity to opt-out the notification.

It defaults to 'y' because the previous (but unused) implementation was
unconditionally compiled-in and because of the thermal users needs.

Is default=y wrong given this history?

 -- Daniel


[1] https://patchwork.kernel.org/patch/11202093/
[2]
https://www.linuxplumbersconf.org/event/2/contributions/185/attachments/39/46/LPC_2018_Thermal-Srinivas-Rui.pdf
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git/commit/?h=thermal/next&id=5b8583d3bd7fc10cea07e4a5bfa59465758a39dc


> So far, I'm not convinced we've ever hit that second case.
> 
> Convince me that the thermal layer is so magical that it really
> warrants it. Tell me why and how my life is improved by enabling it.
> 
>              Linus
> 


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [GIT PULL] RESEND: thermal for v5.9-rc1

[Linus Torvalds]

On Fri, Aug 7, 2020 at 2:40 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
> It defaults to 'y' because the previous (but unused) implementation was
> unconditionally compiled-in and because of the thermal users needs.
>
> Is default=y wrong given this history?

One million percent wrong.

The fact that the old implementation was never used just shows that
it's not so important, and it shouldn't be default 'y'. Not having it
doesn't break anything.

And the new implementation presumably isn't even compatible with the
old format also means that it shouldn't be default 'y'. Building it in
wouldn't help anyway.

And the fact that _some_ users might want it does not mean that it
should be default 'y', because those users presumably _know_ they want
it.

IOW, defaulting to 'y' is just wrong in every possible way. This is
not some kind of "to maintain compatibility and not break existing
users we should enable this" kind of thing.

And it's not some kind of "everybody should have it" thing either,
since presumably nobody has the user-space support for it anyway.

It's something that a new distro would enable _if_ they actually end
up supporting the user space. Not something the kernel should enable
"just because".

Really: "default y" is _wrong_. Every developer thinks that _their_
code is so magical and special that everybody should run it.

And every developer is almost always wrong. Unless you have a "not
having this will break existing users", you don't do it.

                 Linus

Re: [GIT PULL] RESEND: thermal for v5.9-rc1

[Daniel Lezcano]

On 07/08/2020 17:54, Linus Torvalds wrote:
> On Fri, Aug 7, 2020 at 2:40 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>> It defaults to 'y' because the previous (but unused) implementation was
>> unconditionally compiled-in and because of the thermal users needs.
>>
>> Is default=y wrong given this history?
> 
> One million percent wrong.
> 
> The fact that the old implementation was never used just shows that
> it's not so important, and it shouldn't be default 'y'. Not having it
> doesn't break anything.
> 
> And the new implementation presumably isn't even compatible with the
> old format also means that it shouldn't be default 'y'. Building it in
> wouldn't help anyway.
> 
> And the fact that _some_ users might want it does not mean that it
> should be default 'y', because those users presumably _know_ they want
> it.
> 
> IOW, defaulting to 'y' is just wrong in every possible way. This is
> not some kind of "to maintain compatibility and not break existing
> users we should enable this" kind of thing.
> 
> And it's not some kind of "everybody should have it" thing either,
> since presumably nobody has the user-space support for it anyway.
> 
> It's something that a new distro would enable _if_ they actually end
> up supporting the user space. Not something the kernel should enable
> "just because".
> 
> Really: "default y" is _wrong_. Every developer thinks that _their_
> code is so magical and special that everybody should run it.
> 
> And every developer is almost always wrong. Unless you have a "not
> having this will break existing users", you don't do it.

Ok, I will send a fix.

Thanks for taking the time to clarify that.

  -- Daniel


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [GIT PULL] RESEND: thermal for v5.9-rc1

[Linus Torvalds]

On Fri, Aug 7, 2020 at 11:06 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> Ok, I will send a fix.

I ended up doing it during my morning routine of looking around for,
and applying, random patches.

So it's commit 0f5d0a4c01cc ("thermal: don't make THERMAL_NETLINK
'default y'") in my tree now.

                 Linus

Re: [GIT PULL] RESEND: thermal for v5.9-rc1

[Daniel Lezcano]

On 07/08/2020 20:12, Linus Torvalds wrote:
> On Fri, Aug 7, 2020 at 11:06 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>>
>> Ok, I will send a fix.
> 
> I ended up doing it during my morning routine of looking around for,
> and applying, random patches.
> 
> So it's commit 0f5d0a4c01cc ("thermal: don't make THERMAL_NETLINK
> 'default y'") in my tree now.

Great, thank you!


  -- Daniel


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog