linux-kernel - [PATCH v3 0/7] Expose SCMI Transport properties

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: <20241028120151.1301177-1-cristian.marussi@arm.com>
Date: Mon, 28 Oct 2024 12:01:44 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	arm-scmi@...r.kernel.org
Cc: sudeep.holla@....com,
	james.quinlan@...adcom.com,
	f.fainelli@...il.com,
	vincent.guittot@...aro.org,
	etienne.carriere@...com,
	peng.fan@....nxp.com,
	michal.simek@....com,
	quic_sibis@...cinc.com,
	quic_nkela@...cinc.com,
	dan.carpenter@...aro.org,
	Cristian Marussi <cristian.marussi@....com>
Subject: [PATCH v3 0/7] Expose SCMI Transport properties

Hi,

SCMI transports are characterized by a number of properties: the values
assumed by some of them tightly depend on the choices taken at design
time and on the overall archiecture of the specific platform: things like
timeouts, maximum message size and number of in-flight messages are closely
tied to the architecture of the platform like number of SCMI agents on the
system, physical memory available to the SCMI server...so on and so forth.

Moreover, since the SCMI specification does not delve into the details
of specific transports, that are, indeed, outside the scope of the
specification itself, such characteristics are NOT even discoverable
at run-time on an SCMI platform.

Currently such properties are simple default values defined at build time,
but the increasing number and variety of platforms using SCMI with a wide
range of designs has increased the need to have a way to describe such
properties across all these platforms.

This series, at first removes a few ambiguities in how some of the current
built-in properties are interpreted, then lays out a way for the core to
propagate back to the transports any possible setting gathered at runtime
from devicetree and finally introduce a pair of new properties used to
describe such per-platform transport characteristics.

Based on v6.12-rc3.

V3 adds 2 additional patches to fix an already existing similar property
that was missing the vendor prefix.

Any feedback welcome.

Thanks,
Cristian

---
v2 --> v3
- unified SHMEM_PAYLOAD_SIZE definition
- fixed format-string
- added reviewed tags
- added missing vendor to existing max-rx-timeout-ms
v1 --> v2
- added arm, vendor prefix to new DT bindings props
- clarified arm,max-msg bindings meaning
- removed useless warning on advised minimum size on arm,max-msg-size
- fixed maintainers CC list
- removed CCed maintainers from commit log
- using new prefixed arm, props

Cristian Marussi (7):
  firmware: arm_scmi: Account for SHMEM memory overhead
  firmware: arm_scmi: Calculate virtio PDU max size dynamically
  dt-bindings: firmware: arm,scmi: Introduce more transport properties
  firmware: arm_scmi: Use max_msg and max_msg_size devicetree properties
  firmware: arm_scmi: Relocate atomic_threshold to scmi_desc
  dt-bindings: firmware: arm,scmi: Add missing vendor string
  firmware: arm_scmi: Use vendor string in max-rx-timeout-ms

 .../bindings/firmware/arm,scmi.yaml           | 17 ++++++-
 drivers/firmware/arm_scmi/common.h            | 13 +++++-
 drivers/firmware/arm_scmi/driver.c            | 46 +++++++++++--------
 drivers/firmware/arm_scmi/shmem.c             |  7 +++
 .../firmware/arm_scmi/transports/mailbox.c    |  2 +-
 drivers/firmware/arm_scmi/transports/optee.c  |  8 ++--
 drivers/firmware/arm_scmi/transports/smc.c    |  2 +-
 drivers/firmware/arm_scmi/transports/virtio.c | 15 +++---
 8 files changed, 74 insertions(+), 36 deletions(-)

-- 
2.47.0