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
