From: Cristian Marussi <cristian.marussi@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, Ludvig.Parsson@axis.com, cristian.marussi@arm.com Subject: [PATCH 0/9] Rework SCMI initialization and probing sequence Date: Thu, 22 Dec 2022 18:50:40 +0000 [thread overview] Message-ID: <20221222185049.737625-1-cristian.marussi@arm.com> (raw) 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
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, Ludvig.Parsson@axis.com, cristian.marussi@arm.com Subject: [PATCH 0/9] Rework SCMI initialization and probing sequence Date: Thu, 22 Dec 2022 18:50:40 +0000 [thread overview] Message-ID: <20221222185049.737625-1-cristian.marussi@arm.com> (raw) 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-12-22 18:51 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-22 18:50 Cristian Marussi [this message] 2022-12-22 18:50 ` [PATCH 0/9] Rework SCMI initialization and probing sequence Cristian Marussi 2022-12-22 18:50 ` [PATCH 1/9] firmware: arm_scmi: Simplify chan_available transport operation Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 2/9] firmware: arm_scmi: Use dedicated devices to initialize channels Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 3/9] firmware: arm_scmi: Move protocol registration helpers Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 4/9] firmware: arm_scmi: Add common notifier helpers Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 5/9] firmware: arm_scmi: Refactor protocol device creation Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 6/9] firmware: arm_scmi: Move handle get/set helpers Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 7/9] firmware: arm_scmi: Refactor device create/destroy helpers Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 8/9] firmware: arm_scmi: Introduce a new lifecycle for protocol devices Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-22 18:50 ` [PATCH 9/9] firmware: arm_scmi: Split bus and driver into distinct modules Cristian Marussi 2022-12-22 18:50 ` Cristian Marussi 2022-12-23 5:36 ` [PATCH 0/9] Rework SCMI initialization and probing sequence Sumit Garg 2022-12-23 5:36 ` Sumit Garg 2022-12-23 11:37 ` Cristian Marussi 2022-12-23 11:37 ` Cristian Marussi 2022-12-26 13:54 ` Sumit Garg 2022-12-26 13:54 ` Sumit Garg 2023-01-19 19:31 ` Sudeep Holla 2023-01-19 19:31 ` Sudeep Holla
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221222185049.737625-1-cristian.marussi@arm.com \ --to=cristian.marussi@arm.com \ --cc=Ludvig.Parsson@axis.com \ --cc=etienne.carriere@linaro.org \ --cc=f.fainelli@gmail.com \ --cc=james.quinlan@broadcom.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=sudeep.holla@arm.com \ --cc=vincent.guittot@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.