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: <20241021170726.2564329-1-cristian.marussi@arm.com>
Date: Mon, 21 Oct 2024 18:07:21 +0100
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>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>
Subject: [PATCH v2 0/5] 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.

Any feedback welcome.

Thanks,
Cristian

---
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 (5):
  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

 .../bindings/firmware/arm,scmi.yaml           | 15 +++++++
 drivers/firmware/arm_scmi/common.h            | 11 ++++-
 drivers/firmware/arm_scmi/driver.c            | 42 +++++++++++--------
 drivers/firmware/arm_scmi/shmem.c             |  7 ++++
 .../firmware/arm_scmi/transports/mailbox.c    |  4 +-
 drivers/firmware/arm_scmi/transports/optee.c  |  2 +-
 drivers/firmware/arm_scmi/transports/smc.c    |  4 +-
 drivers/firmware/arm_scmi/transports/virtio.c | 15 +++----
 8 files changed, 71 insertions(+), 29 deletions(-)

-- 
2.46.1


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ