From: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>,
Mark Gross <markgross@kernel.org>,
Andy Shevchenko <andy@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Lee Jones <lee@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Daniel Scally <djrscally@gmail.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: platform-driver-x86@vger.kernel.org, linux-leds@vger.kernel.org,
linux-gpio@vger.kernel.org, Kate Hsuan <hpa@redhat.com>,
Mark Pearson <markpearson@lenovo.com>,
Andy Yeh <andy.yeh@intel.com>, Hao Yao <hao.yao@intel.com>,
linux-media@vger.kernel.org,
Andy Shevchenko <andy.shevchenko@gmail.com>,
artur@madrzak.eu
Subject: Re: [PATCH v5 05/11] [RFC] leds: led-class: Add devicetree support to led_get()
Date: Mon, 25 Aug 2025 15:43:16 +0200 [thread overview]
Message-ID: <eac8ce16-4e63-4092-8729-dc73b3433ece@gmail.com> (raw)
In-Reply-To: <20230120114524.408368-6-hdegoede@redhat.com>
On 1/20/23 12:45, Hans de Goede wrote:
> Turn of_led_get() into a more generic __of_led_get() helper function,
> which can lookup LEDs in devicetree by either name or index.
>
> And use this new helper to add devicetree support to the generic
> (non devicetree specific) [devm_]led_get() function.
>
> This uses the standard devicetree pattern of adding a -names string array
> to map names to the indexes for an array of resources.
>
> Note the new led-names property for LED consumers is not added
> to the devicetree documentation because there seems to be no
> documentation for the leds property itself to extend it with this.
> It seems that how LED consumers should be described is not documented
> at all ATM.
>
> This patch is marked as RFC because of both the missing devicetree
> documentation and because there are no devicetree users of
> the generic [devm_]led_get() function for now.
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hi,
It appears this patch was marked as RFC due some missing dt-bindings and
not having direct DT consumers at the time, and was eventually left out.
With recent inflow of arm64-power laptops (Snapdragon X1E/X1P) which
mostly use MIPI cameras, this feature becomes more desired. I have
rebased this patch onto 6.17-rc2, and can confirm its (still) working as
expected (with respective DT changes) on Dell XPS 9345.
What would be the best approach to revive this patch? For Hans to respin
this? Alternatively I could respin it myself keeping the original
authorship.
Regarding missing dt-binding documentation, would
`Documentation/devicetree/bindings/leds/common.yaml` be the good place
for it? Afaiu it was mentioned that no appropriate LED bindings exists
in this series (3yo), but this binding is ~6yo, so perhaps its not a
right place after all.
Thank you in advance,
Alex
> ---
> drivers/leds/led-class.c | 37 ++++++++++++++++++++++++++++---------
> 1 file changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 0c4b8d8d2b4f..2f3af6e30208 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -234,19 +234,18 @@ static struct led_classdev *led_module_get(struct device *led_dev)
> return led_cdev;
> }
>
> -/**
> - * of_led_get() - request a LED device via the LED framework
> - * @np: device node to get the LED device from
> - * @index: the index of the LED
> - *
> - * Returns the LED device parsed from the phandle specified in the "leds"
> - * property of a device tree node or a negative error-code on failure.
> - */
> -struct led_classdev *of_led_get(struct device_node *np, int index)
> +static struct led_classdev *__of_led_get(struct device_node *np, int index,
> + const char *name)
> {
> struct device *led_dev;
> struct device_node *led_node;
>
> + /*
> + * For named LEDs, first look up the name in the "led-names" property.
> + * If it cannot be found, then of_parse_phandle() will propagate the error.
> + */
> + if (name)
> + index = of_property_match_string(np, "led-names", name);
> led_node = of_parse_phandle(np, "leds", index);
> if (!led_node)
> return ERR_PTR(-ENOENT);
> @@ -256,6 +255,19 @@ struct led_classdev *of_led_get(struct device_node *np, int index)
>
> return led_module_get(led_dev);
> }
> +
> +/**
> + * of_led_get() - request a LED device via the LED framework
> + * @np: device node to get the LED device from
> + * @index: the index of the LED
> + *
> + * Returns the LED device parsed from the phandle specified in the "leds"
> + * property of a device tree node or a negative error-code on failure.
> + */
> +struct led_classdev *of_led_get(struct device_node *np, int index)
> +{
> + return __of_led_get(np, index, NULL);
> +}
> EXPORT_SYMBOL_GPL(of_led_get);
>
> /**
> @@ -329,9 +341,16 @@ EXPORT_SYMBOL_GPL(devm_of_led_get);
> struct led_classdev *led_get(struct device *dev, char *con_id)
> {
> struct led_lookup_data *lookup;
> + struct led_classdev *led_cdev;
> const char *provider = NULL;
> struct device *led_dev;
>
> + if (dev->of_node) {
> + led_cdev = __of_led_get(dev->of_node, -1, con_id);
> + if (!IS_ERR(led_cdev) || PTR_ERR(led_cdev) != -ENOENT)
> + return led_cdev;
> + }
> +
> mutex_lock(&leds_lookup_lock);
> list_for_each_entry(lookup, &leds_lookup_list, list) {
> if (!strcmp(lookup->dev_id, dev_name(dev)) &&
next prev parent reply other threads:[~2025-08-25 13:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 11:45 [PATCH v5 00/11] leds: lookup-table support + int3472/media privacy LED support Hans de Goede
2023-01-20 11:45 ` [PATCH v5 01/11] leds: led-class: Add missing put_device() to led_put() Hans de Goede
2023-01-27 11:00 ` Lee Jones
2023-01-20 11:45 ` [PATCH v5 02/11] leds: led-class: Add led_module_get() helper Hans de Goede
2023-01-27 11:06 ` Lee Jones
2023-01-20 11:45 ` [PATCH v5 03/11] leds: led-class: Add __devm_led_get() helper Hans de Goede
2023-01-27 11:06 ` Lee Jones
2023-01-20 11:45 ` [PATCH v5 04/11] leds: led-class: Add generic [devm_]led_get() Hans de Goede
2023-01-27 11:07 ` Lee Jones
2023-01-20 11:45 ` [PATCH v5 05/11] [RFC] leds: led-class: Add devicetree support to led_get() Hans de Goede
2023-01-27 10:59 ` Lee Jones
2025-08-25 13:43 ` Aleksandrs Vinarskis [this message]
2023-01-20 11:45 ` [PATCH v5 06/11] media: v4l2-core: Built async and fwnode code into videodev.ko Hans de Goede
2023-01-20 12:47 ` Sakari Ailus
2023-01-27 10:01 ` Hans de Goede
2023-01-20 11:45 ` [PATCH v5 07/11] media: v4l2-core: Make the v4l2-core code enable/disable the privacy LED if present Hans de Goede
2023-01-20 12:51 ` Sakari Ailus
2023-01-27 10:29 ` Hans de Goede
2023-01-20 11:45 ` [PATCH v5 08/11] platform/x86: int3472/discrete: Refactor GPIO to sensor mapping Hans de Goede
2023-01-20 11:45 ` [PATCH v5 09/11] platform/x86: int3472/discrete: Create a LED class device for the privacy LED Hans de Goede
2023-01-20 11:45 ` [PATCH v5 10/11] platform/x86: int3472/discrete: Move GPIO request to skl_int3472_register_clock() Hans de Goede
2023-01-20 11:45 ` [PATCH v5 11/11] platform/x86: int3472/discrete: Get the polarity from the _DSM entry Hans de Goede
2023-01-27 11:08 ` [PATCH v5 00/11] leds: lookup-table support + int3472/media privacy LED support Lee Jones
2023-01-27 11:23 ` Hans de Goede
2023-01-27 14:58 ` Lee Jones
2023-01-27 17:14 ` [GIT PULL] Immutable branch from LEDs due for the v6.3 merge window Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eac8ce16-4e63-4092-8729-dc73b3433ece@gmail.com \
--to=alex.vinarskis@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=andy.yeh@intel.com \
--cc=andy@kernel.org \
--cc=artur@madrzak.eu \
--cc=bryan.odonoghue@linaro.org \
--cc=djrscally@gmail.com \
--cc=hao.yao@intel.com \
--cc=hdegoede@redhat.com \
--cc=hpa@redhat.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=markpearson@lenovo.com \
--cc=mchehab@kernel.org \
--cc=pavel@ucw.cz \
--cc=platform-driver-x86@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.