[{"id":1778487,"web_url":"http://patchwork.ozlabs.org/comment/1778487/","msgid":"<20171002174414.GL1165@minitux>","list_archive_url":null,"date":"2017-10-02T17:44:14","subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","submitter":{"id":68398,"url":"http://patchwork.ozlabs.org/api/people/68398/","name":"Bjorn Andersson","email":"bjorn.andersson@linaro.org"},"content":"On Thu 07 Sep 08:33 PDT 2017, Timur Tabi wrote:\n\nSorry for the slow response, I finally met with Linus last week to\ndiscuss this.\n\n> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c\n[..]\n> @@ -825,13 +897,39 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)\n>  \tchip->owner = THIS_MODULE;\n>  \tchip->of_node = pctrl->dev->of_node;\n>  \n> +\t/* If the GPIO map is sparse, then we need to disable specific IRQs */\n> +\tchip->irq_need_valid_mask = pctrl->soc->sparse;\n> +\n>  \tret = gpiochip_add_data(&pctrl->chip, pctrl);\n>  \tif (ret) {\n>  \t\tdev_err(pctrl->dev, \"Failed register gpiochip\\n\");\n>  \t\treturn ret;\n>  \t}\n>  \n> -\tret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev), 0, 0, chip->ngpio);\n> +\t/*\n> +\t * If irq_need_valid_mask is true, then gpiochip_add_data() will\n> +\t * initialize irq_valid_mask to all 1s.  We need to clear all the\n> +\t * GPIOs that are unavailable, and we need to find each block\n> +\t * of consecutive available GPIOs are add them as pin ranges.\n> +\t */\n> +\tif (chip->irq_need_valid_mask) {\n> +\t\tfor (i = 0; i < ngpio; i++)\n> +\t\t\tif (!groups[i].npins)\n> +\t\t\t\tclear_bit(i, pctrl->chip.irq_valid_mask);\n> +\n> +\t\twhile ((count = msm_gpio_get_next_range(pctrl, &start))) {\n> +\t\t\tret = gpiochip_add_pin_range(&pctrl->chip,\n> +\t\t\t\t\t\t     dev_name(pctrl->dev),\n> +\t\t\t\t\t\t     start, start, count);\n> +\t\t\tif (ret)\n> +\t\t\t\tbreak;\n> +\t\t\tstart += count;\n\nI do not fancy the idea of specifying a bitmap of valid irq pins and\nthen having the driver register the pin-ranges in-between. If we provide\na bitmap of validity to the core it should support using this for the\npins as well. (Which I believe is what Linus answered in the discussion\nfollowing patch 0/2)\n\n> +\t\t}\n> +\t} else {\n> +\t\tret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev),\n> +\t\t\t\t\t     0, 0, ngpio);\n> +\t}\n> +\n\nRegards,\nBjorn\n--\nTo unsubscribe from this list: send the line \"unsubscribe linux-gpio\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at  http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"ge5VSg6P\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y5V0N1ZC1z9rxm\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue,  3 Oct 2017 04:44:20 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751131AbdJBRoT (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tMon, 2 Oct 2017 13:44:19 -0400","from mail-pg0-f41.google.com ([74.125.83.41]:53191 \"EHLO\n\tmail-pg0-f41.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751204AbdJBRoS (ORCPT\n\t<rfc822; linux-gpio@vger.kernel.org>); Mon, 2 Oct 2017 13:44:18 -0400","by mail-pg0-f41.google.com with SMTP id i195so3331285pgd.9\n\tfor <linux-gpio@vger.kernel.org>;\n\tMon, 02 Oct 2017 10:44:18 -0700 (PDT)","from minitux (ip68-111-217-79.sd.sd.cox.net. [68.111.217.79])\n\tby smtp.gmail.com with ESMTPSA id\n\te13sm17290160pgt.14.2017.10.02.10.44.16\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 02 Oct 2017 10:44:16 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=MeujL/INYlBtYXuYuNytLT8EjBB29ocjgNXoI2Kj240=;\n\tb=ge5VSg6PpMxgehNKdznRgXYOcFgBhtwVH2z4/HSLdP4lalDq5wINQEgj8z2wmFMWiP\n\to7l9smGJJBR+zPqHx3cqy8NwZ6e6BkIsSiOAuTmrTn/NlIV30B+AY1qfB4Zek0S6YdDq\n\tiYysPzOuXRtVZTjuQ1oMlAH6ebRO0MhwwqpVQ=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=MeujL/INYlBtYXuYuNytLT8EjBB29ocjgNXoI2Kj240=;\n\tb=RItYeRJzMzbQwCIwyezOwiV5JDGN6QL07tOy6BI6zcBqz2xzIg4VPH3SAj4JLqMCt7\n\tMzemaf/BELaKaeDYT7KYi/firv8wIjmVxS93PupE1mgrhjNtQENpfC+hDOCkoOyNFj8N\n\tWty+A3zyZTqtGxJ/FRuBX9aKmYQs3cAicQudk+2bSgLELNnugts0SKf2dY/RehDIEemW\n\toZFXhkEO5GsLtvzV3fCg95xSzmBwnqTWOPPUBnpi6tbpC8I3aQJohe9iW4YqL4q8fuGt\n\tCsc7cfTuUOc07zYTdG9H8VjiaBwIeV2XpGAmVVVajgHahXTzkYfD79DkBJcgvWd0hYNe\n\tf0pg==","X-Gm-Message-State":"AHPjjUg8anCjuihA3AjUuBp85KfexEF85EqdsrHF090WxLNHF6nVHuej\n\t8vWIoEF0fBaf+tWBjCycYH7W3g==","X-Google-Smtp-Source":"AOwi7QCPijsLZRtJvNydoAs8ZYwnmV5YxKCXGhWGH/EFX1u7Qb9akrtzbgVZt2GbEkcOh1/E6+l3DA==","X-Received":"by 10.99.145.73 with SMTP id l70mr8756709pge.132.1506966257447; \n\tMon, 02 Oct 2017 10:44:17 -0700 (PDT)","Date":"Mon, 2 Oct 2017 10:44:14 -0700","From":"Bjorn Andersson <bjorn.andersson@linaro.org>","To":"Timur Tabi <timur@codeaurora.org>","Cc":"Linus Walleij <linus.walleij@linaro.org>, andy.gross@linaro.org,\n\tdavid.brown@linaro.org, anjiandi@codeaurora.org,\n\tlinux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tlinux-arm-msm@vger.kernel.org","Subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","Message-ID":"<20171002174414.GL1165@minitux>","References":"<1504798409-32041-1-git-send-email-timur@codeaurora.org>\n\t<1504798409-32041-2-git-send-email-timur@codeaurora.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1504798409-32041-2-git-send-email-timur@codeaurora.org>","User-Agent":"Mutt/1.8.3 (2017-05-23)","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1778612,"web_url":"http://patchwork.ozlabs.org/comment/1778612/","msgid":"<9f28c9dd-6277-6c75-1186-a834e15c5346@codeaurora.org>","list_archive_url":null,"date":"2017-10-02T20:47:51","subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","submitter":{"id":66858,"url":"http://patchwork.ozlabs.org/api/people/66858/","name":"Timur Tabi","email":"timur@codeaurora.org"},"content":"On 10/02/2017 12:44 PM, Bjorn Andersson wrote:\n>> +\t/*\n>> +\t * If irq_need_valid_mask is true, then gpiochip_add_data() will\n>> +\t * initialize irq_valid_mask to all 1s.  We need to clear all the\n>> +\t * GPIOs that are unavailable, and we need to find each block\n>> +\t * of consecutive available GPIOs are add them as pin ranges.\n>> +\t */\n>> +\tif (chip->irq_need_valid_mask) {\n>> +\t\tfor (i = 0; i < ngpio; i++)\n>> +\t\t\tif (!groups[i].npins)\n>> +\t\t\t\tclear_bit(i, pctrl->chip.irq_valid_mask);\n>> +\n>> +\t\twhile ((count = msm_gpio_get_next_range(pctrl, &start))) {\n>> +\t\t\tret = gpiochip_add_pin_range(&pctrl->chip,\n>> +\t\t\t\t\t\t     dev_name(pctrl->dev),\n>> +\t\t\t\t\t\t     start, start, count);\n>> +\t\t\tif (ret)\n>> +\t\t\t\tbreak;\n>> +\t\t\tstart += count;\n> I do not fancy the idea of specifying a bitmap of valid irq pins and\n> then having the driver register the pin-ranges in-between. \n\nBut that's exactly what abx500_gpio_probe() in pinctrl-abx500.c does. \nHere's even a reference to holes in the GPIO space:\n\n/*\n  * Compute number of GPIOs from the last SoC gpio range descriptors\n  * These ranges may include \"holes\" but the GPIO number space shall\n  * still be homogeneous, so we need to detect and account for any\n  * such holes so that these are included in the number of GPIO pins.\n  */\n\n > If we provide\n> a bitmap of validity to the core it should support using this for the\n> pins as well. (Which I believe is what Linus answered in the discussion\n> following patch 0/2)\n\nSo you want to change \"gpio_chip\" to add an \"available\" callback?  And \nevery time gpiolib wants to call a gpio_chip callback, it should call \n->available first?  Like this:\n\nif (chip->available && chip->available())\n\tstatus = chip->direction_input(chip, gpio_chip_hwgpio(desc));\n\nI can do that, but it just seems very redundant.  The core already knows \nnot to touch GPIOs that are not in a pin range.  The only exception is \ngpiochip_add_data(), as I've stated before.\n\nIt just seems wrong to call an API every time to ask permission before \nwe can call any other API.  But since the API may not be defined, we \nhave to first check if the API exists before we can ask permission.","headers":{"Return-Path":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"do5DxFyg\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n\theader.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"S2mEHhyT\"; dkim-atps=neutral","pdx-caf-mail.web.codeaurora.org;\n\tdmarc=none (p=none dis=none)\n\theader.from=codeaurora.org","pdx-caf-mail.web.codeaurora.org;\n\tspf=none smtp.mailfrom=timur@codeaurora.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y5Z4C5jXtz9t5R\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue,  3 Oct 2017 07:47:55 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751204AbdJBUry (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tMon, 2 Oct 2017 16:47:54 -0400","from smtp.codeaurora.org ([198.145.29.96]:42360 \"EHLO\n\tsmtp.codeaurora.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750984AbdJBUrx (ORCPT\n\t<rfc822; linux-gpio@vger.kernel.org>); Mon, 2 Oct 2017 16:47:53 -0400","by smtp.codeaurora.org (Postfix, from userid 1000)\n\tid 286006021C; Mon,  2 Oct 2017 20:47:53 +0000 (UTC)","from [10.222.143.167] (i-global254.qualcomm.com [199.106.103.254])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\t(Authenticated sender: timur@smtp.codeaurora.org)\n\tby smtp.codeaurora.org (Postfix) with ESMTPSA id 22840600D0;\n\tMon,  2 Oct 2017 20:47:52 +0000 (UTC)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1506977273;\n\tbh=iMtQ/VsLvWmenX+CJydSwWjWTECDEwSE1A1yB7612/4=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=do5DxFygdervj44DSkMowCEdpV8+ayfRcFRzelxvPEuS0JuKeE87PXOZrDevVzjU4\n\teE4mK93sKWqANQLRbm6ieWfBHjy6ni/XcJNHD4OYBm3xrrWtJdSsMrmW2YNYQRlv4A\n\tnGfljHz7/vlk22QIvs1FDMm+EANEgzaxbM+OjMmE=","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1506977272;\n\tbh=iMtQ/VsLvWmenX+CJydSwWjWTECDEwSE1A1yB7612/4=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=S2mEHhyT3kOLIJ1BlhEGihNqDyL4/ipumaSDctinlzm4HfgABaEPIFjuJS2nHG2Tr\n\tLM1KpmrvIuDC5CNyBwGIH6AkFjw3S023bBYhUQ9ao1kq6Ie3Vh4HZx1LSEotriZdJw\n\tjOQXVh4R9oN7i6z/cG7CWI2+1B4k3sKhcOIgvc2Q="],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tpdx-caf-mail.web.codeaurora.org","X-Spam-Level":"","X-Spam-Status":"No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00,\n\tDKIM_SIGNED,\n\tT_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0","DMARC-Filter":"OpenDMARC Filter v1.3.2 smtp.codeaurora.org 22840600D0","Subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","To":"Bjorn Andersson <bjorn.andersson@linaro.org>","Cc":"Linus Walleij <linus.walleij@linaro.org>, andy.gross@linaro.org,\n\tdavid.brown@linaro.org, anjiandi@codeaurora.org,\n\tlinux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tlinux-arm-msm@vger.kernel.org","References":"<1504798409-32041-1-git-send-email-timur@codeaurora.org>\n\t<1504798409-32041-2-git-send-email-timur@codeaurora.org>\n\t<20171002174414.GL1165@minitux>","From":"Timur Tabi <timur@codeaurora.org>","Message-ID":"<9f28c9dd-6277-6c75-1186-a834e15c5346@codeaurora.org>","Date":"Mon, 2 Oct 2017 15:47:51 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20171002174414.GL1165@minitux>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1782078,"web_url":"http://patchwork.ozlabs.org/comment/1782078/","msgid":"<CACRpkdYYp5TSM1QV-f+FmbwzY_ittgW-4MuXiZ9NW694GoMwKQ@mail.gmail.com>","list_archive_url":null,"date":"2017-10-07T11:07:50","subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","submitter":{"id":7055,"url":"http://patchwork.ozlabs.org/api/people/7055/","name":"Linus Walleij","email":"linus.walleij@linaro.org"},"content":"On Mon, Oct 2, 2017 at 10:47 PM, Timur Tabi <timur@codeaurora.org> wrote:\n> On 10/02/2017 12:44 PM, Bjorn Andersson wrote:\n>>>\n>>> +       /*\n>>> +        * If irq_need_valid_mask is true, then gpiochip_add_data() will\n>>> +        * initialize irq_valid_mask to all 1s.  We need to clear all the\n>>> +        * GPIOs that are unavailable, and we need to find each block\n>>> +        * of consecutive available GPIOs are add them as pin ranges.\n>>> +        */\n>>> +       if (chip->irq_need_valid_mask) {\n>>> +               for (i = 0; i < ngpio; i++)\n>>> +                       if (!groups[i].npins)\n>>> +                               clear_bit(i, pctrl->chip.irq_valid_mask);\n>>> +\n>>> +               while ((count = msm_gpio_get_next_range(pctrl, &start)))\n>>> {\n>>> +                       ret = gpiochip_add_pin_range(&pctrl->chip,\n>>> +\n>>> dev_name(pctrl->dev),\n>>> +                                                    start, start,\n>>> count);\n>>> +                       if (ret)\n>>> +                               break;\n>>> +                       start += count;\n>>\n>> I do not fancy the idea of specifying a bitmap of valid irq pins and\n>> then having the driver register the pin-ranges in-between.\n>\n> But that's exactly what abx500_gpio_probe() in pinctrl-abx500.c does. Here's\n> even a reference to holes in the GPIO space:\n\nThis driver is not a good example of what is desireable.\n\nI am sorry that the kernel contains a lot of bad examples. These\nare historical artifacts, they cannot be used as an argument to write\ncode in the same style.\n\n>> If we provide\n>>\n>> a bitmap of validity to the core it should support using this for the\n>> pins as well. (Which I believe is what Linus answered in the discussion\n>> following patch 0/2)\n>\n> So you want to change \"gpio_chip\" to add an \"available\" callback?  And every\n> time gpiolib wants to call a gpio_chip callback, it should call ->available\n> first?  Like this:\n>\n> if (chip->available && chip->available())\n>         status = chip->direction_input(chip, gpio_chip_hwgpio(desc));\n\nI mean that you add\nunsigned long *line_valid_mask;\nto struct gpio_chip using the same type of logic\nas .irq_valid_mask. The mask should be optional.\n\nThen the operation gpiod_get[_index]() will FAIL if the\nline is not valid.\n\nThere is no need to check on every operation, there should\nbe no way to get a handle on the pin any other way.\n\nAll new code should be using descriptors at this point so we\nonly need to design for that case.\n\nYours,\nLinus Walleij\n--\nTo unsubscribe from this list: send the line \"unsubscribe linux-gpio\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at  http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"OAuxvZNG\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y8Nys3wpvz9t5w\n\tfor <incoming@patchwork.ozlabs.org>;\n\tSat,  7 Oct 2017 22:08:05 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751004AbdJGLHx (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tSat, 7 Oct 2017 07:07:53 -0400","from mail-io0-f169.google.com ([209.85.223.169]:46599 \"EHLO\n\tmail-io0-f169.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750948AbdJGLHv (ORCPT\n\t<rfc822; linux-gpio@vger.kernel.org>); Sat, 7 Oct 2017 07:07:51 -0400","by mail-io0-f169.google.com with SMTP id 101so5685814ioj.3\n\tfor <linux-gpio@vger.kernel.org>;\n\tSat, 07 Oct 2017 04:07:51 -0700 (PDT)","by 10.79.14.140 with HTTP; Sat, 7 Oct 2017 04:07:50 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=w3VcogT5xw8PNiUht3azU7HmAy/aZxi1uzLeullcIoI=;\n\tb=OAuxvZNGIGmrIC5TW7WKzZsAMFm3pxLa+UZQQQHXgdWG65O3F+W23EwoPFaZVqXLxC\n\tkzE+0U0rYoWrghBWpuFHVQMvxNsX0+UgOluaJNHmfFksC+VebUnjT9zlfIeH2FGZ/lWy\n\tKCkwVHAHHzKI9wYoxaSuFBLPPq4OBIGFq7z7g=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=w3VcogT5xw8PNiUht3azU7HmAy/aZxi1uzLeullcIoI=;\n\tb=OKL3no3adx4wzc4O+5ZXYmr2rWFZF4c4q+NM9qyUoM8cZmf9783YFkJT+j3VYj2u28\n\t4LmK+1/8Z0+9QR+khcYr89ekBW8mHMGi/OkB1FAIF1DRcSeysvNbvj6JX2afynYGNO+f\n\tPDaYDpeeG6k+rp44iYAxE1uq5GRxriGDVdFQmhfXnBB3UxBsBSyIvwg73wyVUE6X6sYY\n\tGzr55qS/mMz2E/fESB61ZfUs246FbZ3pA5bijO+TFn96fsjPUnqiCsMG9qTugPvfvIxc\n\tELYfKTX2VZEpTPwn65sog2QyxXYq6NoC9j9RqzXF1WqBUdX4C+9F6qzSmwQmAWMjPTYS\n\tU6Fw==","X-Gm-Message-State":"AMCzsaUSO5s+V1SwC4F4bRvjBweL2gH+1N4rW+5YZbV7jNp/WmCElfd1\n\tJVvFQ8qhl0Kcbmtbn/rd3YJSSl6Q3iOPjHXwXWxowA==","X-Google-Smtp-Source":"AOwi7QCqAWaKlQ5qOrlkEeIkyXq7wW2hYZ+D6tp4xptbOt8It9BfZtEWN7PH1bna/eNjO6nEc4uNqW5bwvCwGsPZNag=","X-Received":"by 10.107.63.67 with SMTP id m64mr5857050ioa.104.1507374471100; \n\tSat, 07 Oct 2017 04:07:51 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<9f28c9dd-6277-6c75-1186-a834e15c5346@codeaurora.org>","References":"<1504798409-32041-1-git-send-email-timur@codeaurora.org>\n\t<1504798409-32041-2-git-send-email-timur@codeaurora.org>\n\t<20171002174414.GL1165@minitux>\n\t<9f28c9dd-6277-6c75-1186-a834e15c5346@codeaurora.org>","From":"Linus Walleij <linus.walleij@linaro.org>","Date":"Sat, 7 Oct 2017 13:07:50 +0200","Message-ID":"<CACRpkdYYp5TSM1QV-f+FmbwzY_ittgW-4MuXiZ9NW694GoMwKQ@mail.gmail.com>","Subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","To":"Timur Tabi <timur@codeaurora.org>","Cc":"Bjorn Andersson <bjorn.andersson@linaro.org>,\n\tAndy Gross <andy.gross@linaro.org>,\n\tDavid Brown <david.brown@linaro.org>, anjiandi@codeaurora.org,\n\t\"linux-gpio@vger.kernel.org\" <linux-gpio@vger.kernel.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-arm-msm@vger.kernel.org\" <linux-arm-msm@vger.kernel.org>","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1786736,"web_url":"http://patchwork.ozlabs.org/comment/1786736/","msgid":"<2be95dec-5e53-71b4-1b08-3e8dd45ca30c@codeaurora.org>","list_archive_url":null,"date":"2017-10-13T23:35:59","subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","submitter":{"id":66858,"url":"http://patchwork.ozlabs.org/api/people/66858/","name":"Timur Tabi","email":"timur@codeaurora.org"},"content":"On 10/07/2017 06:07 AM, Linus Walleij wrote:\n> I mean that you add\n> unsigned long *line_valid_mask;\n> to struct gpio_chip using the same type of logic\n> as .irq_valid_mask. The mask should be optional.\n\nHmmm okay\n\n> Then the operation gpiod_get[_index]() will FAIL if the\n> line is not valid.\n\nJust to be clear, you want gpiod_get_index() to check line_valid_mask \n(if present) and return -ENODEV if not valid?\n\n> There is no need to check on every operation, there should\n> be no way to get a handle on the pin any other way.\n> \n> All new code should be using descriptors at this point so we\n> only need to design for that case.\n\nOk, I will check this.","headers":{"Return-Path":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"URa7W+If\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n\theader.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"P9XgM5fu\"; dkim-atps=neutral","pdx-caf-mail.web.codeaurora.org;\n\tdmarc=none (p=none dis=none)\n\theader.from=codeaurora.org","pdx-caf-mail.web.codeaurora.org;\n\tspf=none smtp.mailfrom=timur@codeaurora.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yDPHH4Q4Bz9s76\n\tfor <incoming@patchwork.ozlabs.org>;\n\tSat, 14 Oct 2017 10:36:11 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753239AbdJMXgG (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tFri, 13 Oct 2017 19:36:06 -0400","from smtp.codeaurora.org ([198.145.29.96]:34036 \"EHLO\n\tsmtp.codeaurora.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752942AbdJMXgB (ORCPT\n\t<rfc822; linux-gpio@vger.kernel.org>); Fri, 13 Oct 2017 19:36:01 -0400","by smtp.codeaurora.org (Postfix, from userid 1000)\n\tid 41B176199A; Fri, 13 Oct 2017 23:36:01 +0000 (UTC)","from [10.222.143.167] (i-global254.qualcomm.com [199.106.103.254])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\t(Authenticated sender: timur@smtp.codeaurora.org)\n\tby smtp.codeaurora.org (Postfix) with ESMTPSA id 28F946199A;\n\tFri, 13 Oct 2017 23:36:00 +0000 (UTC)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507937761;\n\tbh=nZIoDPycNoyEf1aWTSG6Kt6lqk5dYAmYKzBgPY+EFWo=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=URa7W+Ifx7vazB01C6MEQs5RMcgfyDbH3114rzrD2OURjE4VufrRtwDU1VWwLA6qB\n\t0olDEoskA/XYKGBuVWpUmTiwIY2fZA2XKK+McQZ0JVjmv5ZtuXjtzChqlnT+3VzKA7\n\tP3P8o0DchfpnM6mUrW27BRGZmoHgOp4G48re960g=","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507937760;\n\tbh=nZIoDPycNoyEf1aWTSG6Kt6lqk5dYAmYKzBgPY+EFWo=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=P9XgM5fu3CuKWszh2MZHZMgjuA1IVpDr3YbBa+qH0WWKwOJlVgZkmn+wBes4qvGis\n\trr5jp2b9PBH2LpsG9rqK0vsOMfEJ8Fk/UOjW5CXbJYfeiSGfhVM5CaYc38Fxe4LpEp\n\t8puMAetNuy1eFtAM72pfS7UeGmPj4+J7gwrbFvTA="],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tpdx-caf-mail.web.codeaurora.org","X-Spam-Level":"","X-Spam-Status":"No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00,\n\tDKIM_SIGNED,\n\tT_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0","DMARC-Filter":"OpenDMARC Filter v1.3.2 smtp.codeaurora.org 28F946199A","Subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","To":"Linus Walleij <linus.walleij@linaro.org>","Cc":"Bjorn Andersson <bjorn.andersson@linaro.org>,\n\tAndy Gross <andy.gross@linaro.org>,\n\tDavid Brown <david.brown@linaro.org>, anjiandi@codeaurora.org,\n\t\"linux-gpio@vger.kernel.org\" <linux-gpio@vger.kernel.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-arm-msm@vger.kernel.org\" <linux-arm-msm@vger.kernel.org>","References":"<1504798409-32041-1-git-send-email-timur@codeaurora.org>\n\t<1504798409-32041-2-git-send-email-timur@codeaurora.org>\n\t<20171002174414.GL1165@minitux>\n\t<9f28c9dd-6277-6c75-1186-a834e15c5346@codeaurora.org>\n\t<CACRpkdYYp5TSM1QV-f+FmbwzY_ittgW-4MuXiZ9NW694GoMwKQ@mail.gmail.com>","From":"Timur Tabi <timur@codeaurora.org>","Message-ID":"<2be95dec-5e53-71b4-1b08-3e8dd45ca30c@codeaurora.org>","Date":"Fri, 13 Oct 2017 18:35:59 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<CACRpkdYYp5TSM1QV-f+FmbwzY_ittgW-4MuXiZ9NW694GoMwKQ@mail.gmail.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1787203,"web_url":"http://patchwork.ozlabs.org/comment/1787203/","msgid":"<20171016080117.GA17369@ulmo>","list_archive_url":null,"date":"2017-10-16T08:01:17","subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","submitter":{"id":26234,"url":"http://patchwork.ozlabs.org/api/people/26234/","name":"Thierry Reding","email":"thierry.reding@gmail.com"},"content":"On Thu, Sep 07, 2017 at 10:33:28AM -0500, Timur Tabi wrote:\n[...]\n>  \tret = gpiochip_add_data(&pctrl->chip, pctrl);\n>  \tif (ret) {\n>  \t\tdev_err(pctrl->dev, \"Failed register gpiochip\\n\");\n>  \t\treturn ret;\n>  \t}\n>  \n> -\tret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev), 0, 0, chip->ngpio);\n> +\t/*\n> +\t * If irq_need_valid_mask is true, then gpiochip_add_data() will\n> +\t * initialize irq_valid_mask to all 1s.  We need to clear all the\n> +\t * GPIOs that are unavailable, and we need to find each block\n> +\t * of consecutive available GPIOs are add them as pin ranges.\n> +\t */\n> +\tif (chip->irq_need_valid_mask) {\n> +\t\tfor (i = 0; i < ngpio; i++)\n> +\t\t\tif (!groups[i].npins)\n> +\t\t\t\tclear_bit(i, pctrl->chip.irq_valid_mask);\n> +\n> +\t\twhile ((count = msm_gpio_get_next_range(pctrl, &start))) {\n> +\t\t\tret = gpiochip_add_pin_range(&pctrl->chip,\n> +\t\t\t\t\t\t     dev_name(pctrl->dev),\n> +\t\t\t\t\t\t     start, start, count);\n> +\t\t\tif (ret)\n> +\t\t\t\tbreak;\n> +\t\t\tstart += count;\n> +\t\t}\n> +\t} else {\n> +\t\tret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev),\n> +\t\t\t\t\t     0, 0, ngpio);\n> +\t}\n\nThis is the bit that I don't understand. If you only tell gpiolib about\nthe GPIOs that exist, then it won't be initializing the .irq_valid_mask\nin a wrong way.\n\nIn other words, what I'm trying to say is that in your case, ngpio isn't\nequal to the sum of .npins over all groups. If instead you make the chip\nregister only the lines that actually exist, .irq_valid_mask will only\ncontain bits that do exist.\n\nThe reason I'm bringing this up is because we had the same discussion\nback in November last year (yes, that driver still isn't upstream...):\n\n\thttps://lkml.org/lkml/2016/11/22/543\n\nIn a nutshell: the Tegra driver was assuming that each port had a fixed\nnumber (8) of lines, but when gpiolib changed to query the direction of\nGPIOs at driver probe time this broke badly because on of the instances\nof the GPIO controller is very strict about what it allows access to.\n\nThis seems to be similar to what you're experiencing. In our case we'd\nrun into a hard hang trying to access a register for a non-existing\nGPIO. One of the possibilities discussed in the thread was to introduce\nsomething akin to what's being proposed here.\n\nIn the end it turned out to be easiest to just don't tell gpiolib about\nany non-existing GPIOs, because then you don't get to deal with any of\nthese workarounds. The downside is that you need a little more code to\nfind out exactly what GPIO you're talking about, or to determine how\nmany you have. In the end I think it's all worth it by making it a lot\neasier in general to deal with. I think it's really confusing if you\nexpose, say, 200 pins, and for 50 of them users will get -EACCES, or\n-ENOENT or whatever if they try to use them.\n\nThierry","headers":{"Return-Path":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"oglZsipx\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yFrPH3VmSz9sNc\n\tfor <incoming@patchwork.ozlabs.org>;\n\tMon, 16 Oct 2017 19:01:23 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751754AbdJPIBW (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tMon, 16 Oct 2017 04:01:22 -0400","from mail-qt0-f171.google.com ([209.85.216.171]:55343 \"EHLO\n\tmail-qt0-f171.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751714AbdJPIBV (ORCPT\n\t<rfc822; linux-gpio@vger.kernel.org>); Mon, 16 Oct 2017 04:01:21 -0400","by mail-qt0-f171.google.com with SMTP id v41so19678007qtv.12;\n\tMon, 16 Oct 2017 01:01:20 -0700 (PDT)","from localhost\n\t(p200300E41BE4FD00CEAD5B94E1CFD280.dip0.t-ipconnect.de.\n\t[2003:e4:1be4:fd00:cead:5b94:e1cf:d280])\n\tby smtp.gmail.com with ESMTPSA id\n\ti27sm1241437qtc.91.2017.10.16.01.01.19\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 16 Oct 2017 01:01:19 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=uk6S9Iv857a0kg3zUN9in5DVIP+UuGgphgkReejgnvc=;\n\tb=oglZsipxzAU1wwjQBCl85IrtA9nlkS94LkkpbsYBmPObi54sBW2bK/ZEl+hhsY5xsb\n\tTbnlN9ykHtFXIJWBQ45CgjlPVEw/eTtYO2rr9lNMZymvdSIq2VRvdVr2s0tcvilntY36\n\txO0w74w9d7PE55uSXuv/HzBs4RYwJX6fuEQzaDP6sG0OSBe4am68T4nfAJadt7/unprn\n\tKTud/TqoqFgMdYW96w4TpMRlol2ZY3iU/s1qSsyo2Z3hmZm/mAfUecxav4BDWXpZELG4\n\tdQ0yeooivbuMOuZxvEjwAkP1Cnwh3wMCuLgwB73HENqETTVTKbHyfyVC+ABqHWUHphap\n\tl/0A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=uk6S9Iv857a0kg3zUN9in5DVIP+UuGgphgkReejgnvc=;\n\tb=Q7h7kRqCrE1M/Kp5TwlDWhqmRTAwJc1ZgMIsEpdsfAC8LChVPsi4FLxer5jG1qNY5T\n\tfxOOC5h5stPhq00esHcXFc0fgeGJ4sINIdQrNzT7PRQntMEdbeM98jxRx07bg8wUxZds\n\tql4/OWs1fZuH7VLQnxjk+pDhYlfwgdNDk7RBsv8HH5f8QKCq8YFr0qCoQRJBJ8OwKQ4+\n\tQQ4a+VB43GTDm+P9yNknjJ0gP5CBhxta8KH0jHht9Te6cojvprAEfKSqZNchzMwtbMQz\n\txWhD+QkPn9j80zShMFGBFpZLAiF31u4BvF3siUOQg339T/6/IzoYlJoz8TG19q8nTHt5\n\t48kA==","X-Gm-Message-State":"AMCzsaUJ1qa1gAPIJ9771jRV5RwmBOWGX7UeOrLG0K8ht25Hbw7v4sEt\n\tOhxko6Z443xihyES6yqx7Zo=","X-Google-Smtp-Source":"AOwi7QD329TPiarJeIUq42w1IKW6QRSSkIYZ+qqJkl+3wPc7LCSF+dkEHl1D4VAv0IdO1wPP6KXKgA==","X-Received":"by 10.200.38.50 with SMTP id u47mr12459305qtu.112.1508140880318; \n\tMon, 16 Oct 2017 01:01:20 -0700 (PDT)","Date":"Mon, 16 Oct 2017 10:01:17 +0200","From":"Thierry Reding <thierry.reding@gmail.com>","To":"Timur Tabi <timur@codeaurora.org>","Cc":"Linus Walleij <linus.walleij@linaro.org>, andy.gross@linaro.org,\n\tdavid.brown@linaro.org, anjiandi@codeaurora.org,\n\tBjorn Andersson <bjorn.andersson@linaro.org>,\n\tlinux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tlinux-arm-msm@vger.kernel.org","Subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","Message-ID":"<20171016080117.GA17369@ulmo>","References":"<1504798409-32041-1-git-send-email-timur@codeaurora.org>\n\t<1504798409-32041-2-git-send-email-timur@codeaurora.org>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"+HP7ph2BbKc20aGI\"","Content-Disposition":"inline","In-Reply-To":"<1504798409-32041-2-git-send-email-timur@codeaurora.org>","User-Agent":"Mutt/1.9.1 (2017-09-22)","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1787448,"web_url":"http://patchwork.ozlabs.org/comment/1787448/","msgid":"<9c142b32-5f14-38c5-3611-884f2589d682@codeaurora.org>","list_archive_url":null,"date":"2017-10-16T13:52:09","subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","submitter":{"id":66858,"url":"http://patchwork.ozlabs.org/api/people/66858/","name":"Timur Tabi","email":"timur@codeaurora.org"},"content":"On 10/16/2017 03:01 AM, Thierry Reding wrote:\n> This is the bit that I don't understand. If you only tell gpiolib about\n> the GPIOs that exist, then it won't be initializing the .irq_valid_mask\n> in a wrong way.\n\nI know, and that's what my patches do.  I tell gpiolib that I need a \nvalid mask:\n\n/* If the GPIO map is sparse, then we need to disable specific IRQs */\nchip->irq_need_valid_mask = pctrl->soc->sparse;\n\nThen I proceed to provide the specific GPIOs that exist, one block at a \ntime:\n\n\tret = gpiochip_add_pin_range(&pctrl->chip,\n\t\t\t\t     dev_name(pctrl->dev),\n\t\t\t\t     start, start, count);\n\n> In other words, what I'm trying to say is that in your case, ngpio isn't\n> equal to the sum of .npins over all groups.\n\nThat's true.  I set it to the maximum number of GPIOs that exist on the \nchip.  I could set it to the highest number of GPIOs that I register \n(e.g. the highest value of \"start + count\"), but that's not necessary \nfor my patches to work.\n\n> If instead you make the chip\n> register only the lines that actually exist, .irq_valid_mask will only\n> contain bits that do exist.\n\nThat's what I'm doing.\n\n> The reason I'm bringing this up is because we had the same discussion\n> back in November last year (yes, that driver still isn't upstream...):\n> \n> \thttps://lkml.org/lkml/2016/11/22/543\n> \n> In a nutshell: the Tegra driver was assuming that each port had a fixed\n> number (8) of lines, but when gpiolib changed to query the direction of\n> GPIOs at driver probe time this broke badly because on of the instances\n> of the GPIO controller is very strict about what it allows access to.\n\nIt appear we're re-hashing that same exact argument.\n\n> This seems to be similar to what you're experiencing. In our case we'd\n> run into a hard hang trying to access a register for a non-existing\n> GPIO. One of the possibilities discussed in the thread was to introduce\n> something akin to what's being proposed here.\n\nI guess great minds do think alike!\n\n> In the end it turned out to be easiest to just don't tell gpiolib about\n> any non-existing GPIOs, because then you don't get to deal with any of\n> these workarounds.\n\nI agree.\n\n> The downside is that you need a little more code to\n> find out exactly what GPIO you're talking about, or to determine how\n> many you have.\n\nIn my case, the ACPI table provides an exact list that I use at probe() \ntime.\n\n> In the end I think it's all worth it by making it a lot\n> easier in general to deal with. I think it's really confusing if you\n> expose, say, 200 pins, and for 50 of them users will get -EACCES, or\n> -ENOENT or whatever if they try to use them.\n\nTrue, but /sys/kernel/debug/gpio is the only mechanism I found where the \nuser can get a list of valid GPIOs.  Maybe we need something similar in \n/sys/class/gpio/.","headers":{"Return-Path":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"lzER1yru\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n\theader.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"o9YmFmxP\"; dkim-atps=neutral","pdx-caf-mail.web.codeaurora.org;\n\tdmarc=none (p=none dis=none)\n\theader.from=codeaurora.org","pdx-caf-mail.web.codeaurora.org;\n\tspf=none smtp.mailfrom=timur@codeaurora.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yG0B919lzz9sPk\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 17 Oct 2017 00:52:17 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752466AbdJPNwQ (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tMon, 16 Oct 2017 09:52:16 -0400","from smtp.codeaurora.org ([198.145.29.96]:33186 \"EHLO\n\tsmtp.codeaurora.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752431AbdJPNwP (ORCPT\n\t<rfc822; linux-gpio@vger.kernel.org>); Mon, 16 Oct 2017 09:52:15 -0400","by smtp.codeaurora.org (Postfix, from userid 1000)\n\tid 50D1F60A63; Mon, 16 Oct 2017 13:52:15 +0000 (UTC)","from [10.222.143.167] (i-global254.qualcomm.com [199.106.103.254])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\t(Authenticated sender: timur@smtp.codeaurora.org)\n\tby smtp.codeaurora.org (Postfix) with ESMTPSA id 35F0B60A63;\n\tMon, 16 Oct 2017 13:52:10 +0000 (UTC)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1508161935;\n\tbh=4iFGpxLJpAWz+mKhUw7y+CLKohLxSEz9swOrjSaAUuQ=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=lzER1yruKN92Y+ym+s4InKnPcWjRQWVBb4m5r6FQW0X4jYy5IMOJB6cDFaLqvIGZQ\n\t347l15QEsLamBo5J34YLDYsE9HaRg3N3EUqAi0l41nVKMstosSy5FPuTKIMAqkXnCv\n\tztkl4jSHKujCQG1lkMTJetCLfVZAHq88BBZEcwic=","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1508161930;\n\tbh=4iFGpxLJpAWz+mKhUw7y+CLKohLxSEz9swOrjSaAUuQ=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=o9YmFmxPbkHXevqiPueR5HuFmXcdCP8t8Uy7jPzDqxii1bKtPCs72J4LIbZkQ2IId\n\thBpk3CrcXGKvWz83b+r+qHXiuzhCqLg8ZCS2nStG6fj+NxM0OlqfC4mzcky2X+mrO2\n\tNnA0zOFs5aE8fVmsMPpaF4lmeGBhcMvLRmNjrEuU="],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tpdx-caf-mail.web.codeaurora.org","X-Spam-Level":"","X-Spam-Status":"No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00,\n\tDKIM_SIGNED,\n\tT_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0","DMARC-Filter":"OpenDMARC Filter v1.3.2 smtp.codeaurora.org 35F0B60A63","Subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","To":"Thierry Reding <thierry.reding@gmail.com>","Cc":"Linus Walleij <linus.walleij@linaro.org>, andy.gross@linaro.org,\n\tdavid.brown@linaro.org, anjiandi@codeaurora.org,\n\tBjorn Andersson <bjorn.andersson@linaro.org>,\n\tlinux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tlinux-arm-msm@vger.kernel.org","References":"<1504798409-32041-1-git-send-email-timur@codeaurora.org>\n\t<1504798409-32041-2-git-send-email-timur@codeaurora.org>\n\t<20171016080117.GA17369@ulmo>","From":"Timur Tabi <timur@codeaurora.org>","Message-ID":"<9c142b32-5f14-38c5-3611-884f2589d682@codeaurora.org>","Date":"Mon, 16 Oct 2017 08:52:09 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171016080117.GA17369@ulmo>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1791009,"web_url":"http://patchwork.ozlabs.org/comment/1791009/","msgid":"<819a0c67-3494-030d-3166-748081509c83@codeaurora.org>","list_archive_url":null,"date":"2017-10-19T22:44:59","subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","submitter":{"id":66858,"url":"http://patchwork.ozlabs.org/api/people/66858/","name":"Timur Tabi","email":"timur@codeaurora.org"},"content":"On 10/07/2017 06:07 AM, Linus Walleij wrote:\n> I mean that you add\n> unsigned long *line_valid_mask;\n> to struct gpio_chip using the same type of logic\n> as .irq_valid_mask. The mask should be optional.\n> \n> Then the operation gpiod_get[_index]() will FAIL if the\n> line is not valid.\n> \n> There is no need to check on every operation, there should\n> be no way to get a handle on the pin any other way.\n> \n> All new code should be using descriptors at this point so we\n> only need to design for that case.\n\nI think I'm missing something, because I implemented what you're asking \nfor, but whenever I try to expose a GPIO from sysfs (e.g. echo 37 > \n/sys/class/gpio/export), gpiod_get_index() is not called.  The only \nthing preventing the GPIO from being exported is the ->request callback:\n\nstatic int msm_gpio_request(struct gpio_chip *chip, unsigned int offset)\n{\n\tstruct msm_pinctrl *pctrl = gpiochip_get_data(chip);\n\tconst struct msm_pingroup *g = &pctrl->soc->groups[offset];\n\n\tif (!g->npins)\n\t\treturn -ENODEV;\n\nWhat operation is supposed to trigger a call to gpiod_get_index?","headers":{"Return-Path":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"ZKBa9Iz/\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n\theader.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"ZKBa9Iz/\"; dkim-atps=neutral","pdx-caf-mail.web.codeaurora.org;\n\tdmarc=none (p=none dis=none)\n\theader.from=codeaurora.org","pdx-caf-mail.web.codeaurora.org;\n\tspf=none smtp.mailfrom=timur@codeaurora.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yJ3sY0b9mz9t5C\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 20 Oct 2017 09:45:05 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753838AbdJSWpD (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tThu, 19 Oct 2017 18:45:03 -0400","from smtp.codeaurora.org ([198.145.29.96]:38428 \"EHLO\n\tsmtp.codeaurora.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753513AbdJSWpC (ORCPT\n\t<rfc822; linux-gpio@vger.kernel.org>); Thu, 19 Oct 2017 18:45:02 -0400","by smtp.codeaurora.org (Postfix, from userid 1000)\n\tid B112160542; Thu, 19 Oct 2017 22:45:01 +0000 (UTC)","from [10.222.143.167] (i-global254.qualcomm.com [199.106.103.254])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\t(Authenticated sender: timur@smtp.codeaurora.org)\n\tby smtp.codeaurora.org (Postfix) with ESMTPSA id 90FE760351;\n\tThu, 19 Oct 2017 22:45:00 +0000 (UTC)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1508453101;\n\tbh=Q9I1FUw2fya5Ht5r7t6I6ToADiR+i9ai4WzrZpZbKkc=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=ZKBa9Iz//i2CCPMg/Cv8UA9DuHhwgvl6TE78a0SCzVPBQO5m3nUFkrKt3X0Jpp4m0\n\tnWQzy9xnSRJsm0eeVr9+Ayy/azw/M3b0AT0h12uWC7nPr6wWpOS8ewCVA9ihBR8WJR\n\tpJ56O57+FwNpWxjdNoYvb1PecPy2iQkNkbHx9mhg=","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1508453101;\n\tbh=Q9I1FUw2fya5Ht5r7t6I6ToADiR+i9ai4WzrZpZbKkc=;\n\th=Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=ZKBa9Iz//i2CCPMg/Cv8UA9DuHhwgvl6TE78a0SCzVPBQO5m3nUFkrKt3X0Jpp4m0\n\tnWQzy9xnSRJsm0eeVr9+Ayy/azw/M3b0AT0h12uWC7nPr6wWpOS8ewCVA9ihBR8WJR\n\tpJ56O57+FwNpWxjdNoYvb1PecPy2iQkNkbHx9mhg="],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tpdx-caf-mail.web.codeaurora.org","X-Spam-Level":"","X-Spam-Status":"No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00,\n\tDKIM_SIGNED,\n\tT_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0","DMARC-Filter":"OpenDMARC Filter v1.3.2 smtp.codeaurora.org 90FE760351","Subject":"Re: [PATCH 1/2] [v5] pinctrl: qcom: disable GPIO groups with no pins","To":"Linus Walleij <linus.walleij@linaro.org>","Cc":"Bjorn Andersson <bjorn.andersson@linaro.org>,\n\tAndy Gross <andy.gross@linaro.org>,\n\tDavid Brown <david.brown@linaro.org>, anjiandi@codeaurora.org,\n\t\"linux-gpio@vger.kernel.org\" <linux-gpio@vger.kernel.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-arm-msm@vger.kernel.org\" <linux-arm-msm@vger.kernel.org>","References":"<1504798409-32041-1-git-send-email-timur@codeaurora.org>\n\t<1504798409-32041-2-git-send-email-timur@codeaurora.org>\n\t<20171002174414.GL1165@minitux>\n\t<9f28c9dd-6277-6c75-1186-a834e15c5346@codeaurora.org>\n\t<CACRpkdYYp5TSM1QV-f+FmbwzY_ittgW-4MuXiZ9NW694GoMwKQ@mail.gmail.com>","From":"Timur Tabi <timur@codeaurora.org>","Message-ID":"<819a0c67-3494-030d-3166-748081509c83@codeaurora.org>","Date":"Thu, 19 Oct 2017 17:44:59 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<CACRpkdYYp5TSM1QV-f+FmbwzY_ittgW-4MuXiZ9NW694GoMwKQ@mail.gmail.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}}]