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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux