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 260AAC27C4F for ; Wed, 26 Jun 2024 11:04:37 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SEIaYS7uSR/XA5nYt6dvXNgZJh0x2ozPHXwbB3Bzkyk=; b=0Ua2a1QEwXwVWgzkLwBokmnL1I D0hNJpz3f+nMQ+HwlJSEBB3ODIoVY6Y1IpuiL2wWTjcUzfSzYPEia0GTsrkbi4vEu5cpzzpOyqzRe vOjP87M2H0GNUQMUtS0EDv6pjfaBQVl2iuqtPQZa+P1ex6e/FD9abv4BQZt7HiZz2gn6AlADodwRi RaKktd3UBysdg37zbUq9dtDxd0wdNY4BNllJ2vwo0a8Z948IJANfW/35yYMCI/QyCa8Li8UYLeN3/ nVQQPQFOBXwlCAFHI9YoZVBlokLz/RMU+bMl0/GvSXXhQydLSFFxzmV/2i/2JpBNsEm0oJStyKb9k QbPfeYSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMQRt-00000006Tog-0fvz; Wed, 26 Jun 2024 11:04:25 +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 1sMQRj-00000006TnQ-0h1h for linux-arm-kernel@lists.infradead.org; Wed, 26 Jun 2024 11:04:16 +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 2A920339; Wed, 26 Jun 2024 04:04:36 -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 352A53F766; Wed, 26 Jun 2024 04:04:10 -0700 (PDT) Date: Wed, 26 Jun 2024 12:04:07 +0100 From: Cristian Marussi To: "Peng Fan (OSS)" Cc: Sudeep Holla , Cristian Marussi , arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Peng Fan Subject: Re: [PATCH 0/2] firmware: arm_scmi: create scmi devices for protocols that not have of_node Message-ID: References: <20240626-scmi-driver-v1-0-f16d777e004a@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240626-scmi-driver-v1-0-f16d777e004a@nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240626_040415_287917_AFB56F42 X-CRM114-Status: GOOD ( 21.39 ) 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 On Wed, Jun 26, 2024 at 02:58:38PM +0800, Peng Fan (OSS) wrote: > Per Hi, > https://lore.kernel.org/all/20230125141113.kkbowopusikuogx6@bogus/ > " > In short we shouldn't have to add a node if there are no consumers. It > was one of the topic of discussion initially when SCMI binding was added > and they exist only for the consumers otherwise we don't need it as > everything is discoverable from the interface. > " > https://lore.kernel.org/all/Y9JLUIioxFPn4BS0@e120937-lin/ > If a node has its own channel, the of_node is still needed. > > i.MX95 SCMI firmware not have dedicated channel for 0x12, and no need > of_node. This patchset is to support protocol 0x12 without the procotol > node in device tree. > With this patch you change a bit of the core logic to allow for protocols not explicitly described in the DT to be instantiated, and you use a static builtin array to list such protocols...so any future change or any downstream vendor protocols that want to use this, we will have to patch and extend such protocols[] array. Moreover, if anyone DO want to use a per-protocol channel in the future on some of these protocols, it will work fine with your solution on the code side, BUT you will still have anyway a DT binding check error when you try to add that 0x12 node to contain a channel description, right ? ... because in that case you will have re-added a (supposedly) empty protocol node in order to containn the channels definitions and that wont be yaml-compliant, am I right ? IOW this solves your issue in the immediate, while adding complexity to the core code and changing the core behaviour around protocols, but it wont stand any future addition or different usage. For these reasons, I still think that the cleanest solution is to just let protocol nodes to exist even if not referenced anywhere from the DT (your original patch to add protocol0x12 I think) simply because we allow per-protocol channel definitions and so any empty unreferenced protocol node could be needed in the future for this reason. In this way we'll also keep treating protocols in an uniform way. Just my opinion, though, I'll settle with what is finally decided anyway. Thank Cristian