[RFC,0/3] Introduce SCMI Quirks framework

Message

Cristian Marussi April 1, 2025, 12:25 p.m. UTC

Hi,

with the increasing adoption of SCMI across arm64 ecosystems, we have to
start considering how to deal and take care of out-of-spec SCMI firmware
platforms that are actively deployed in the wild, in a consistent manner.

This small series introduces a simple framework, based on static_keys,
that allows a user to:

- define a quirk and its matching conditions; quirks can match based on:

  	compatible / Vendor_ID / Sub_Vendor_ID / ImplVersion

  from the longest matching sequence down to the shortest.

  When the SCMI core stack boots it will enable the matching quirks
  depending on the information gathered from the platform via Base
  protocol: any NULL/0 match condition is ignored during matching and is
  interpreted as ANY, so you can decide to match on a very specific
  combination of compatibles and FW versions OR simply on a compatible.

- define a quirk code-block: simply a block of code, meant to play the
  magic quirk trick, defined in the proximity of where it will be used
  and gated by an implicit quirk static-key associated with the defined
  quirk

Patch 1/3 in the series is really unrelated to the Quirk framework
itself: it is a slight variation on a fix posted previously by Sibi around
PERF FastChannels and it is included here for simplicity, since the example
quirk provided later in this series has to be applied exactly where 1/3
applies its modifications.

Patch 2/3 introduces support for SCMI quirks: support is default-n in
Kconfig as of this series. All the quirks found defined are stored in
an hashtable at module initialization time.
Later on, when the SCMI core stack probes and it has retrieved basic info
via Base protocol, all the matching quirks are enabled, which simply means
the related underlying specific quirks static-keys are enabled.

Patch 3/3 introduces an example Quirk for a known problem on a known
platform as reported by Johan, Marc and Sibi, BUT note that the matching
condition in tha patch MUST be properly completed in the patch (I was not
sure what to use...see my comments)

All of this as an RFC since:

- the provided macro-salad to enable quirks definitions is certainly
  ugly and can be done better (and checkpatch is already complaining
  a bit...)...or maybe I should just get rid of macros

- proper Documentation is missing...I wanted to have some feedback
  before babbling out too much non-sense just in case all of this has
  to go straight to the bin...

- macthing logic can be simplfied probably

Any feedback and testing is very much welcome.

Thanks,
Cristian


Cristian Marussi (2):
  firmware: arm_scmi: Add Quirks framework
  [NOT FOR UPSTREAM] firmware: arm_scmi: quirk: Ignore FC bit in
    attributes

Sibi Sankar (1):
  firmware: arm_scmi: Ensure that the message-id supports fastchannel

 drivers/firmware/arm_scmi/Kconfig     |  12 ++
 drivers/firmware/arm_scmi/Makefile    |   1 +
 drivers/firmware/arm_scmi/base.c      |  14 ++
 drivers/firmware/arm_scmi/driver.c    |  87 +++++++-----
 drivers/firmware/arm_scmi/protocols.h |   2 +
 drivers/firmware/arm_scmi/quirks.c    | 194 ++++++++++++++++++++++++++
 drivers/firmware/arm_scmi/quirks.h    |  43 ++++++
 7 files changed, 320 insertions(+), 33 deletions(-)
 create mode 100644 drivers/firmware/arm_scmi/quirks.c
 create mode 100644 drivers/firmware/arm_scmi/quirks.h