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 6BB28C76196 for ; Tue, 28 Mar 2023 07:28:15 +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=+T40mTKyGefRcV7nZsALb5fjE565qPjNnvHFlWj2/uM=; b=jjOqJzB0jvBmOM gHpkQA5ZBwfd4VRmMGgl/DQoM0CoUrlJ66bwQ0ley5pI7Yncdmm3jxi64hoP512as1djVEtdrur7L 3LbEOKi8Ldv8+3FvszDE+CLsyv3659oy4VpZC+ojTRPcb4T9y2RNyLdwS+gfcbKsPSlH0w+Gh4yNk p0rlB01MTLdC/7o1kyOEbeOPBhyP3ky3pRmq6t1QLeBdMKjnFK3VKZVTN37+kdHjnbvM7EMd6Jsbq xmHFWx81Zr8FyM7phLLgKtXhdfBA8nQYaOl5BfuNM6KurzVTCd0FmMpqXmwiIS+t8g1Y7XkG5Z94p sGdvnahErHf7xx7hGtyg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ph3jY-00DRHt-36; Tue, 28 Mar 2023 07:27:08 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ph3jU-00DRGo-3B for linux-arm-kernel@lists.infradead.org; Tue, 28 Mar 2023 07:27:06 +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 36E71C14; Tue, 28 Mar 2023 00:27:40 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8FEF73F73F; Tue, 28 Mar 2023 00:26:54 -0700 (PDT) Date: Tue, 28 Mar 2023 08:26:47 +0100 From: Cristian Marussi To: Krzysztof Kozlowski Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, sudeep.holla@arm.com, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, nicola.mazzucato@arm.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org Subject: Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Support mailboxes unidirectional channels Message-ID: References: <20230327140342.222168-1-cristian.marussi@arm.com> <20230327140342.222168-2-cristian.marussi@arm.com> <1838b760-c911-cb0a-184e-150df2f86c3b@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1838b760-c911-cb0a-184e-150df2f86c3b@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230328_002705_091110_82AD11E1 X-CRM114-Status: GOOD ( 17.88 ) 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 Tue, Mar 28, 2023 at 08:36:51AM +0200, Krzysztof Kozlowski wrote: > On 27/03/2023 17:27, Cristian Marussi wrote: > >>> + - | > >>> + firmware { > >>> + scmi { > >>> + compatible = "arm,scmi"; > >>> + mboxes = <&mhu_U_tx 0 0>, <&mhu_U_rx 0 0>; > >>> + shmem = <&cpu_scp_lpri0>; > >>> + > >>> + #address-cells = <1>; > >>> + #size-cells = <0>; > >> > >> I don't think adding one more example with difference in only one piece > >> is needed here. > >> > > > > Mmm, I thought was sensible to add this example, given that a mailbox > > transport configuration for a mailbox exposing unidrectional channels is > > quite different from the usual bidirectional channel config already > > present in the pre-existent example. > > > > I'll add mbox-names into this example and see if I can change your > > mind...or I can then finally drop it. > > And what exactly this one more example changes? Does not validate > different parts of the binding if only one property differs... Well it showcases how the extended new mboxes/shmem prop can be used in to support such unidirectional channels (which is pretty much different from the usual existing biridrectional synatx) ... anyway I never really thought as the examples in terms of validation really (and I am not saying that this is right eh) ... but more as an aid to help the unfortunate human being that has finally to write some DT based on this. Anyway since it does not seem appropriate, I'll just drop the whole example in V3, after waiting for some more (if any) feedback on the binding in general. Are the mbox-names fixes I added in V2 fine ? Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel