linux-kernel - Re: [PATCH RESEND] leds: leds-gpio: Defer probing in case of deferred gpio probing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK5ve-J4prh2GSOsM6iadOgOey9K05PuqH9Y5Yfj8+GwLqKxnQ@mail.gmail.com>
Date:	Wed, 7 Nov 2012 16:28:37 -0800
From:	Bryan Wu <cooloney@...il.com>
To:	Roland Stigge <stigge@...com.de>
Cc:	rpurdie@...ys.net, linux-leds@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] leds: leds-gpio: Defer probing in case of deferred
 gpio probing

On Wed, Nov 7, 2012 at 5:06 AM, Roland Stigge <stigge@...com.de> wrote:
> This patch makes leds-gpio's probe() return -EPROBE_DEFER if any of the gpios
> to register are deferred themselves. This makes a change of
> gpio_leds_create_of()'s return value necessary: Instead of returning NULL on
> error, we now use ERR_PTR() error coding.
>
> Signed-off-by: Roland Stigge <stigge@...com.de>

Sorry about this, actually I've already merged it into my for-next
branch and forgot to reply this email.
It's here: http://git.kernel.org/?p=linux/kernel/git/cooloney/linux-leds.git;a=commitdiff;h=424f58e4cebd76458b44e69ed31f7297808770cd
So is the same one as here?

-Bryan

> ---
>  drivers/leds/leds-gpio.c |   17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
>
> --- linux-2.6.orig/drivers/leds/leds-gpio.c
> +++ linux-2.6/drivers/leds/leds-gpio.c
> @@ -21,6 +21,7 @@
>  #include <linux/workqueue.h>
>  #include <linux/module.h>
>  #include <linux/pinctrl/consumer.h>
> +#include <linux/err.h>
>
>  struct gpio_led_data {
>         struct led_classdev cdev;
> @@ -176,12 +177,16 @@ static struct gpio_leds_priv * __devinit
>         /* count LEDs in this device, so we know how much to allocate */
>         count = of_get_child_count(np);
>         if (!count)
> -               return NULL;
> +               return ERR_PTR(-ENODEV);
> +
> +       for_each_child_of_node(np, child)
> +               if (of_get_gpio(child, 0) == -EPROBE_DEFER)
> +                       return ERR_PTR(-EPROBE_DEFER);
>
>         priv = devm_kzalloc(&pdev->dev, sizeof_gpio_leds_priv(count),
>                         GFP_KERNEL);
>         if (!priv)
> -               return NULL;
> +               return ERR_PTR(-ENOMEM);
>
>         for_each_child_of_node(np, child) {
>                 struct gpio_led led = {};
> @@ -216,7 +221,7 @@ static struct gpio_leds_priv * __devinit
>  err:
>         for (count = priv->num_leds - 2; count >= 0; count--)
>                 delete_gpio_led(&priv->leds[count]);
> -       return NULL;
> +       return ERR_PTR(-ENODEV);
>  }
>
>  static const struct of_device_id of_gpio_leds_match[] = {
> @@ -226,7 +231,7 @@ static const struct of_device_id of_gpio
>  #else /* CONFIG_OF_GPIO */
>  static struct gpio_leds_priv * __devinit gpio_leds_create_of(struct platform_device *pdev)
>  {
> -       return NULL;
> +       return ERR_PTR(-ENODEV);
>  }
>  #endif /* CONFIG_OF_GPIO */
>
> @@ -264,8 +269,8 @@ static int __devinit gpio_led_probe(stru
>                 }
>         } else {
>                 priv = gpio_leds_create_of(pdev);
> -               if (!priv)
> -                       return -ENODEV;
> +               if (IS_ERR(priv))
> +                       return PTR_ERR(priv);
>         }
>
>         platform_set_drvdata(pdev, priv);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/