linux-kernel - [RFC PATCH 0/3] SCMI System Power Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200427210806.37422-1-cristian.marussi@arm.com>
Date:   Mon, 27 Apr 2020 22:08:03 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc:     sudeep.holla@....com, lukasz.luba@....com,
        james.quinlan@...adcom.com, Jonathan.Cameron@...wei.com,
        cristian.marussi@....com
Subject: [RFC PATCH 0/3] SCMI System Power Support

Hi all,

this series wants to add the core SCMI System Power support and related
events' handling logic: the protocol support itself is trivial and boils
down to some bare initializations and supporting one SCMI System Power
notification event meant to carry platform-originated System transition
requests. This is patch [1/3].

On top of this a new SCMI driver has been developed which registers for
such System Power notification and acts accordingly to satisfy such
plaform system-state transition requests that can be of forceful or
graceful kind.

In order to comply with such graceful requests, and co-operate with
userspace entities to drive a clean shutdown/reboot, the logic of the
driver relies on the same orderly_* API methods used by ACPI when handling
ACPI Shutdown bus events. This is patch [2/3].

Patch [3/3] is a mere JUNO example of the minimal DT bindings needed to
enable the protocol at the DT level and is NOT meant to be upstream as of
now.

A viable alternative method (not implemented here) for communicating
graceful requests to userspace could be to use instead signals to PID 1
init process (e.g. kill_cad_pid(SIGRTMIN + 4, 1)): this method is supported
out-of-the-box by SystemD and (to some extent) Android, and, maybe, could
be interesting as an optional alternative, since it avoids the dependency
on usermodehelpers introduced by the internals of the orderly_ API calls
above.

Such alternative, if deemed worth, should clearly be configurable via DT
(also in terms of which signals to use), BUT all of this work is not done
in this series: and that's the reason for the RFC tag: does it make sense
to add such a configurable additional option ?

The series is based on SCMI Notifications Core V7 (still not posted though)
which in turn is based on top of scmi-for-next-5.7 and it's available (with
some additional debug on top) at [1].

Thanks

Cristian

----

[1] http://www.linux-arm.org/git?p=linux-cm.git;a=shortlog;h=refs/heads/scmi_system_power_V1

Cristian Marussi (3):
  firmware: arm_scmi: Add System Power Protocol support
  firmware: arm_scmi: Add SCMI System Power Control driver
  arm64: dts: juno: add SCMI SystemPower Protocol support

 arch/arm64/boot/dts/arm/juno-base.dtsi        |   4 +
 drivers/firmware/Kconfig                      |  12 +
 drivers/firmware/arm_scmi/Makefile            |   3 +-
 drivers/firmware/arm_scmi/driver.c            |   1 +
 .../firmware/arm_scmi/scmi_power_control.c    | 359 ++++++++++++++++++
 drivers/firmware/arm_scmi/system.c            | 146 +++++++
 include/linux/scmi_protocol.h                 |  17 +
 7 files changed, 541 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/arm_scmi/scmi_power_control.c
 create mode 100644 drivers/firmware/arm_scmi/system.c

-- 
2.17.1