From mboxrd@z Thu Jan 1 00:00:00 1970 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 B7D39C48BEB for ; Thu, 22 Feb 2024 09:20:54 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ddU0bDKg4ZzwAKJfdHTprGyNWNqD+wMKD3hMynxQk+g=; b=w6UHk3utHu0INO f4mKnVC/s1bae6zwhEOwfnjlR/XsIQ/SDZhUrLzxmaFpNCLfekyNxQN7ACwT9oY8JEEQy5Lzlu0BO wN+ebhdEsTUz/0qh3WDCZZlwwL+MeWe2wq2OhVptrr4kiSul9bu+GX5y/QQ/Do4fQf16dpQlLhjMT 7P+S/wK5/08Sifgd+WxIJCIXN8ldgYVHmy/ZPjfn8A2egh1cl9HkYiVV/dGNsd87Y0pmaZbQbogBx 0LVquNEqhkHIeELC2MQa3v1JLnGr0vCVoAtvN5ZuKmI63xsDQYARv8uDnmgg3hV9iPdY4S8V1lZ8j MlPZjXeQqkk7N1OCvprQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rd5Fz-00000004Cq3-411x; Thu, 22 Feb 2024 09:20:43 +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 1rd5Fy-00000004Cpe-0KJR for linux-arm-kernel@lists.infradead.org; Thu, 22 Feb 2024 09:20:43 +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 71B471007; Thu, 22 Feb 2024 01:21:14 -0800 (PST) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 891273F766; Thu, 22 Feb 2024 01:20:34 -0800 (PST) Date: Thu, 22 Feb 2024 09:20:32 +0000 From: Cristian Marussi To: "Peng Fan (OSS)" Cc: "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "sudeep.holla@arm.com" , "james.quinlan@broadcom.com" , "f.fainelli@gmail.com" , "vincent.guittot@linaro.org" , "michal.simek@amd.com" , "quic_sibis@quicinc.com" , "quic_nkela@quicinc.com" , "souvik.chakravarty@arm.com" Subject: Re: [PATCH] firmware: arm_scmi: Add support for multiple vendors custom protocols Message-ID: References: <20240221220426.1205146-1-cristian.marussi@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240222_012042_178699_067990E3 X-CRM114-Status: GOOD ( 15.49 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 22, 2024 at 08:32:05AM +0000, Peng Fan (OSS) wrote: > Hi Cristian, > > > Subject: [PATCH] firmware: arm_scmi: Add support for multiple vendors > > custom protocols > > Do you have an example how to test this? Could this be used for pinctrl imx? Hi Peng, as an example usecase for this, you can consider your upcoming series which adds 2 NXP SCMI vendor protocol (which I hope to review today) that you numbered as 0x81, 0x84: in order to avoid clashes with other vendors potentially registering in the future their own vendor protocols while using the same numbers as yours, you will have to add a vendor_id string specification to your scmi_protocol definition, so that it matches the vendor_id string reported by your SCMI server at runtime via the Base protocol. This mechanism basically allows a vendor to own the whole space of vendor protocols numbers, since the numbers are really now referred to a specific vendor namespace at runtime. You can also optionally add a sub_vendor_id and implementation version if you want to use different protocols of you own with the same number but different capabilties on different platform of yours...but I am doubtful about the opprtunity of this further customization...lets see what the review process bring up... BUT, all of this stands true for custom vendor protocols, pinctrl-imx does use the standard 0x19 Pinctrl protocol, and the clash is really on the device node underlying the device which is created...re-implementing and duplicating fully a std protocol as a vendor one, just with a different number to workaround this issue it is not something can go upstream... ...so at this point you will be better off with just that couple of downstream pinctrl-imx patches that you have, until we get creative and found a better way to support your specific usecase...or you move to the generic Linux Pinctrl subsystem that is supported by the pinctrl-scmi driver originally by Oleksii (but I understand this is problematic for you in other ways too...) Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel