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

Open Source and information security mailing list archives

Message-ID: <CAFA6WYP++tYORr+-EDPF1EKakwJHaH+_WFq8kzWY-UU3yQJ7Gg@mail.gmail.com>
Date:   Fri, 23 Dec 2022 11:06:29 +0530
From:   Sumit Garg <sumit.garg@...aro.org>
To:     Cristian Marussi <cristian.marussi@....com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        sudeep.holla@....com, james.quinlan@...adcom.com,
        f.fainelli@...il.com, etienne.carriere@...aro.org,
        vincent.guittot@...aro.org, Ludvig.Parsson@...s.com
Subject: Re: [PATCH 0/9] Rework SCMI initialization and probing sequence

On Fri, 23 Dec 2022 at 00:22, Cristian Marussi <cristian.marussi@....com> wrote:
>
> 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.

Thanks Cristian for the rework, but this doesn't seem to address
reluctance to carry forward the DT legacy (see [1]).

TLDR, it has led to misrepresentation of OP-TEE transport as follows:

    First represented as a platform device via DT (compatible =
"linaro,scmi-optee";) and then
    Migrated to being a TEE bus device (UUID: 0xa8cfe406, 0xd4f5,
0x4a2e, 0x9f, 0x8d, 0xa2, 0x5d, 0xc7, 0x54, 0xc0, 0x99)

Do we really need to have a platform device for every SCMI transport?

[1] https://lore.kernel.org/lkml/CAFA6WYPwku8d7EiJ8rF5pVh568oy+jXMXLdxSr6r476e0SD2nw@mail.gmail.com/

-Sumit

>
> 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
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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