From patchwork Mon Apr 8 09:30:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cristian Marussi X-Patchwork-Id: 13620874 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 46672CD128A for ; Mon, 8 Apr 2024 09:32:16 +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=4k/O88gsj++LGfKyhMkC1UuMIKRGjDP0yHoDW7c3JkE=; b=Qf/O/ilMJ2sQhX Fz4thHUocEyp12aG1NM2Gh8Op2BF9hT5eW/VAiVOeSfLxRKdd3N/F8mMitQ8chizhsASxn/BE4oKs e1b1UujxWdx+QRsUoz9VBceIS04P1xA+yAcfOS06khz4SQJWWgfekke929tj69RpWTANAUSHAcdvb jPdtpPR3/zmGCtjW1Kzm/1TNUfUDd4iJtb623BEky4qVQskG+xxhD9ksDhp20scnZs7G9Z0CWRt/R fpRz+RNwsZgNzzreUk9pIYKX9Bvym03YVQrCq4GPgYbniExaG7Zxotwn2I6ORowXnzFiT8beWj20r vwouZxqxpYWuqbjONmWg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rtlM7-0000000F6Qx-0fZd; Mon, 08 Apr 2024 09:31:59 +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 1rtlM3-0000000F6Or-0WiD for linux-arm-kernel@lists.infradead.org; Mon, 08 Apr 2024 09:31:57 +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 6444B1007; Mon, 8 Apr 2024 02:32:21 -0700 (PDT) Received: from pluto.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 41BAB3F766; Mon, 8 Apr 2024 02:31:49 -0700 (PDT) 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, vincent.guittot@linaro.org, peng.fan@oss.nxp.com, michal.simek@amd.com, quic_sibis@quicinc.com, konrad.dybcio@linaro.org, souvik.chakravarty@arm.com, Cristian Marussi Subject: [PATCH v2 0/2] SCMI multiple vendor protocol support Date: Mon, 8 Apr 2024 10:30:50 +0100 Message-ID: <20240408093052.3801576-1-cristian.marussi@arm.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240408_023155_353894_0459DF2D X-CRM114-Status: GOOD ( 13.92 ) 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, this is meant to address the possibility of having multiple vendors implementing distinct SCMI vendor protocols with possibly the same overlapping protocol number without the need of crafting the Kconfig at compile time to include only wanted protos Basic idea is simple: - vendor protos HAS to be 'tagged' at build time with a vendor_id - vendor protos COULD also optionally be tagged at build time with sub_vendor_id and implementation version - at init all the build vendor protos are registered with the SCMI core using a key derived from the above tags - at SCMI probe time the platform is identified via Base protocol as usual and all the required vendor protos (i.e. IDs defined in the DT as usual) are loaded (if required) after a lookup process based on the following rules: + protocol DB is searched using the platform/Base runtime provided tags / / using the following search logic (keys), first match: 1. proto_id / / / 2. proto_id / / / 0 3. proto_id / / NULL / 0 IOW, closest match, depending on how much fine grained is your protocol tuned (tagged) for the platform. I am still doubtful about the usage of , and tempted to drop it since we have anyway protocol version and NEGOTIATE_PROTOCOL_VERSION to deal with slight difference in fw revision... In V2 a dedicated vendors dir/Makefile/Kconfig is added: not sure if we want to provide also a way of grouping SCMI vendor protocol headers under include/linux...open to any suggestion/opinion. Based on sudeep/for-next/scmi/updates on top of commit dccc943c8953 ("clk: scmi: Support get/set duty_cycle operations") Any feedback welcome Thanks, Cristian --- v1 -> v2 - added a dedicated vendors/ directory and Kconfig under arm_scmi/ Cristian Marussi (2): firmware: arm_scmi: Add support for multiple vendors custom protocols firmware: arm_scmi: Add dedicated vendor protocols submenu drivers/firmware/arm_scmi/Kconfig | 2 + drivers/firmware/arm_scmi/Makefile | 1 + drivers/firmware/arm_scmi/driver.c | 165 ++++++++++++++++++--- drivers/firmware/arm_scmi/protocols.h | 15 ++ drivers/firmware/arm_scmi/vendors/Kconfig | 4 + drivers/firmware/arm_scmi/vendors/Makefile | 2 + 6 files changed, 167 insertions(+), 22 deletions(-) create mode 100644 drivers/firmware/arm_scmi/vendors/Kconfig create mode 100644 drivers/firmware/arm_scmi/vendors/Makefile