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 05504C4332F for ; Fri, 10 Nov 2023 00:59: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: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=7RnXmmqP7RSvWNOEEIybUsXD0UBcrzvaIHXKaSCxd54=; b=eN/9qGUxaP7hEi 56MQ5llJ2Dr2zbO5vpdUHNp4in6voGOLW9BJPCuLiety308kgRIygC3+LzaIDMId42aaBRuDn/Avb 2lOG7Z3jQMYzoEh2LOlrDBpaLV/8lwyWvAmpymFq6xjGWDnPe9qhOojIDLMkKed3cOBDQKEZTLXlw OYSsYKnkEnU3OOVqrsCkoEoMbH1TTFR8K486a2Y2P81dS7hpOec+3Cro1TN9BwDdYPvXgqXg0XlQx SuejgnwvIIEUd5OcFDHouFDD4LrE3gfxaRJPYVY7Bw2biw9XmuhisThFUQuG7dpawXFMcP5F/C9zb kQc1UrB0UbfA9MFke33g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r1FrE-007Y5v-2p; Fri, 10 Nov 2023 00:58:48 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r1FrB-007Y50-2p for linux-arm-kernel@lists.infradead.org; Fri, 10 Nov 2023 00:58:47 +0000 Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-6d339b93423so12100a34.0 for ; Thu, 09 Nov 2023 16:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1699577924; x=1700182724; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=xJVrXuXFcu3DgtWdnbXpFzASR1Czvt1UEeVrRTmaZPQ=; b=wy5mblOFrKHOvEe42shGPAofhD5WSwr6tjCz3uPDQZ2uuA4pKtPTOFXtu/3R2MYdzI bTk+5nJl7yytWGThoEr9hUzqr5sy/tCYGRg2w1PmsQHiX3r01iqoLsF+kOMeugDzPJWd qoi82HgC7VJDBumw229A5VYhgS+Y3ZPVrCHC13oUhSIFpkEo5U7++m9vibCnBbH8b5yh H03lq0lnnOses8iKm9iovSf8rizcuNyzhnQGchKAeCZvRj537UhtDIoDUh+Z/UXq2Qwq hX5HyLrpX1bL18xH39FYDs/IZAW6r+d4FWc7QgQiT6gFG/bLsmpLqpuXUPSreSIyaSEn aDRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699577924; x=1700182724; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xJVrXuXFcu3DgtWdnbXpFzASR1Czvt1UEeVrRTmaZPQ=; b=DicfBMhRQuOR0vL1t5Bz8QIZ0FehlCEHdi2daSub4KKcpHL4BTb5QJqcQOL6JBkmvi GyWZQLgb7jOHOtvtXrTOgk+zLSwTj3H00ofP6Dh6xIYiUU9KOU7dMEZ5aYTF3xv6v+nh vhxUVXx7rliqHuzojIGMszbm9dS4qw9fDADnT7SdG94r1qjf9R6enCYpbm3Paoe8425s CLR1Y8fEGNUqRHdVmKvh2J1k4uywoFF0qk+YrLB/BFo6ACpGYZwb4JpuuEem2m5Zet+l OiSrCkXSUPRWZW2yh0DDJzeMw6gkhS2sbwf6xJk/TgVUu01DnEfzMbvY6pukfjpUa58c vSkQ== X-Gm-Message-State: AOJu0Yx5WzchVFhaZtX7Y8Qy19BMUSd8mPbsLO9liWZ6jjFVsvF8i5Ba Xk1fmvHJ92h4TR9HDb5Va4o/8g== X-Google-Smtp-Source: AGHT+IFCGAq9uOJ74nOCEa1XdXbPO22Qfscitoj00Gqwgxzjx8UkOGK6WexDGU679wSnRWP4OZnOBw== X-Received: by 2002:a9d:6f16:0:b0:6b7:36af:1937 with SMTP id n22-20020a9d6f16000000b006b736af1937mr7501364otq.0.1699577923984; Thu, 09 Nov 2023 16:58:43 -0800 (PST) Received: from octopus ([2400:4050:c3e1:100:f2ee:7d90:a86d:610]) by smtp.gmail.com with ESMTPSA id s4-20020a655844000000b005bdf596164fsm1746007pgr.94.2023.11.09.16.58.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Nov 2023 16:58:43 -0800 (PST) Date: Fri, 10 Nov 2023 09:58:39 +0900 From: Takahiro Akashi To: Linus Walleij Cc: Oleksii Moisieiev , "sudeep.holla@arm.com" , Cristian Marussi , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" Subject: Re: [RFC v5 5/5] dt-bindings: firmware: arm,scmi: Add support for pinctrl protocol Message-ID: Mail-Followup-To: Takahiro Akashi , Linus Walleij , Oleksii Moisieiev , "sudeep.holla@arm.com" , Cristian Marussi , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" References: 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-20231109_165845_944685_40BC2800 X-CRM114-Status: GOOD ( 22.08 ) 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 Hi Arm folks, Do you have any comment? I expect that you have had some assumption when you defined SCMI pinctrl protocol specification. On Mon, Nov 06, 2023 at 02:12:36PM +0100, Linus Walleij wrote: > On Fri, Oct 27, 2023 at 8:28???AM Oleksii Moisieiev > wrote: > > > + keys_pins: keys-pins { > > + pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1"; > > + bias-pull-up; > > + }; > > This is kind of interesting and relates to my question about naming groups and > functions of GPIO pins. > > Here we see four pins suspiciously named "GP_*" which I read as > "generic purpose" > and they are not muxed to *any* function, yes pulled up. > > I would have expected something like: > > keys_pins: keys-pins { > groups = "GP_5_17_grp", "GP_5_20_grp", "GP_5_22_grp", "GP_2_1_grp"; > function = "gpio"; > pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1"; > bias-pull-up; > }; > > I hope this illustrates what I see as a problem in not designing in > GPIO as an explicit > function, I get the impression that these pins are GPIO because it is hardware > default. If you want to stick to "explicit", we may rather introduce a pre-defined sub-node name, "gpio", in a device tree binding, i.e. protocol@19 { // pinctrl protocol ... // other pinmux nodes scmi_gpio: gpio { // "gpio" is a fixed name keys-pins { pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1"; bias-pull-up; // possibly input or output }; input-pins { groups = "some group"; // any name input-mode; } output-pins { pins = "foo1", "foo2"; // any name output-mode; } } } It would indicate that all the succeeding nodes are for gpio definitions and *virtual* gpio pin numbers will be assigned in the order of appearances in "gpio" node. Then a client driver may refer to a gpio pin (say, GP_2_1?) like in the current manner: foo_device { ... reset-gpios = <&scmi_gpio 3 ...>; } -Takahiro Akashi > > Yours, > Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel