Merge tag 'scmi-updates-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep...

Merge tag 'scmi-updates-6.3' of git://git./linux/kernel/git/sudeep.holla/linux into soc/drivers

Arm SCMI updates for v6.3

The main addition is a unified userspace interface for SCMI irrespective
of the underlying transport and along with some changed to refactor the
SCMI stack probing sequence.

1. SCMI unified userspace interface

   This is to have a unified way of testing an SCMI platform firmware
   implementation for compliance, fuzzing etc., from the perspective of
   the non-secure OSPM irrespective of the underlying transport supporting
   SCMI. It is just for testing/development and not a feature intended fo
   use in production.

   Currently an SCMI Compliance Suite[1] can only work by injecting SCMI
   messages using the mailbox test driver only which makes it transport
   specific and can't be used with any other transport like virtio,
   smc/hvc, optee, etc. Also the shared memory can be transport specific
   and it is better to even abstract/hide those details while providing
   the userspace access. So in order to scale with any transport, we need
   a unified interface for the same.

   In order to achieve that, SCMI "raw mode support" is being added through
   debugfs which is more configurable as well. A userspace application
   can inject bare SCMI binary messages into the SCMI core stack; such
   messages will be routed by the SCMI regular kernel stack to the backend
   platform firmware using the configured transport transparently. This
   eliminates the to know about the specific underlying transport
   internals that will be taken care of by the SCMI core stack itself.
   Further no additional changes needed in the device tree like in the
   mailbox-test driver.

[1] https://gitlab.arm.com/tests/scmi-tests

2. Refactoring of the SCMI stack probing sequence

   On some platforms, SCMI transport can be provide by OPTEE/TEE which
   introduces certain dependency in the probe ordering. In order to address
   the same, the SCMI bus is split into its own module which continues to
   be initialized at subsys_initcall, while the SCMI core stack, including
   its various transport backends (like optee, mailbox, virtio, smc), is
   now moved into a separate module at module_init level.

   This allows the other possibly dependent subsystems to register and/or
   access SCMI bus well before the core SCMI stack and its dependent
   transport backends.

* tag 'scmi-updates-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (31 commits)
  firmware: arm_scmi: Clarify raw per-channel ABI documentation
  firmware: arm_scmi: Add per-channel raw injection support
  firmware: arm_scmi: Add the raw mode co-existence support
  firmware: arm_scmi: Call raw mode hooks from the core stack
  firmware: arm_scmi: Reject SCMI drivers when configured in raw mode
  firmware: arm_scmi: Add debugfs ABI documentation for raw mode
  firmware: arm_scmi: Add core raw transmission support
  firmware: arm_scmi: Add debugfs ABI documentation for common entries
  firmware: arm_scmi: Populate a common SCMI debugfs root
  debugfs: Export debugfs_create_str symbol
  include: trace: Add platform and channel instance references
  firmware: arm_scmi: Add internal platform/channel identifiers
  firmware: arm_scmi: Move errors defs and code to common.h
  firmware: arm_scmi: Add xfer helpers to provide raw access
  firmware: arm_scmi: Add flags field to xfer
  firmware: arm_scmi: Refactor scmi_wait_for_message_response
  firmware: arm_scmi: Refactor polling helpers
  firmware: arm_scmi: Refactor xfer in-flight registration routines
  firmware: arm_scmi: Split bus and driver into distinct modules
  firmware: arm_scmi: Introduce a new lifecycle for protocol devices
  ...

Link: https://lore.kernel.org/r/20230120162152.1438456-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>