From patchwork Thu Dec 22 18:50:40 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cristian Marussi X-Patchwork-Id: 13080225 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5F809C4332F for ; Thu, 22 Dec 2022 18:52:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=szYU9x6NcLPmFM0aHu5DbOUY65s8Pr9oYI7tLGUxqvw=; b=QvOWDc+PjbsEpk 3P0QFmPZPLon4TyxdPQ9sEkAwOM9VVtKbIzO0r/EBcPyIfcQYwngoZtralhVi+URt0AYnDXtnHNH6 JsF3MZID+cbQlzaWwOx+Db4FtkgTjCeGelqIr7pxgQ/p4+D/MSwNFfFU0D9ifJ7mtvZU3ArUn6cgH oZgfqgPE7RoV6urfVTKEVF6KPyg8DtkaKHRymp9IKiQfkjTIqz8v2BGLyyq1LptwwWqacxuedXsgj KFbqEU/pT1qOS4a23LLtt+qx/Zti50ZSSD4PmE2O79DIXv1pVu6aln+EjZbyEy7KDbKl9hfNH0Eyv bHrm0xrMmeF/qWON/DYQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8Qf6-00FdLA-J6; Thu, 22 Dec 2022 18:51:24 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8Qep-00Fd9m-Aa for linux-arm-kernel@lists.infradead.org; Thu, 22 Dec 2022 18:51:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6EE691FB; Thu, 22 Dec 2022 10:51:46 -0800 (PST) Received: from e120937-lin.. (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 130843FA32; Thu, 22 Dec 2022 10:51:03 -0800 (PST) From: Cristian Marussi 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 Message-Id: <20221222185049.737625-1-cristian.marussi@arm.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221222_105107_448313_943D8176 X-CRM114-Status: GOOD ( 10.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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(-)