Re: [Ksummit-discuss] [TECH TOPIC] [CORE TOPIC] The three ways of temperature sensing in Linux

[Guenter Roeck <linux@roeck-us.net>]

On 08/24/2015 11:26 PM, Krzysztof Kozlowski wrote:
> On 25.08.2015 15:12, Eduardo Valentin wrote:
>> Hi all,
>>
>> [Not sure if this is TECH or CORE, as it touches more than one
>> subsystem]
>>
>> Not sure how late it is to post this, but I am trying anyway.
>>
>> During LPC 2015 last week it came out the topic of the interaction
>> between the thermal subsystem with HWMON. On top of it, we also got a
>> proposal [1] of having thermal exposing its registered devices as IIO.
>>
>> I know the three subsystem coexist today for some years. They also have
>> their own design goals. However, the fact that we have three different
>> subsystems for doing very similar task may be confusing, for the driver
>> writer, and for user space too.
>>
>> Another aspect of it is the possible code duplication. For example, it
>> would interesting to get board temperature sensors, typically registered
>> as hwmon devices, to be available in the thermal subsystem while
>> constructing thermal zones out of them. Some user process would expect
>> the opposite though, to read the thermal zone sensors as hwmon devices,
>> or as IIO devices.
>
> I would rather expect using only one subsystem for exporting this
> information to user-space. If the susbsytem lacks some features then it
> could be expanded.
>
> Some power supply drivers (fuel gauges or chargers) also provide
> temperature data. They use the thermal for that. It would be weird to
> export them through IIO...
>

I agree, the current situation is less than optimal.

There are bridges from thermal and iio to hwmon, but they are not
perfect. Resulting hwmon device names are odd, and iio doesn't support
limits. The thermal-hwmon bridge only supports one trip point, and
it doesn't pass alarms.

Both the iio-hwmon and the thermal-hwmon bridge break the hwmon model
of reporting sensor data per chip, which makes it difficult to convert
drivers from hwmon to thermal (if that is suggested) without breaking
the userspace ABI.

At the same time, there is no bridge from the hwmon core to thermal.
Currently hwmon drivers supporting thermal register with both hwmon
and thermal, which is really undesirable. Implementing a hwmon-thermal
bridge in the hwmon core would require implementing a new hwmon registration
API. That is easier said then done, and would require more time than
at least I have available.

This, I think, is the core of the problem. Somehow would have to go in
and create that new hwmon registration API, if that is a solution
acceptable to the thermal maintainers. At the same time, the thermal-hwmon
bridge should be improved to export provide available information to hwmon.

An alternative would be for thermal to 'take over', convert all hwmon
drivers to thermal drivers, and retain a compatibility layer to provide
the data as hwmon device data to user space without breaking the existing
hwmon ABI. Again, someone would have to do that work.

Guenter