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 BCC89CDB465 for ; Tue, 17 Oct 2023 02:32:55 +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=vhHLwuCkwjf4laggQFSKi1O+oyBrcmFwwIyASyaxZ+M=; b=iK8IwT/7yOBFZC A03+gylsEihC6NxWr1jupjvoqY2SAdzs8+EqHiVDY6vAe4vhPpA2PBYsQ1yJof0+ph+zUjFL+LnKR 9mQjFwLw9Q9mJeibYSfTK0nlrQwvcTIYo5UUSYz9hs+EDX06ELuR65m5TU9cwcs/viVs1oRz7j5+C aT7JQwm936qT3trHPhl+8G55VgPd/UPov2NSMyD7UUBRBR2PUO0BgtSI6DmMmTV3tHUcS77iuqaVh CjvaB6VVnTX8tJE8mASA3WnXEy3ymCYHhbv3jWXJEEmzL5lc6VhMB4oFP3fQ78bWtlvnepttTS1EJ U+Jvj0Fz+edoHzssZXtw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qsZsd-00B4UW-2J; Tue, 17 Oct 2023 02:32:23 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qsZsa-00B4Tx-1m for linux-arm-kernel@lists.infradead.org; Tue, 17 Oct 2023 02:32:22 +0000 Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-27d27026dc2so1205328a91.0 for ; Mon, 16 Oct 2023 19:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1697509937; x=1698114737; 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=trHmVVa3HVQtG4Xt2doqvC4B0sQ9SbK5P7sWmT0onTo=; b=SxR6BuEvAceix4Mc/MdrWg+qUL41Y0V54ljQ0IjWQyt1ZQmmpQ5gid13MXIDvNBuEe sCzhTM+PZutj4bDWEBo96s1Huf0u9r6e0ylGnc04wtO+JQlY5Cw1nw1ogkI2Ocp7lxH5 JbXvuVQ0c4vzYHCg1rfDRwX9p6tnWGurnVdJrzJUSPXgUjsLWEfxvTdbiWZ4mxZkaPAu rT3APlmZba+LUdKG2VeexMEvNOxrx7uWbcpPtC7xQMy1f0ZUz/7uBM9MKYLtW5UYp69F A5Xm6HQcUAKWK+bQKKAuMDplPXDYCpLj9lk2MkhAph7NTp1Bd88XaN3ApTroYnby1MD6 ryJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697509937; x=1698114737; 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=trHmVVa3HVQtG4Xt2doqvC4B0sQ9SbK5P7sWmT0onTo=; b=CujzslLbyNNY7QvV/3Z2yF31Q84xBzGmzzRDwktEcoszjzX35tyhk0d9d8mfU6SuGV 6j12Y/aiDXYNOKvqfGE28VcHAn5xJnjoDsAdoR2Bx/t4pTIjJzFbRrR1nDX9huVV0rVT 4cVO1tdcFWAIM/KS8Y+d9ldl6n1BHjhCAokK5UdxStX2kvHsn+lrobT2UyFG/uest5dr dX8CdIC9ASfG3nqDwTFOtzntvw7n9g4bTxHX9ojGZxq2WJswK9bE4CNvqEP9GT6DWfnD 4vEfL0R2hTDEqrRrczGWNVhirU0g5YlX+AdA2JAjrmrAQmW8pze9jL99IRhQ/yDoNCZK nfIg== X-Gm-Message-State: AOJu0YzVgV9cFUToiNT2h7y17Z7t5vuLnejDnRF52GqB9pDlw+/m3Mt+ Jt1XoCxIMOsMrZe21m++uq5VN2aJcs14ecoyYMDpVA== X-Google-Smtp-Source: AGHT+IGdPnaBYT7c8lIIVrIXW+cFRIDzNmwPorn8Hdp88GfjSDfiCtDs/2w9Fxd3AznDtYhsuNugYw== X-Received: by 2002:a17:902:dace:b0:1ca:8e79:53ae with SMTP id q14-20020a170902dace00b001ca8e7953aemr1081353plx.1.1697509937071; Mon, 16 Oct 2023 19:32:17 -0700 (PDT) Received: from octopus ([2400:4050:c3e1:100:b992:c10c:3bda:e666]) by smtp.gmail.com with ESMTPSA id j14-20020a170902da8e00b001c9bca1d705sm284757plx.242.2023.10.16.19.32.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 19:32:16 -0700 (PDT) Date: Tue, 17 Oct 2023 11:32:11 +0900 From: AKASHI Takahiro To: Linus Walleij Cc: Rob Herring , sudeep.holla@arm.com, cristian.marussi@arm.com, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.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 v2 5/5] dt-bindings: gpio: Add bindings for pinctrl based generic gpio driver Message-ID: Mail-Followup-To: AKASHI Takahiro , Linus Walleij , Rob Herring , sudeep.holla@arm.com, cristian.marussi@arm.com, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.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 References: <20231005025843.508689-1-takahiro.akashi@linaro.org> <20231005025843.508689-6-takahiro.akashi@linaro.org> <20231006132346.GA3426353-robh@kernel.org> 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-20231016_193220_669403_7145935F X-CRM114-Status: GOOD ( 22.97 ) 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 Linus, On Thu, Oct 12, 2023 at 09:25:20AM +0200, Linus Walleij wrote: > On Tue, Oct 10, 2023 at 7:25???AM AKASHI Takahiro > wrote: > > > > We can probably mandate that this has to be inside a pin controller > > > since it is a first. > > > > Yeah, my U-Boot implementation tentatively supports both (inside and > > outside pin controller). But it is not a user's choice, but we should > > decide which way to go. > > OK I have decided we are going to put it inside the pin control node, > as a subnode. (I don't expect anyone to object.) While I'm still thinking of how I can modify my current implementation to fit into 'inside' syntax, there are a couple of concerns: 1) invoke gpiochip_add_data() at probe function Probably we no longer need "compatible" property, but instead we need to call gpiochip_add_data() explicitly in SCMI pin controller's probe as follows: scmi_pinctrl_probe() ... devm_pinctrl_register_and_init(dev, ..., pctrldev); pinctrl_enable(pctrldev); device_for_each_child_node(dev, fwnode) if (fwnode contains "gpio-controller") { /* what pin_control_gpio_probe() does */ gc->get_direction = ...; ... devm_gpiochip_data_add(dev, gc, ...); } 2) gpio-by-pinctrl.c While this file is SCMI-independent now, due to a change at (1), it would be better to move the whole content inside SCMI pin controller driver (because there is no other user for now). 3) Then, pin-control-gpio.yaml may also be put into SCMI binding (i.e. firmware/arm,scmi.yaml). Can we leave the gpio binding outside? 4) phandle in "gpio-ranges" property (As you mentioned) The first element in a tuple of "gpio-ranges" is a phandle to a pin controller node. Now that the gpio node is a sub node of pin controller, the phandle is trivial. But there is no easier way to represent it than using an explicit label: (My U-Boot implementation does this.) scmi { ... scmi_pinctrl: protocol@19 { ... gpio { gpio-controller; ... gpio-ranges = <&scmi_pinctrl ... >; } } } I tried: gpio-ranges = <0 ...>; // dtc passed, but '0' might be illegal by spec. gpio-ranges = <(-1) ...>; // dtc passed, but ... gpio-ranges = <&{..} ...>; // dtc error because it's not a full path. Do you have any other idea? Otherwise, I will modify my RFC with the changes above. -Takahiro Akashi > It makes everything easier and clearer for users I think. > > Yours, > Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel