linux-kernel - [PATCH 0/9] Rework SCMI initialization and probing sequence

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20221222185049.737625-1-cristian.marussi@arm.com>
Date:   Thu, 22 Dec 2022 18:50:40 +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, etienne.carriere@...aro.org,
        vincent.guittot@...aro.org, Ludvig.Parsson@...s.com,
        cristian.marussi@....com
Subject: [PATCH 0/9] Rework SCMI initialization and probing sequence

Hi,

under some configurations the SCMI core stack, which is now initialized
as a whole at the subsys_initcall level, can be dependent on some other
Kernel subsystems (like TEE) when some SCMI transport backend like optee
is used.

This has been reported to lead to some awkward probe loop which, even
though successful at the end, leaves a track of errors in the logs coming
directly from the core Linux driver model facilities.

In order to solve this issue and cleaning up a bit the SCMI stack startup
sequence, this small series reviews and reworks the SCMI core stack
initialization and probe logic.

Basically the SCMI Bus is split into its own module (scmi-core.ko) which is
initialized at subsys_initcall, while the SCMI core stack, including its
various transport backends (like optee, mailbox, virtio, smc), is kept into
a distinct module (scmi-module.ko) which get initialized at module_init.

The SCMI driver users initlevel, instead, remains unchanged at module_init.

No change is made to the Kconfig: the main ARM_SCMI_PROTOCOL option will
now cause both modules to be built.

This allows the other possibly needed subsystems to be up and running
well before the core SCMI stack and its dependent transport backends, so
solving the reported issue.

Tested with SCMI transports mailbox/virtio and, in a previous draft, optee,
in a number of different load/unload/bind/unbind combinations both as
builtin and as LKMs.

Applies on v6.1.

Any feedback, testing welcome.

Thanks,
Cristian

Cristian Marussi (9):
  firmware: arm_scmi: Simplify chan_available transport operation
  firmware: arm_scmi: Use dedicated devices to initialize channels
  firmware: arm_scmi: Move protocol registration helpers
  firmware: arm_scmi: Add common notifier helpers
  firmware: arm_scmi: Refactor protocol device creation
  firmware: arm_scmi: Move handle get/set helpers
  firmware: arm_scmi: Refactor device create/destroy helpers
  firmware: arm_scmi: Introduce a new lifecycle for protocol devices
  firmware: arm_scmi: Split bus and driver into distinct modules

 drivers/firmware/arm_scmi/Makefile  |   8 +-
 drivers/firmware/arm_scmi/bus.c     | 388 ++++++++++++-----
 drivers/firmware/arm_scmi/common.h  |  25 +-
 drivers/firmware/arm_scmi/driver.c  | 623 ++++++++++++++--------------
 drivers/firmware/arm_scmi/mailbox.c |   6 +-
 drivers/firmware/arm_scmi/optee.c   |   6 +-
 drivers/firmware/arm_scmi/smc.c     |   6 +-
 drivers/firmware/arm_scmi/virtio.c  |   4 +-
 include/linux/scmi_protocol.h       |   5 -
 9 files changed, 622 insertions(+), 449 deletions(-)

-- 
2.34.1