In gpio_leds_create(), when devm_get_gpiod_from_child() fails with
-EPROBE_DEFER on the second gpio led to be created, the first already
registered led is not torn down properly. This causes create_gpio_led()
to fail for the first led on re-probe().
Fix this misbehaviour by incrementing num_leds only if all
potentially failing calls completed successfully.
Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Bryan Wu <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
drivers/leds/leds-gpio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index d26af0a79a90..f2eb13805b92 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -217,18 +217,19 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev)
if (fwnode_property_present(child, "retain-state-suspended"))
led.retain_state_suspended = 1;
- ret = create_gpio_led(&led, &priv->leds[priv->num_leds++],
+ ret = create_gpio_led(&led, &priv->leds[priv->num_leds],
dev, NULL);
if (ret < 0) {
fwnode_handle_put(child);
goto err;
}
+ priv->num_leds++;
}
return priv;
err:
- for (count = priv->num_leds - 2; count >= 0; count--)
+ for (count = priv->num_leds - 1; count >= 0; count--)
delete_gpio_led(&priv->leds[count]);
return ERR_PTR(ret);
}
--
2.1.0
Hi Sebastian,
On 04/14/2015 11:23 PM, Sebastian Hesselbarth wrote:
> In gpio_leds_create(), when devm_get_gpiod_from_child() fails with
> -EPROBE_DEFER on the second gpio led to be created, the first already
> registered led is not torn down properly. This causes create_gpio_led()
> to fail for the first led on re-probe().
>
> Fix this misbehaviour by incrementing num_leds only if all
> potentially failing calls completed successfully.
>
> Signed-off-by: Sebastian Hesselbarth <[email protected]>
> ---
> Cc: Bryan Wu <[email protected]>
> Cc: Richard Purdie <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> ---
> drivers/leds/leds-gpio.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
For this patch:
Acked-by: Jacek Anaszewski <[email protected]>
I have a question regarding the sequence above on line 201:
if (!led.name)
return ERR_PTR(-EINVAL);
Shouldn't this be also 'goto err"?
--
Best Regards,
Jacek Anaszewski
On 04/15/2015 11:11 AM, Jacek Anaszewski wrote:
> On 04/14/2015 11:23 PM, Sebastian Hesselbarth wrote:
>> In gpio_leds_create(), when devm_get_gpiod_from_child() fails with
>> -EPROBE_DEFER on the second gpio led to be created, the first already
>> registered led is not torn down properly. This causes create_gpio_led()
>> to fail for the first led on re-probe().
>>
>> Fix this misbehaviour by incrementing num_leds only if all
>> potentially failing calls completed successfully.
>>
>> Signed-off-by: Sebastian Hesselbarth <[email protected]>
>> ---
>> Cc: Bryan Wu <[email protected]>
>> Cc: Richard Purdie <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> ---
>> drivers/leds/leds-gpio.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> For this patch:
>
> Acked-by: Jacek Anaszewski <[email protected]>
Jacek, Thanks!
> I have a question regarding the sequence above on line 201:
>
> if (!led.name)
> return ERR_PTR(-EINVAL);
>
> Shouldn't this be also 'goto err"?
Yes, every error within the loop has to goto the err label.
Mind to send a patch fixing it?
Sebastian
On 04/15/2015 11:29 AM, Sebastian Hesselbarth wrote:
> On 04/15/2015 11:11 AM, Jacek Anaszewski wrote:
>> On 04/14/2015 11:23 PM, Sebastian Hesselbarth wrote:
>>> In gpio_leds_create(), when devm_get_gpiod_from_child() fails with
>>> -EPROBE_DEFER on the second gpio led to be created, the first already
>>> registered led is not torn down properly. This causes create_gpio_led()
>>> to fail for the first led on re-probe().
>>>
>>> Fix this misbehaviour by incrementing num_leds only if all
>>> potentially failing calls completed successfully.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <[email protected]>
>>> ---
>>> Cc: Bryan Wu <[email protected]>
>>> Cc: Richard Purdie <[email protected]>
>>> Cc: [email protected]
>>> Cc: [email protected]
>>> ---
>>> drivers/leds/leds-gpio.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> For this patch:
>>
>> Acked-by: Jacek Anaszewski <[email protected]>
>
> Jacek, Thanks!
>
>> I have a question regarding the sequence above on line 201:
>>
>> if (!led.name)
>> return ERR_PTR(-EINVAL);
>>
>> Shouldn't this be also 'goto err"?
>
> Yes, every error within the loop has to goto the err label.
> Mind to send a patch fixing it?
OK, I'll take care of it.
--
Best Regards,
Jacek Anaszewski
On Wed, Apr 15, 2015 at 2:11 AM, Jacek Anaszewski
<[email protected]> wrote:
> Hi Sebastian,
>
> On 04/14/2015 11:23 PM, Sebastian Hesselbarth wrote:
>>
>> In gpio_leds_create(), when devm_get_gpiod_from_child() fails with
>> -EPROBE_DEFER on the second gpio led to be created, the first already
>> registered led is not torn down properly. This causes create_gpio_led()
>> to fail for the first led on re-probe().
>>
>> Fix this misbehaviour by incrementing num_leds only if all
>> potentially failing calls completed successfully.
>>
>> Signed-off-by: Sebastian Hesselbarth <[email protected]>
>> ---
>> Cc: Bryan Wu <[email protected]>
>> Cc: Richard Purdie <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> ---
>> drivers/leds/leds-gpio.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>
> For this patch:
>
> Acked-by: Jacek Anaszewski <[email protected]>
>
Thanks, I merged it.
-Bryan
> I have a question regarding the sequence above on line 201:
>
> if (!led.name)
> return ERR_PTR(-EINVAL);
>
> Shouldn't this be also 'goto err"?
>
> --
> Best Regards,
> Jacek Anaszewski