Couple of questions on SCMI sensor protocol and Linux implementation

Couple of questions on SCMI sensor protocol and Linux implementation

[Florian Fainelli]

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? The other thing that puzzles me
is that there does not appear to be provision in the SCMI sensor
protocol to describe thermal zones, so I assume that people still have
to provide supplemental data through Device Tree for
devm_thermal_zone_of_sensor_register() to pick up the thermal zones
definitions?

2) Support for regulators through SCMI

I work with a device where the regulators can only be controlled via a
dedicated piece of HW which is accessible through SCMI from the Linux
side. Do you think there is value in coming up with a scmi-regulator.c
driver that makes use of the sensor protocol for discovering and
reporting regulators or would that be something that belongs more to the
power domain protocol?

Thanks for reading me! Cheers
-- 
Florian

Re: Couple of questions on SCMI sensor protocol and Linux implementation

[Sudeep Holla]

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.

> The other thing that puzzles me
> is that there does not appear to be provision in the SCMI sensor
> protocol to describe thermal zones, so I assume that people still have
> to provide supplemental data through Device Tree for
> devm_thermal_zone_of_sensor_register() to pick up the thermal zones
> definitions?
>

Yes, I tend to agree. When SCMI v1.0 was designed we were not sure if
we can incorporate thermal zones into the specification without losing
the flexibility that vendors have today with DT. If you think we should
update the specification for this, can you send me brief summary so that
the discussion on the specification side can be kicked off.

> 2) Support for regulators through SCMI
>
> I work with a device where the regulators can only be controlled via a
> dedicated piece of HW which is accessible through SCMI from the Linux
> side. Do you think there is value in coming up with a scmi-regulator.c
> driver that makes use of the sensor protocol for discovering and
> reporting regulators or would that be something that belongs more to the
> power domain protocol?
>

Controlling regulators directly from OSPM/Linux via SCMI was intentionally
not added to the specification. One of the issues SCMI wanted to address
is clockscrew[1] kind of security attacks exploiting direct regulator control.

--
Regards,
Sudeep

[1] https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-tang.pdf

Re: Couple of questions on SCMI sensor protocol and Linux implementation

[Guenter Roeck]

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

Re: Couple of questions on SCMI sensor protocol and Linux implementation

[Florian Fainelli]

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.
> 
>> The other thing that puzzles me
>> is that there does not appear to be provision in the SCMI sensor
>> protocol to describe thermal zones, so I assume that people still have
>> to provide supplemental data through Device Tree for
>> devm_thermal_zone_of_sensor_register() to pick up the thermal zones
>> definitions?
>>
> 
> Yes, I tend to agree. When SCMI v1.0 was designed we were not sure if
> we can incorporate thermal zones into the specification without losing
> the flexibility that vendors have today with DT. If you think we should
> update the specification for this, can you send me brief summary so that
> the discussion on the specification side can be kicked off.

For now, I am fine with the supplemental data in Device Tree to
advertise thermal zones and that seems to work nicely. I will reply to
Guenter's comment though.

> 
>> 2) Support for regulators through SCMI
>>
>> I work with a device where the regulators can only be controlled via a
>> dedicated piece of HW which is accessible through SCMI from the Linux
>> side. Do you think there is value in coming up with a scmi-regulator.c
>> driver that makes use of the sensor protocol for discovering and
>> reporting regulators or would that be something that belongs more to the
>> power domain protocol?
>>
> 
> Controlling regulators directly from OSPM/Linux via SCMI was intentionally
> not added to the specification. One of the issues SCMI wanted to address
> is clockscrew[1] kind of security attacks exploiting direct regulator control.

So that is also precisely why we did that architecture where there is an
indirection layer through the SCMI provider. In our case we have a PMIC
device that is controllable only through a dedicated processor which we
consider trusted in the system. That processor can be made aware of
specific board level details such as, which PMIC rail controls the power
of which peripheral.

The main use case here is really that when you enter system standby into
a deep sleep you may want to leave some of those regulators on such
that, say: Wake-on-LAN/WLAN can take the system out of suspend.
Traditionally these regulators were controlled over GPIOs, but now they
are controlled by the isolated PMIC. This is the background for this
question essentially.

Thanks!
-- 
Florian