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 E32D5C00A8F for ; Tue, 24 Oct 2023 11:10:40 +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=cjCuKeKHWldIY89KiddNqM+r+7IoScK20drN07qJ/ew=; b=L8StKNhLT2R3vA FPArTfcPw+gvXjGrVtNTSCHJz622yxEJr+r5d4JvFwZQFcDODJfb8rtgJDI9dK1aijpOy5jk8Gg+M 0aaOAg3jSCLEh41oeWBR6+k11cRUgGVCZcfPkoRmPs+ld1P6xUGHVu88diK0vm8p8Dag+6RW0nS3T 42I2aFiZi+xvB86UGNUxCveBlFydeA+pRy35HTZe5f25LpKXwoTDp6BVld0ZR6NLGOaSnKFAY9mHq e2OnFseU0GJvccmHbF849saQNFjYUW6PqJF1xh6mC8Z8kMbSjtCjAVIim0famWXfzxkuIZdFgxVYN SW1TKJvld5LnQM1jeDHQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qvFIW-009d4C-34; Tue, 24 Oct 2023 11:10:08 +0000 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qvFIT-009d3R-1C for linux-arm-kernel@lists.infradead.org; Tue, 24 Oct 2023 11:10:06 +0000 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-6bcbfecf314so905080b3a.1 for ; Tue, 24 Oct 2023 04:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1698145802; x=1698750602; 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=RE1wsH4r/PT9CdvJUxnqs/kAns7JcqtTbkS2nbmYIlM=; b=R4iUAaaRSKtW/Zh7vrdYA09sqp+j4QY3EftjpHpZGn4vGf+7mjHg0YPOOzqzdLPLPU ZZljXx2vpCzhbG7Mu+5TuoSGFRE7kR46nQ2y8a8QPP38MxkdhNW7YDQmWH4lSVVVdxav 0zumhjeB7yHkTy2YA9ttjq3dT00p4MdodyKFBAge2z5zCSjvVlK8q75elytT5LARGsBf qhdZ+8OA97JLo2yn7HUnXgxCzpBcEGjTJCgbS0QOxBTaBp1uhr4rXVS5wTX10o4kPM62 rWv2csDgLODU0yxrEpnDP9rYqYom1dZs69magOo1S0YhrbLDc75cu9Ms2sEI72r5X5GH UsFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698145802; x=1698750602; 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=RE1wsH4r/PT9CdvJUxnqs/kAns7JcqtTbkS2nbmYIlM=; b=eXLQ1QirmEJd2IcvxTYWl6Cy9WND432nyY9sOAhsv1yJVmOZCMrJIb4eci3i9SpVxh 4N5sKLtLmM4R2hqhd+aLf/RE+BKUGxzgNDAF3S0BcTxBGKptoLvPop+SvQEKfU4UDYZB BqNnIEtEEHtxdNYHU4YUxm4OjBAyY6HHUa0SIuCfPnNvi5+40bJLgEpd/yRBC8goxi50 PAQcxdh9JphVbl8Om1g79JEvn8jzIYe3s5D41h+wFy1lsdpVL5R/TDvJGOT7ubgDmUOg 1MAx8zIcNcD5Z+vEtl+shOA7eYH5jD/AOmpmGYHRpO9CMmQGgx9Mnd9rOel6IqCmmAiJ Np/A== X-Gm-Message-State: AOJu0YwOSEAqifu0d/QIcfvbE2vHDvCfT+kKTxiQiNn+HJJO/Wbx5d/i xjMSDws+F2shEZQ6kz74N62ZAQ== X-Google-Smtp-Source: AGHT+IEX6WuqA5vIkcaujPmdybMRkAiT+hemmNEfBNRefkfhx9JKBoVLMwM5Lt2yToWxR/gWgGlVNg== X-Received: by 2002:a05:6a21:8cc5:b0:17b:170c:2d11 with SMTP id ta5-20020a056a218cc500b0017b170c2d11mr11510054pzb.6.1698145801901; Tue, 24 Oct 2023 04:10:01 -0700 (PDT) Received: from octopus ([2400:4050:c3e1:100:7c15:610f:1205:f10c]) by smtp.gmail.com with ESMTPSA id f125-20020a625183000000b0065a1b05193asm7801805pfb.185.2023.10.24.04.09.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 04:10:01 -0700 (PDT) Date: Tue, 24 Oct 2023 20:09:52 +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-20231024_041005_476086_14CE3138 X-CRM114-Status: GOOD ( 46.07 ) 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 Tue, Oct 24, 2023 at 11:40:00AM +0200, Linus Walleij wrote: > Hi Takahiro, > > On Tue, Oct 24, 2023 at 9:12???AM AKASHI Takahiro > wrote: > > > > I think it is better of the pin controller just parse and add any > > > subdevices (GPIO or other) using of_platform_default_populate() > > > (just grep for this function and you will see how many device > > > drivers use that). > > > > IICU, then, we will have to add a "compatible" to pinctrl node > > to make of_platform_default_populate() work as expected. That is: > > > > scmi { > > ... > > protocol@19 { > > compatible = "simple-bus"; // <- added > > Hm right, but you could also use > of_platform_populate(np, NULL, NULL, dev); > > Then the compatible match is of no concern. > > Sorry for my lack of attention to details :/ > > If you want to restrict the population to a few select compatibles > (maybe only "pin-control-gpio") then you can do > that with > > const struct of_device_id of_scmi_protocol_19_match_table[] = { > { .compatible = "pin-control-gpio", }, > {} > }; > of_platform_populate(np, of_scmi_protocol_19_match_table, NULL, dev); > > > Is this what you meant? > > In this case, however, "protocol@19" has a mixture of sub-nodes, > > most are pinconf definitions which are the properties of the pin > > controller, while "scmi_gpio" is a separate device. > > That looks good to me, it makes sense to have the GPIO as a subnode > here and mandate it with a compatible to match. > > > The code will work, but is it sane from DT binding pov? > > Let's let the DT people jump in on that. > > > > Instead just call gpiochip_add_pin_range() directly in Linux > > > after adding the pin controller and gpio_chip. > > > C.f. drivers/pinctrl/pinctrl-sx150x.c for an example of a driver > > > doing this. In this case the SX150X is hot-plugged (on a slow > > > bus) so it needs to figure out all ranges at runtime anyway. > > > > Are you suggesting implementing a custom function for parsing "gpio-ranges" > > and calling it in pin_control_gpio_probe() instead of a generic helper? > > The generic helper will always be attempted but if there are > no ranges in the device tree, it will just continue without adding > any ranges. I suggest putting *no* ranges into the device tree. > > > Or do you want to always map all the pin controller's pins to > > gpio pins as sx150x does? > > I think since the SCMI firmware knows about the available line > and pins etc, it makes sense that the driver comes up with the > applicable ranges on its own (derived from the information from > the SCMI firmware) and add them, instead of trying to put that > information into the device tree at all. Just omit it, and make your > own ranges, and add them in the Linux driver with > gpiochip_add_pin_range() without involving DT at all when defining > the ranges. As far as I understand, there is only one way for SCMI gpio driver to know which pins are actually GPIO pins; Calling PINCNTRL_CONFIG_GET command with "Input-mode" or "Output-mode" configuration type against *every* pin-controller's pins. (Here I assume that the command would fail with INVALID_PARAMETERS or NOT_SUPPORTED if configuring the given pin as a GPIO input or output is not possible. But the specification seems to be a bit ambiguous.) It means that, if SCMI firmware has 100 pinctrl pins, the driver needs to call the command 200 times in order to get the answer. It is possible but I believe that it is clunky and painful for the driver initialization. I'd like to see explicit "gpio-ranges" property in a device tree. Thanks, -Takahiro Akashi > I'm sorry if I'm unclear sometimes. > > Yours, > Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel