| Message ID | 1501179565-26466-2-git-send-email-timur@codeaurora.org |
|---|---|
| State | New |
| Headers | show |
On Thu, Jul 27, 2017 at 8:19 PM, Timur Tabi <timur@codeaurora.org> wrote: > Before querying a GPIO to determine its direction, the GPIO should be > formally requested. This allows the GPIO driver to block access to > unavailable GPIOs, which makes it easier for some drivers to support > sparse GPIO maps. > > Signed-off-by: Timur Tabi <timur@codeaurora.org> This makes all kind of semantic change, so patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/31/2017 08:35 AM, Linus Walleij wrote: >> Before querying a GPIO to determine its direction, the GPIO should be >> formally requested. This allows the GPIO driver to block access to >> unavailable GPIOs, which makes it easier for some drivers to support >> sparse GPIO maps. >> >> Signed-off-by: Timur Tabi<timur@codeaurora.org> > This makes all kind of semantic change, so patch applied. Have you push it to git.kernel.org? I don't see it.
On Mon, Aug 21, 2017 at 11:23 PM, Timur Tabi <timur@codeaurora.org> wrote: > On 07/31/2017 08:35 AM, Linus Walleij wrote: >>> >>> Before querying a GPIO to determine its direction, the GPIO should be >>> formally requested. This allows the GPIO driver to block access to >>> unavailable GPIOs, which makes it easier for some drivers to support >>> sparse GPIO maps. >>> >>> Signed-off-by: Timur Tabi<timur@codeaurora.org> >> >> This makes all kind of semantic change, so patch applied. > > Have you push it to git.kernel.org? I don't see it. It's right there on the "devel" branch from the GPIO git tree. https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/23/2017 03:32 AM, Linus Walleij wrote: > It's right there on the "devel" branch from the GPIO git tree. > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel The devel branch is missing this commit: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?id=83cf5faeba37fede8a6274d07f646d1cd1b25d35 which I need to avoid a merge conflict. I'm going to submit a new version of my patches, but they won't apply on top of 'devel' unless you pull in that commit from linux-pinctrl. Or you could copy that my gpiolib commit to linux-pinctrl.
On Thu, Aug 24, 2017 at 1:28 AM, Timur Tabi <timur@codeaurora.org> wrote: > On 08/23/2017 03:32 AM, Linus Walleij wrote: >> >> It's right there on the "devel" branch from the GPIO git tree. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel > > > The devel branch is missing this commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?id=83cf5faeba37fede8a6274d07f646d1cd1b25d35 Yes I have separate git trees for GPIO and pin control even. > which I need to avoid a merge conflict. I'm going to submit a new version > of my patches, but they won't apply on top of 'devel' unless you pull in > that commit from linux-pinctrl. Or you could copy that my gpiolib commit to > linux-pinctrl. I don't see how you can have a merge conflict between this patch that only affects gpiolib.c and something in the pin control tree? The merge window is imminent, so if it is not extremely urgent I would opt to wait until after. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/24/2017 04:28 PM, Linus Walleij wrote: > I don't see how you can have a merge conflict between this > patch that only affects gpiolib.c and something in the pin > control tree? Actually, the merge conflict is because this is missing in the gpio tree: pinctrl: msm: add support to configure ipq40xx GPIO_PULL bits > The merge window is imminent, so if it is not extremely urgent > I would opt to wait until after. As long as it gets into 4.14-final, I don't care which specific RC it appears in. Thanks.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 9568708..3b4e1e8 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1202,6 +1202,14 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data) struct gpio_desc *desc = &gdev->descs[i]; desc->gdev = gdev; + + if (chip->request) { + status = chip->request(chip, i); + if (status < 0) + /* The GPIO is unavailable, so skip it */ + continue; + } + /* * REVISIT: most hardware initializes GPIOs as inputs * (often with pullups enabled) so power usage is @@ -1227,6 +1235,9 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data) */ set_bit(FLAG_IS_OUT, &desc->flags); } + + if (chip->free) + chip->free(chip, i); } #ifdef CONFIG_PINCTRL
Before querying a GPIO to determine its direction, the GPIO should be formally requested. This allows the GPIO driver to block access to unavailable GPIOs, which makes it easier for some drivers to support sparse GPIO maps. Signed-off-by: Timur Tabi <timur@codeaurora.org> --- drivers/gpio/gpiolib.c | 11 +++++++++++ 1 file changed, 11 insertions(+)