Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191205212501.9163-1-jacek.anaszewski@gmail.com>
In-Reply-To: <20191205212501.9163-1-jacek.anaszewski@gmail.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Wed, 11 Dec 2019 01:44:43 +0100
Message-ID: <CACRpkda220vtWPRkkKX+gSPsTuA+VjmKhCDTn8ZeLrkrLd3u8w@mail.gmail.com>
Subject: Re: [PATCH] leds: gpio: Fix uninitialized gpio label for fwnode based probe
To:     Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc:     Linux LED Subsystem <linux-leds@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Pavel Machek <pavel@ucw.cz>,
        Russell King <linux@armlinux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Dec 5, 2019 at 10:25 PM Jacek Anaszewski
<jacek.anaszewski@gmail.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@linaro.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

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

Yours,
Linus Walleij