Hey Guenter!

On Tue, Aug 25, 2015 at 07:03:35AM -0700, Guenter Roeck wrote:
> 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.

Yes, we do have some bridges in place, and more coming (as thermal-iio
RFC). I just would like to have a more coordinated or a better overall
agreegation of these bridges. Specially to avoid breaking
compatibility, as you mentioned in the existing thermal-hwmon, and
iio-hwmon cases. This is the original motivation of this proposal,
define a clear path for this overlap.

> 
> 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.
> 


I don't think this is much of a concern from thermal subsystem, mainly
because most of the work would be first at the hwmon side.

On the other hand, I definitely agree that we need to sit down and
architecture what are the needed shared information between the
subsystems. And on top of that, how do we present them to userspace?
To avoid, for instance, having a half baked hwmon device showing up in
sysfs, if that is coming from thermal.

> 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.
> 

This is more in the direction of having a single subsystem to perform
the task of monitoring temperature. The amount of work will be similar
in either cases above, I would say. There is no simple way out, we would
need to touch all drivers. 

Of course, this is a view in the hwmon <-> thermal case, but we need to
consider the iio interactions too. This is why I though of starting this
topic :-)

I think a first step would be to clarify the data that would be needed
to be shared between the subsystems. What are the involved callbacks,
and monitoring modes? Once that is clear enough, we can properly design
and write better bridges across the three subsystems. A latter step
would be to discuss the convergence, if needed at all, to a single way
of monitoring temperature (within kernel and userspace). 

> Guenter
> 

BR,

Eduardo Valentin