From patchwork Sun Jul 7 00:20:47 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cristian Marussi X-Patchwork-Id: 13725932 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 7F3B2C2BD09 for ; Sun, 7 Jul 2024 00:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=iq3+u/KJPyfe+Go5KRzPrF+6hN4jw4RV5rmJu/QWDjQ=; b=wEUdGhV9iG1dnAgkqXSZrbM7EX BoyAIwmU6NKJK3NbcQaihloc2IrvrmiZQyJf0ojVrUwYWeRAysO7JV0FdKWzJSGkOLsp58WSO7cUi P3pAjBvFGVAI7RChiHJH5oA0V4fHQiUDi3vrogUMIGME62cX+N5MxrhXGHzKx1cxgVasIWJf9c4IG EffcZUfHGHtolKaF+tHeIfxN6DF83i5E0ga7KtYKywHmm0e2bSx4yImB+8AFm7naZUWcfRwI68neu WBl+e3+VPQSz3L7rMVLxxh3AbxW63XAJ5HEVZ6ubg9NInyk8Up1l7Ktg1+gOAlRNl1xq5AR9r6F0H 6ACSymRA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sQFf5-000000018Fs-3Bo2; Sun, 07 Jul 2024 00:21:51 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sQFer-000000018AK-0MAx for linux-arm-kernel@lists.infradead.org; Sun, 07 Jul 2024 00:21:39 +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 1CAB0DA7; Sat, 6 Jul 2024 17:21:58 -0700 (PDT) Received: from pluto.. (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B756A3F73B; Sat, 6 Jul 2024 17:21:29 -0700 (PDT) From: Cristian Marussi To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com, f.fainelli@gmail.com, vincent.guittot@linaro.org, etienne.carriere@foss.st.com, peng.fan@oss.nxp.com, michal.simek@amd.com, quic_sibis@quicinc.com, quic_nkela@quicinc.com, ptosi@google.com, dan.carpenter@linaro.org, souvik.chakravarty@arm.com, Cristian Marussi Subject: [PATCH 0/8] Make SCMI transport as standalone drivers Date: Sun, 7 Jul 2024 01:20:47 +0100 Message-ID: <20240707002055.1835121-1-cristian.marussi@arm.com> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240706_172137_250754_85F74E89 X-CRM114-Status: GOOD ( 16.99 ) 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 all, SCMI transport layer was till now being embedded built into in the core SCMI stack. Some of these transports, despite being currently part of the main SCMI module, are indeed also registered with different subsystems like optee or virtio, and actvely probed also by those: this led to a few awkward and convoluted tricks to properly handle such interactions at boot time in the SCMI stack. Moreover some partner expressed the desire to be able to fully modularize the transports components. This series aim to make all such transports as standalone drivers that can be optionally loaded as modules. In order to do this, at first some new mechanism is introduced to support this new capability while maintaining, in parallel, the old legacy embedded transports; then each transport, one by one, is transitioned to be a standalone driver and finally the old legacy support for embedded transport is removed. Patch [1/8] is a mostly unrelated (but much needed) clean-up from Peng, which I included in this series to avoid conflicts at merge. Patch [2/8] simply collects the existing datagram manipulation helpers in a pair of function pointers structures, in preparation for later reworks. Patch [3/8] adds the bulk of the new logic to the core SCMI stack and then each existing transport is transitioned to be a standalone driver in patches 4,5,6,7 while shuffling around the compatibles. (no DT change is needed of curse for backward compatibility) While doing this I kept the module authorship in line with the main author(S) as spitted out by git-blame. Finally patch [8/8] removes all the legacy dead code from the core SCMI stack. No new symbol EXPORT has been added. The new transport drivers have been tested, as built-in and LKM, as follows: - mailbox on JUNO - virtio on emulation - optee on QEMU/optee using Linaro setup Exercised using the regular SCMI drivers stack and the SCMI ACS suite, testing commands, replies, delayed responses and notification. Multiple virtual SCMI instances support has been tested too. SMC has NOT been tested/exercised at run-time, only compile-tested. (due to lack of hardware) Note that in this new setup, all the probe deferral and retries between the SCMI core stack and the transports has been removed, since no more needed. Moreover the new drivers have been tested also with a fully modularized SCMI stack, i.e.: scmi-core.ko + scmi-module.ko + scmi_transport_*.ko [ + vendor modules ] One thing that I have NOT done still, but that it's an easy pick, would be to completely remove any dependency between the SCMI core stack and the transports, leaving these latter only dependent on the mere presence of the related subsystems like optee/virtio/mailbox/smc: this would allow to compile the transports and the related subsys as built-in while keeping the core SCMI stack as a module....not sure if it makes sense... but it can be already easily done by simply patching further the Kconfig. Based on sudeep/for-next/scmi/updates. Any feedback, and especially testing (:D) is welcome. Thanks, Cristian Cristian Marussi (7): firmware: arm_scmi: Introduce packet handling helpers firmware: arm_scmi: Add support for standalone transport drivers firmware: arm_scmi: Make MBOX transport a standalone driver firmware: arm_scmi: Make SMC transport a standalone driver firmware: arm_scmi: Make OPTEE transport a standalone driver firmware: arm_scmi: Make VirtIO transport a standalone driver firmware: arm_scmi: Remove legacy transport-layer code Peng Fan (1): firmware: arm_scmi: Introduce setup_shmem_iomap drivers/firmware/arm_scmi/Kconfig | 20 +- drivers/firmware/arm_scmi/Makefile | 9 +- drivers/firmware/arm_scmi/common.h | 183 +++++++++++++----- drivers/firmware/arm_scmi/driver.c | 140 +++++--------- drivers/firmware/arm_scmi/msg.c | 34 +++- .../{mailbox.c => scmi_transport_mailbox.c} | 69 ++++--- .../{optee.c => scmi_transport_optee.c} | 120 +++++------- .../arm_scmi/{smc.c => scmi_transport_smc.c} | 52 ++--- .../{virtio.c => scmi_transport_virtio.c} | 95 +++++---- drivers/firmware/arm_scmi/shmem.c | 80 ++++++-- 10 files changed, 445 insertions(+), 357 deletions(-) rename drivers/firmware/arm_scmi/{mailbox.c => scmi_transport_mailbox.c} (87%) rename drivers/firmware/arm_scmi/{optee.c => scmi_transport_optee.c} (89%) rename drivers/firmware/arm_scmi/{smc.c => scmi_transport_smc.c} (88%) rename drivers/firmware/arm_scmi/{virtio.c => scmi_transport_virtio.c} (95%)