From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH 0/2] [v5] pinctrl: qcom: add support for sparse GPIOs Date: Wed, 11 Oct 2017 09:51:08 +0200 Message-ID: References: <1504798409-32041-1-git-send-email-timur@codeaurora.org> <20170919070422.GI3349@codeaurora.org> <1ecdf6ee-5098-15d3-f85e-66b39a6c25f9@codeaurora.org> <619f48d2-59c7-c090-4ace-9e8db9f92064@codeaurora.org> <255ad0dc-2d16-ae7f-0b45-500e23cff1a4@codeaurora.org> <20171003220311.GU457@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from mail-it0-f49.google.com ([209.85.214.49]:46146 "EHLO mail-it0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932498AbdJKHvJ (ORCPT ); Wed, 11 Oct 2017 03:51:09 -0400 Received: by mail-it0-f49.google.com with SMTP id f187so1878739itb.1 for ; Wed, 11 Oct 2017 00:51:09 -0700 (PDT) In-Reply-To: <20171003220311.GU457@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Stephen Boyd Cc: Timur Tabi , Andy Gross , David Brown , anjiandi@codeaurora.org, Bjorn Andersson , "linux-gpio@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , "thierry.reding@gmail.com" , Mika Westerberg , Andy Shevchenko On Wed, Oct 4, 2017 at 12:03 AM, Stephen Boyd wrote: > Could we remove the pin direction finding part here in > gpiochip_add_pin_range() and lazily resolve the pin direction > when a pin is requested? We would need a similar check in the msm > specific debugfs code where we skip pins that aren't requested. > This is basically a revert of commit 72d320006177 ("gpio: set up > initial state from .get_direction()"). It seems reasonable for the gpiolib to be able to call this function immediately after registering the new GPIO chip with its vtable. I think it is more up to the driver to numb the reply with some dummy return value (i.e. input mode) or refactor the callback so that it is acceptable for gpiolib to get an -EINVAL or so from the driver (again it will assume input mode) if the driver can't return the direction at this time. Yours, Linus Walleij From mboxrd@z Thu Jan 1 00:00:00 1970 From: linus.walleij@linaro.org (Linus Walleij) Date: Wed, 11 Oct 2017 09:51:08 +0200 Subject: [PATCH 0/2] [v5] pinctrl: qcom: add support for sparse GPIOs In-Reply-To: <20171003220311.GU457@codeaurora.org> References: <1504798409-32041-1-git-send-email-timur@codeaurora.org> <20170919070422.GI3349@codeaurora.org> <1ecdf6ee-5098-15d3-f85e-66b39a6c25f9@codeaurora.org> <619f48d2-59c7-c090-4ace-9e8db9f92064@codeaurora.org> <255ad0dc-2d16-ae7f-0b45-500e23cff1a4@codeaurora.org> <20171003220311.GU457@codeaurora.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Oct 4, 2017 at 12:03 AM, Stephen Boyd wrote: > Could we remove the pin direction finding part here in > gpiochip_add_pin_range() and lazily resolve the pin direction > when a pin is requested? We would need a similar check in the msm > specific debugfs code where we skip pins that aren't requested. > This is basically a revert of commit 72d320006177 ("gpio: set up > initial state from .get_direction()"). It seems reasonable for the gpiolib to be able to call this function immediately after registering the new GPIO chip with its vtable. I think it is more up to the driver to numb the reply with some dummy return value (i.e. input mode) or refactor the callback so that it is acceptable for gpiolib to get an -EINVAL or so from the driver (again it will assume input mode) if the driver can't return the direction at this time. Yours, Linus Walleij