linux-kernel - [PATCH v5 0/3] Introduce SCMI System Power Control driver

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]

Date:   Thu,  4 Feb 2021 16:59:10 +0000
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, arnd@...db.de,
        gregkh@...uxfoundation.org, robh@...nel.org
Subject: [PATCH v5 0/3] Introduce SCMI System Power Control driver

Hi

This series, building on top of the recently introduced SCMI System Power
Protocol support, adds a new SCMI driver which, registering for SystemPower
notifications, acts accordingly to satisfy SCMI plaform system transitions
requests like shutdown/reboot both of graceful and forceful kind. (possibly
involving userspace when the request is of the graceful kind)

Interaction with userspace boils down to the same orderly_ Kernel methods
used by ACPI to handle similar shutdown requests.

As a part of the series, patch 1/3 enforces, at the SCMI core level, the
creation of one single SCMI SystemPower device, to avoid promoting the
design of systems in which multiple SCMI platforms can advertise the
concurrent support of SystemPower protocol: when multiple SCMI platform
are defined, only one of them should be in charge of SystemPower comms
with the OSPM, so only one such SystemPower device across all platforms
is allowed to be created.

The series has been rebased in v5 on top of:

https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/

since this last series about SCMI modularization carries also a few changes
in the SCMI interface exposed to drivers like this one.

This whole series, rebased as above specified, can be found (with some messy
DEBUG patches on top) at [1].

Thanks

Cristian

[1]: https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_system_power_control_ext_V5

---
v4 --> v5
 - rebased on SCMI Modules v5 series to use new SCMI protocols interface
 - removed signal based shutdown/reboot
 - removed all module parameters
 - added 60secs fixed timeout to shutdwon/reboot requests
 - make it modularizable to cope with SCMI core modularization
 - refactored all data config structs
 - using dev_* instead of pr_*

v3 --> v4
 - rebased v5.11-rc2
 - removed unneeded ugly usage of atomics and barriers
 - simplfied SysPower shutdown state machine
 - split out macro definition to different patch

v2 --> v3
 - rebased
 - some minor cleanup in codestyle and commit message

v1 --> v2
 - split out of SCMI System Power Protocol series now merged

Cristian Marussi (3):
  firmware: arm_scmi: support only one single SystemPower device
  firmware: arm_scmi: add System Power utility macro
  firmware: arm_scmi: add SCMI System Power Control driver

 drivers/firmware/Kconfig                      |  12 +
 drivers/firmware/arm_scmi/Makefile            |   1 +
 drivers/firmware/arm_scmi/bus.c               |  25 ++
 .../firmware/arm_scmi/scmi_power_control.c    | 347 ++++++++++++++++++
 include/linux/scmi_protocol.h                 |   1 +
 5 files changed, 386 insertions(+)
 create mode 100644 drivers/firmware/arm_scmi/scmi_power_control.c

-- 
2.17.1