From: Sudeep Holla <sudeep.holla@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-hwmon@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: Couple of questions on SCMI sensor protocol and Linux implementation
Date: Fri, 12 Apr 2019 14:57:47 +0100 [thread overview]
Message-ID: <20190412135747.GC23351@e107155-lin> (raw)
In-Reply-To: <1902f151-7ddd-6b4b-4135-a2affe20c009@gmail.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-12 13:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 3:22 Couple of questions on SCMI sensor protocol and Linux implementation Florian Fainelli
2019-04-12 13:57 ` Sudeep Holla [this message]
2019-04-12 15:38 ` Guenter Roeck
2019-04-12 22:40 ` Florian Fainelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190412135747.GC23351@e107155-lin \
--to=sudeep.holla@arm.com \
--cc=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox