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 A5615E784BC for ; Mon, 2 Oct 2023 14:59:14 +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=raSHb1cOneieSgHUeHC+hR5azAaqrZq1pVojkh8EaWI=; b=SbMLHdXwEKZZ1C wqzf94MPzAnWpg/6FNWXaYpDQl0brNkgYpBrLihYelQDkvl2jCzu549OlbZCHNfLB6NcANyS438fm OMklmAP6u1VsrpZspig97G3tyy9RZZLKv8ET0kk6fKh226lqn7KXT+3/Aj4bMUWiA5dkESKZVpViV OPwinUhvq6MVZaSOCpIdnrqpgap5aU49MlvysnZb45MSVObk7GZRgEESX9n9OS9vs5In/elymSRso +UUCI0QNlfdIE859FIdgG+0iIeFyz6tQ3HKoKfBsfovCmTtVtPp/b7IgksxdL3bvE7/kdvXzu7UVP vVHaWkvyDsWsIf5BDygA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qnKNf-00Cvat-2M; Mon, 02 Oct 2023 14:58:43 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qnKNc-00CvZ1-0y for linux-arm-kernel@lists.infradead.org; Mon, 02 Oct 2023 14:58:42 +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 20E62C15; Mon, 2 Oct 2023 07:59:10 -0700 (PDT) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D53C03F762; Mon, 2 Oct 2023 07:58:29 -0700 (PDT) Date: Mon, 2 Oct 2023 15:58:27 +0100 From: Cristian Marussi To: Rob Herring Cc: AKASHI Takahiro , sudeep.holla@arm.com, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, linus.walleij@linaro.org, Oleksii_Moisieiev@epam.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org Subject: Re: [RFC 4/4] dt-bindings: gpio: Add bindings for SCMI pinctrl based gpio Message-ID: References: <20231002021602.260100-1-takahiro.akashi@linaro.org> <20231002021602.260100-5-takahiro.akashi@linaro.org> <20231002144155.GA1675188-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231002144155.GA1675188-robh@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231002_075840_406336_52A545E7 X-CRM114-Status: GOOD ( 14.94 ) 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 Mon, Oct 02, 2023 at 09:41:55AM -0500, Rob Herring wrote: > On Mon, Oct 02, 2023 at 11:16:02AM +0900, AKASHI Takahiro wrote: > > A dt binding for SCMI pinctrl based gpio driver is defined in this > > commit. It basically conforms to generic pinctrl-gpio mapping framework. [ snip] > > + additionalProperties: false > > + > > +required: > > + - compatible > > + - gpio-controller > > + - "#gpio-cells" > > + - gpio-ranges > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include > > + > > + scmi_gpio_0: scmi_gpio@0 { > > gpio { > > But doesn't SCMI have protocol numbers? > My understanding is that this RFC GPIO driver from Akashi is built completely on Pinctrl facilities (as he says in the cover), it is not indeed a typical pure SCMI driver, it just happen to trigger the use of SCMI if the underlying backend pinctrl driver is pinctrl-scmi; but this driver does not really call directly into any SCMI API by itself, i.e. it does not get and call any SCMI protocol ops. (but it could indeed trigger the backend Pinctrl SCMI driver to issue such call on its behalf AFAIU...) I wonder why it has even a dependency on PINCTRL_SCMI at this point; is not that it could work (generically) even if the backend Pinctrl driver is NOT SCMI ? What makes it usable only against an SCMI Pinctrl backend ? Cannot be a generic GPIO driver based on top of Pinctrl, no matter which Pinctrl backend driver has been configured ? ...I maybe missing something here about Pinctrl AND GPIO frameworks :P Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel