On 4/12/19 6:57 AM, Sudeep Holla wrote:
On Tue, Apr 02, 2019 at 08:22:58PM -0700, Florian Fainelli wrote:
Hi Sudeep,
There are a couple of things on which I would appreciate your feedback
regarding the Linux SCMI sensor protocol:
1) The Linux SCMI implementation has all the nuts and bolts to allow
configuring trip points, but the hwmon subsystem through the use of
hwmon_thermal_add_sensor() API does not actually make use of that
capability. Would it be a big stretch to use the hwmon_ops::write
function to get to support that feature?
As a concept, it sounds good. Though I am not sure if write API semantics
match with what we want here with trip point configuration.
Last time I checked, the thermal subsystem concept of trip points was strictly
dynamic. Exceeding a trip point (low or high) would result in a signal followed
by the trip point being updated.
In the hwmon subsystem, and in general with temperature sensors it supports,
trip points (or limits) are static. Making such static trip points available
to the thermal subsystem would, in many cases, have undesirable consequences:
Exceeding a trip point often does not only generate a signal, it may also
activate a pin which, in turn, could for example activate fans or, in extreme
cases, shut down the system. It would also affect status reporting in the hwmon
subsystem, where exceeding a trip point is reported with a sysfs attribute.
In order to interconnect the thermal subsystem more closely with the hwmon
subsystem, it would be necessary for the thermal subsystem to recognize a
concept of static trip points.
If scmi is to be used with the thermal subsystem and its concept of dynamic
trip points, I would suggest to move the driver from hwmon to thermal. People
can then use the thermal->hwmon bridge for (limited) temperature reporting
through the hwmon subsystem.
Thanks,
Guenter
