Hi!
> When switching to using generic LED name composition mechanism via
> devm_led_classdev_register_ext() API the part of code initializing
> struct gpio_led's template name property was removed alongside.
> It was however overlooked that the property was also passed to
> devm_fwnode_get_gpiod_from_child() in place of "label" parameter,
> which when set to NULL, results in gpio label being initialized to '?'.
>
> It could be observed in debugfs and failed to properly identify
> gpio association with LED consumer.
>
> Fix this shortcoming by updating the GPIO label after the LED is
> registered and its final name is known.
>
> Fixes: d7235f5feaa0 ("leds: gpio: Use generic support for composing LED names")
> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>
> Cc: Pavel Machek <pavel@xxxxxx>
> Cc: Russell King <linux@xxxxxxxxxxxxxxx>
> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>
Patch looks good, except:
> @@ -151,9 +151,14 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev)
> struct gpio_led led = {};
> const char *state = NULL;
>
> + /**
> + * Acquire gpiod from DT with uninitialized label, which
> + * will be updated after LED class device is registered,
> + * Only then the final LED name is known.
> + */
> led.gpiod = devm_fwnode_get_gpiod_from_child(dev, NULL, child,
> GPIOD_ASIS,
> - led.name);
> + NULL);
This is not linuxdoc, so comment should beging with /* AFAICT.
I'll probably hand-edit the patch.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
