Linux: Kernel config default HWMON THERMAL. Build both into kernel. Or both as module.

[chris001]

From: https://github.com/groeck/lm-sensors/issues/30

The raspberry pi kernel is being built with config defaults which prevent the lm-sensors package from using the _thermal-hwmon bridge_ to read the CPU temperature from the RPi Broadcom SoC ARM CPU's built-in thermal sensor.

This is causing issues in Webmin, which has been unable to see the RPi CPU temp. Webmin relies on the lm-sensors package to obtain the CPU temp from whichever CPU sensor lm-sensors is able to automatically detect on the RPi server.
Also: https://github.com/webmin/webmin/issues/625

This issue should be easily fixed by modifying the default kernel build config settings used to build the released RPi Foundation kernel, to enable the lm-sensors package running on the released kernel to be able to obtain the CPU temperature data thru the _thermal-hwmon bridge_, saving the user having to do further work, such as learn how to manually recompile the kernel, and wait a long time for it to complete.

From @groeck :
"The thermal-hwmon bridge only works if THERMAL and HWMON are both configured to be built as module, or if both are configured to be built into the kernel. Based on the above, it appears that THERMAL is built into the kernel, and HWMON is built as module. With this configuration, the bridge does not work since code built into the kernel can not call functions declared in a module. On top of that, it is necessary to enable THERMAL_HWMON."

[jonsnow1357]

this also causes issues with sysstat which uses lm-sensors as back-end for reading sensors information.

I think the following kernel config options are necessary (as you can see from the lm-sensors issue referenced above), but I cannot figure where to enable them :(
CONFIG_THERMAL
CONFIG_HWMON
CONFIG_THERMAL_HWMON

Thanks

[kukabu]

It's cool feature and I use it. But I have bad new for you, it's not working with the upstream thermal driver. I wrote the trivial fix but it's still pending in the upstream :(.
https://patchwork.kernel.org/patch/9832799/

[groeck]

On Thu, Aug 31, 2017 at 02:42:58AM -0700, Michael Tatarinov wrote:

It's cool feature and I use it. But I have bad new for you, it's not working with the upstream thermal driver. I wrote the trivial fix but it's still pending in the upstream :(.
https://patchwork.kernel.org/patch/9832799/

Unfortunately that patch won't be acceptable; one can not introduce linux
specifica properties like this into a devicetree file. In addition to that, the
property is technically unnecessary: It is an implementation issue, not a system
description issue.

One option would be to declare a kenrel-internal preoperty such as
"linux,no-hwmon" and have hwmon drivers set it before calling the thermal
registration function.

Guenter

[JamesH65]

Any progress on this issue? Should it be closed?

[groeck]

I never heard back from the thermal maintainers.

Edit: I did hear back. Thermal maintainers are ok with an internal property, but ask for approval from DT maintainers.

[pelwell]

Have you tried with CONFIG_THERMAL=m? There would be small increase in overall kernel size, but we would consider it if everything still works as expected.

[groeck]

On Tue, Dec 05, 2017 at 03:40:24AM -0800, Phil Elwell wrote:

Have you tried with CONFIG_THERMAL=m? There would be small increase in overall kernel size, but we would consider it if everything still works as expected.

That won't help. My idea of attaching an internal dt property
won't help either, unfortunately, since thermal zones and hwmon
devices (or any other kind of devices, really) are separate
entities with no relation to each other (a thermal zone device
has a name, but no association with an actual device).

Guenter

[pelwell]

Why not? The issue title says "Build both into kernel. Or both as module."

[groeck]

See kukabu's comment. Note that I was wrong re thermal maintainers - I did hear back. Only, as mentioned above, a kernel-internal property does not work, or at least not easily. I'll be happy to stand corrected, though, and I'll be more that happy to accept respective patches.

[JamesH65]

Was there any news? Did this stuff make it in to the upstream kernel?

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[Ferroin]

Based on what I can tell, this did not make it upstream.

Unfortunately, this is also making Netdata's sensor monitoring plugin not work correctly (as it too relies on lm_sensors for data collection).

[JamesH65]

So, what needs to be done to progress this, or should it be closed?

[groeck]

drivers/thermal/rcar_thermal.c provides an example how to implement this. It does look kind of messy, but it may work. Someone with an affected system would have to try and make it work.

[lategoodbye]

Matthias Brugger send a patch to fix this issue:
https://patchwork.kernel.org/patch/10651645/

[pssc]

has this landed in a kernel people can use?

Matthias Brugger send a patch to fix this issue:
https://patchwork.kernel.org/patch/10651645/

[lategoodbye]

This has been merged in current mainline and will be available in Linux 5.0.

[kukabu]

... in 4.20.8 already

[tracernz]

Not in the RPi tree yet though: https://github.com/raspberrypi/linux/commits/rpi-4.20.y/drivers/thermal/broadcom/bcm2835_thermal.c . It is in the 5.0 tree: https://github.com/raspberrypi/linux/commits/rpi-5.0.y/drivers/thermal/broadcom/bcm2835_thermal.c

[JamesH65]

This will be released when we move to the next kernel bump. Closing issue.

[chris001]

It looks like Brugger patched only for BCM2835, which powers only the older hardware: RPi 1A, 1A+, 2A, 2A+, Compute 1, Zero v1.2, Zero v1.3, Zero W?
What about all the other Broadcom system on chip models running the newer RPi 2B, 3A, 3A+, 3B, 3B+, Compute 3, 4B and newer hardware?
https://en.wikipedia.org/wiki/Raspberry_Pi
BCM2835: RPi 1A, 1A+, 2A, 2A+, Compute 1, Zero v1.2, Zero v1.3, Zero W.
BCM2836: RPi 2B.
BCM2837: RPi 2Bv1.2, 3B, Compute 3, Compute 3 Lite.
BCM2837b0: RPi 3A+, 3B+, Compute 3+, Compute 3+ Lite.
BCM2711: RPi 4B.

[lategoodbye]

Except of the RPi 4B all Raspberries use the same thermal driver. The BCM2835 stands for the architecture not for the SoC. Yes, this can be very confusing.

[chris001]

Thanks. What would need to be done to enable hwmon by default on thermal_zone for RPi 4B ?

[lategoodbye]

Need to take a look ...

[konistehrad]

Sorry to necro an old thread, but has there been progress on bringing the RPi 4 into the fold?

[lategoodbye]

I plan to make a backport of Linux 5.6 which contains the new thermal driver. But just for 5.4