linux-kernel - Re: [PATCH] leds: gpio: Fix uninitialized gpio label for fwnode based probe

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: <CACRpkda220vtWPRkkKX+gSPsTuA+VjmKhCDTn8ZeLrkrLd3u8w@mail.gmail.com>
Date:   Wed, 11 Dec 2019 01:44:43 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     Linux LED Subsystem <linux-leds@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Pavel Machek <pavel@....cz>,
        Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH] leds: gpio: Fix uninitialized gpio label for fwnode based probe

On Thu, Dec 5, 2019 at 10:25 PM Jacek Anaszewski
<jacek.anaszewski@...il.com> wrote:

> 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@...aro.org>
> Cc: Pavel Machek <pavel@....cz>
> Cc: Russell King <linux@...linux.org.uk>
> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@...il.com>

Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

Yours,
Linus Walleij