The thermal core only supports a fixed number of trip points for each
driver and the core informs the driver of any changes to those, so
drivers using the core framework can already have hardware trip points,
but just a fixed number of them.
The way of-thermal works, is it reads all the trip points from the
device tree, registers a new thermal_zone_device with that number of
trip points and then handles the trip points completely independently.
Of course, if we're just polling, this is fine, since the thermal core
also knows about those trip points and will trigger cooling when polling
the each zone. However, the driver doesn't, so it cannot setup any
interrupts to call thermal_zone_device_update.
Is there any possibility of cleaning that up? It's obviously horribly
inconsistent if core driver functionality works completely differently
simply because the list of trip-points comes from DT rather than a
static table in the driver. of_thermal should be limited to DT parsing
and related device instantiation/lookup, not introducing a completely
different functionality model.