Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[PATCH RESEND] gpio: of_get_named_gpio_flags() return -EPROBE_DEFER if GPIO not yet available
243 views
Skip to first unread message
Roland Stigge
Jun 27, 2012, 6:40:02 PM6/27/12
to
of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
respective GPIO is not (yet) available. This is useful if driver's probe()
functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
can be probed again later on.
The function still returns -EINVAL on other errors (parse error or node doesn't
exist). This way, the case of an optional/intentionally missing GPIO is handled
appropriately.
Signed-off-by: Roland Stigge <sti...@antcom.de>
Acked-by: Linus Walleij <linus....@linaro.org>
---
Applies to v3.5-rc4
drivers/gpio/gpiolib-of.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- linux-2.6.orig/drivers/gpio/gpiolib-of.c
+++ linux-2.6/drivers/gpio/gpiolib-of.c
@@ -62,7 +62,10 @@ static int of_gpiochip_find_and_xlate(st
int of_get_named_gpio_flags(struct device_node *np, const char *propname,
int index, enum of_gpio_flags *flags)
{
- struct gg_data gg_data = { .flags = flags, .out_gpio = -ENODEV };
+ /* Return -EPROBE_DEFER to support probe() functions to be called
+ * later when the GPIO actually becomes available
+ */
+ struct gg_data gg_data = { .flags = flags, .out_gpio = -EPROBE_DEFER };
int ret;
/* .of_xlate might decide to not fill in the flags, so clear it. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
respective GPIO is not (yet) available. This is useful if driver's probe()
functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
can be probed again later on.
The function still returns -EINVAL on other errors (parse error or node doesn't
exist). This way, the case of an optional/intentionally missing GPIO is handled
appropriately.
Signed-off-by: Roland Stigge <sti...@antcom.de>
Acked-by: Linus Walleij <linus....@linaro.org>
---
Applies to v3.5-rc4
drivers/gpio/gpiolib-of.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- linux-2.6.orig/drivers/gpio/gpiolib-of.c
+++ linux-2.6/drivers/gpio/gpiolib-of.c
@@ -62,7 +62,10 @@ static int of_gpiochip_find_and_xlate(st
int of_get_named_gpio_flags(struct device_node *np, const char *propname,
int index, enum of_gpio_flags *flags)
{
- struct gg_data gg_data = { .flags = flags, .out_gpio = -ENODEV };
+ /* Return -EPROBE_DEFER to support probe() functions to be called
+ * later when the GPIO actually becomes available
+ */
+ struct gg_data gg_data = { .flags = flags, .out_gpio = -EPROBE_DEFER };
int ret;
/* .of_xlate might decide to not fill in the flags, so clear it. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Walleij
Jul 14, 2012, 4:00:01 PM7/14/12
to
On Thu, Jun 28, 2012 at 12:32 AM, Roland Stigge <sti...@antcom.de> wrote:
> of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
> respective GPIO is not (yet) available. This is useful if driver's probe()
> functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
> can be probed again later on.
>
> The function still returns -EINVAL on other errors (parse error or node doesn't
> exist). This way, the case of an optional/intentionally missing GPIO is handled
> appropriately.
>
> Signed-off-by: Roland Stigge <sti...@antcom.de>
> Acked-by: Linus Walleij <linus....@linaro.org>
If I understand correctly this relates closely to another patch from Mark Brown
> of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
> respective GPIO is not (yet) available. This is useful if driver's probe()
> functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
> can be probed again later on.
>
> The function still returns -EINVAL on other errors (parse error or node doesn't
> exist). This way, the case of an optional/intentionally missing GPIO is handled
> appropriately.
>
> Signed-off-by: Roland Stigge <sti...@antcom.de>
> Acked-by: Linus Walleij <linus....@linaro.org>
we discussed the other day (sorry for missing this patch, which arrived
earlier, for a while).
Mark/Grant can you look at this patch?
Yours,
Linus Walleij
Mark Brown
Jul 15, 2012, 5:20:01 PM7/15/12
to
On Sat, Jul 14, 2012 at 09:57:08PM +0200, Linus Walleij wrote:
> If I understand correctly this relates closely to another patch from Mark Brown
> we discussed the other day (sorry for missing this patch, which arrived
> earlier, for a while).
> Mark/Grant can you look at this patch?
Not unless I have a copy of it, no... I had thought a version of this
> If I understand correctly this relates closely to another patch from Mark Brown
> we discussed the other day (sorry for missing this patch, which arrived
> earlier, for a while).
> Mark/Grant can you look at this patch?
had been submitted already and was in a similar place to the one for
gpio_request().
Linus Walleij
Jul 16, 2012, 6:20:02 PM7/16/12
to
On Sun, Jul 15, 2012 at 11:11 PM, Mark Brown
<bro...@opensource.wolfsonmicro.com> wrote:
> On Sat, Jul 14, 2012 at 09:57:08PM +0200, Linus Walleij wrote:
>
>> If I understand correctly this relates closely to another patch from Mark Brown
>> we discussed the other day (sorry for missing this patch, which arrived
>> earlier, for a while).
>
>> Mark/Grant can you look at this patch?
>
> Not unless I have a copy of it, no...
Sorry, forwarded a copy to you.
<bro...@opensource.wolfsonmicro.com> wrote:
> On Sat, Jul 14, 2012 at 09:57:08PM +0200, Linus Walleij wrote:
>
>> If I understand correctly this relates closely to another patch from Mark Brown
>> we discussed the other day (sorry for missing this patch, which arrived
>> earlier, for a while).
>
>> Mark/Grant can you look at this patch?
>
> Not unless I have a copy of it, no...
> I had thought a version of this
> had been submitted already and was in a similar place to the one for
> gpio_request().
Mark Brown
Jul 17, 2012, 3:50:02 AM7/17/12
to
On Tue, Jul 17, 2012 at 12:16:48AM +0200, Linus Walleij wrote:
> On Sun, Jul 15, 2012 at 11:11 PM, Mark Brown
> On Sun, Jul 15, 2012 at 11:11 PM, Mark Brown
> > I had thought a version of this
> > had been submitted already and was in a similar place to the one for
> > gpio_request().
> Me to...
Greg just merged the driver core patch for pushing the deferred devices
> > had been submitted already and was in a similar place to the one for
> > gpio_request().
> Me to...
to the end of the dpm list before reprobing them which should address
Grant's concern about doing this in gpiolib.
Linus Walleij
Jul 17, 2012, 2:20:02 PM7/17/12
to
Yours,
Linus Walleij
Jul 17, 2012, 2:30:02 PM7/17/12
to
> of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
> respective GPIO is not (yet) available. This is useful if driver's probe()
> functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
> can be probed again later on.
>
> The function still returns -EINVAL on other errors (parse error or node doesn't
> exist). This way, the case of an optional/intentionally missing GPIO is handled
> appropriately.
>
> Signed-off-by: Roland Stigge <sti...@antcom.de>
Patch applied, if all gpio stuff shall defer properly in v3.6 we need this
> respective GPIO is not (yet) available. This is useful if driver's probe()
> functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
> can be probed again later on.
>
> The function still returns -EINVAL on other errors (parse error or node doesn't
> exist). This way, the case of an optional/intentionally missing GPIO is handled
> appropriately.
>
> Signed-off-by: Roland Stigge <sti...@antcom.de>
so let's do some testing in -next!
Would be nice to get some ACK besides my own...
Yours,
Linus Walleij
Alexandre Pereira da Silva
Jul 17, 2012, 2:40:02 PM7/17/12
to
On Tue, Jul 17, 2012 at 3:24 PM, Linus Walleij <linus....@linaro.org> wrote:
> On Thu, Jun 28, 2012 at 12:32 AM, Roland Stigge <sti...@antcom.de> wrote:
>
>> of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
>> respective GPIO is not (yet) available. This is useful if driver's probe()
>> functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
>> can be probed again later on.
>>
>> The function still returns -EINVAL on other errors (parse error or node doesn't
>> exist). This way, the case of an optional/intentionally missing GPIO is handled
>> appropriately.
>>
>> Signed-off-by: Roland Stigge <sti...@antcom.de>
>
> Patch applied, if all gpio stuff shall defer properly in v3.6 we need this
> so let's do some testing in -next!
>
> Would be nice to get some ACK besides my own...
You can add mine. I've been using this patch for quite some time now.
> On Thu, Jun 28, 2012 at 12:32 AM, Roland Stigge <sti...@antcom.de> wrote:
>
>> of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
>> respective GPIO is not (yet) available. This is useful if driver's probe()
>> functions try to get a GPIO whose controller isn't probed yet. Thus, the driver
>> can be probed again later on.
>>
>> The function still returns -EINVAL on other errors (parse error or node doesn't
>> exist). This way, the case of an optional/intentionally missing GPIO is handled
>> appropriately.
>>
>> Signed-off-by: Roland Stigge <sti...@antcom.de>
>
> Patch applied, if all gpio stuff shall defer properly in v3.6 we need this
> so let's do some testing in -next!
>
> Would be nice to get some ACK besides my own...
Acked-by: Alexandre Pereira da Silva <alete...@gmail.com>
0 new messages