The temperature is readable, and nothing acts on it

the question

Is it safe to leave this board powered and unattended?

A direct question, and it deserves a direct answer rather than a survey. The temperature is readable, and nothing acts on it. No throttling, no shutdown, no trip point of any kind. That is a property of the vendor kernel and the vendor device trees, not of anything this project configured or left out.

This is a gap that has been characterised, not a fire. Nobody has yet measured what this part runs at, and it is entirely possible it never gets warm enough for any of it to matter — which is exactly why the first step below is a measurement and not a patch.

what works

The sensor is bound, and the core is there to receive it

All symbol evidence on this page comes from System.map of our own build, linux-riscv64-unknown-linux-gnu-6.6.36-xuantie — the kernel that is on the card, not an upstream tree.

# System.map — linux-…-6.6.36-xuantie
t canaan_thermal_probe
t canaan_thermal_init
d __initcall__kmod_canaan_thermal__258_122_canaan_thermal_init6
d of_canaan_thermal_match

# …and the core it registers with
T thermal_zone_device_register_with_trips
T thermal_zone_device_critical
# 306 thermal* symbols in total

drivers/thermal/canaan_thermal.c is enabled by CONFIG_CANAAN_THERMAL, which is default ARCH_CANAAN and so arrives without ever being named in k230_defconfig. It matches tsensor@91107000, compatible = "canaan,k230-tsensor", which is status = "okay" at k230.dtsi:850. The initcall6 symbol is the built-in registration — it is not a module that might fail to load.

what does not

Three breaks in the loop, and any one of them is enough

A thermal response in Linux is a chain: a sensor produces a temperature, a zone compares it against trip points, a governor reacts to a crossed trip, and a cooling device is what the governor acts on. This kernel has the first link and the last three are missing.

The left half is real; everything right of the zone is absent. The driver registers through thermal_tripless_zone_device_register, which is exactly what it says. A zone with no trips never crosses a trip, so the core never invokes a governor and never calls thermal_zone_device_critical() — the emergency-shutdown path that is compiled in, and is unreachable.

// drivers/thermal/canaan_thermal.c:86
data->tz = thermal_tripless_zone_device_register(
        …
);

The driver registers a zone with no trip points, deliberately

thermal_tripless_* is exactly what its name says. The driver is not incomplete; it was written to be a thermometer. A zone with no trips never crosses a trip, so the thermal core never invokes a governor and never calls thermal_zone_device_critical().

No device tree supplies trips either

A thermal-zones node is the usual place a board declares trip-point and critical entries and binds a cooling device to them. There is no thermal-zones node in any K230 device tree in the Xuantie tree, so the gap is not closed from the DT side either.

There is no cooling device to bind even if a trip existed

The only cpufreq symbol in this kernel is cpufreq_add_device; there is no cpufreq_register_driver, so no cpufreq driver is present and the CPU has no DVFS states Linux can select. The conventional response to a passive trip — throttle the CPU — has nothing to act on. That leaves a critical trip forcing an orderly poweroff as the only meaningful protection available, and it is not configured.

in practice

What that means for a board on a desk

Three statements, stated at the strength the evidence supports

Nothing in software will stop this board getting hot. Any protection is whatever the silicon does on its own, which has not been characterised. The TSENSOR block may well have a hardware trip independent of Linux; nobody has read the datasheet on that point yet.

The second C908 is still running its own firmware. Whether RT‑Smart implements a thermal response of its own is unknown and outside our kernel entirely. See the first-boot note for why that core is not ours.

Powering the board down when leaving it unattended is the correct instinct on this evidence, rather than excessive caution. It is also a cheap habit, which is the main argument for it while steps 1 and 2 below are outstanding.

Four steps, cheapest first, and the order is the point

Steps 1 and 2 are research. Step 3 is a small change. Step 4 should not be started until 1 and 2 say it is needed — and they may well say it is not.

step 1 · one boot

Read the sensor

cat /sys/class/thermal/thermal_zone*/temp at idle, then again after a sustained load, and write both numbers down.

This costs a single boot and tells us whether the part even runs warm. It may make everything below it moot, which is the best possible outcome for a list like this one.

step 2 · research

Find the hardware limit

The K230 datasheet’s operating range, and whether the TSENSOR block has a hardware trip of its own independent of Linux.

canaan_thermal.c and the hardlock = <2> property on the DT node are the two places to look.

step 3 · small change

Add a critical trip

A thermal-zones node with a critical trip referencing the tsensor, which finally gives thermal_zone_device_critical() something to fire on.

This needs step 2 first. A made-up threshold is worse than none, because it either never fires — and is then a comfort rather than a protection — or it shuts the board down in the middle of normal work.

step 4 · only if needed

Consider throttling

Which means a cpufreq driver and an OPP table: a substantially larger piece of work, for a board that may simply never get hot enough to need it.

Not started until steps 1 and 2 have argued for it.

Research: docs/thermal.md. Symbol evidence: System.map of linux-riscv64-unknown-linux-gnu-6.6.36-xuantie, this repository's own build.

Kernel sources: drivers/thermal/canaan_thermal.c (line 86 is the tripless registration), drivers/thermal/thermal_core.c, and arch/riscv/boot/dts/canaan/k230.dtsi line 850 for the tsensor node.

Nothing on this page has been observed on the board. It is read out of source and out of our own build's symbol table, which is enough to establish what is absent and not enough to say what the hardware does about it.