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: Wed, 14 Feb 2024 18:29:59 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Cc: sudeep.holla@....com,
	james.quinlan@...adcom.com,
	f.fainelli@...il.com,
	vincent.guittot@...aro.org,
	peng.fan@....nxp.com,
	michal.simek@....com,
	quic_sibis@...cinc.com,
	quic_nkela@...cinc.com,
	souvik.chakravarty@....com,
	Cristian Marussi <cristian.marussi@....com>
Subject: [PATCH 0/7] SCMI V3.2 Misc updates

Hi,

another round of updates related to the last v3.2 SCMI spec, mostly around
Clock protocol.

Note that the series is based on sudeep/for-next/scmi/updates on top of

  7dd3d11f4dac ("clk: scmi: Add support for forbidden clock state controls")

and patch [1/7], which was included in the recently posted [1], it is
included also here just for ease of usage. (since needed also here ofc)

Having said that, [2/7] add a centralized support to the SCMI core to
handle v3.2 optional protocol version negotiation, so that at protocol
initialization time, mif the platform advertised version is newer than
supported by the kernel and protocol version negotiation is supported,
the SCMI core will attempt to negotiate an older protocol version.

Patches 3,4,5 adds the remaining last missing bits of Clock v3.2 protocol
and bumps the supported protocol version to 0x30000 (v3.2).

On top of these new SCMI additions, [6/7] reworks at first slightly how the
clk-scmi driver configures per-clock CLK ops, and then [7/7] adds support
for clock get/set duty cycle, as allowed by the last v3.2 spec additions,
but only if the related SCMI clk domain supports that specific clock
permissions.

Thanks,
Cristian

[1]: https://lore.kernel.org/linux-arm-kernel/20240212123233.1230090-3-cristian.marussi@arm.com/
---

Cristian Marussi (7):
  firmware: arm_scmi: Add a common helper to check if a message is
    supported
  firmware: arm_scmi: Add support for v3.2 NEGOTIATE_PROTOCOL_VERSION
  firmware: arm_scmi: Add Clock check for extended config support
  firmware: arm_scmi: Add standard Clock OEM definitions
  firmware: arm_scmi: Update supported Clock protocol version
  clk: scmi: Allocate CLK operations dynamically
  clk: scmi: Support get/set duty_cycle operations

 drivers/clk/clk-scmi.c                | 168 +++++++++++++++++---------
 drivers/firmware/arm_scmi/clock.c     |  67 +++++++---
 drivers/firmware/arm_scmi/driver.c    |  99 ++++++++++++++-
 drivers/firmware/arm_scmi/protocols.h |   5 +
 include/linux/scmi_protocol.h         |  15 ++-
 5 files changed, 270 insertions(+), 84 deletions(-)

-- 
2.43.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ