mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Rosen Penev <rosenp@gmail.com>
Cc: linux-leds@vger.kernel.org, Pavel Machek <pavel@kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] leds: rgb: qcom-lpg: Use fwnode APIs for LED parsing
Date: Thu, 17 Sep 2026 15:33:17 +0100	[thread overview]
Message-ID: <20260917143317.GL1605367@google.com> (raw)
In-Reply-To: <20260908053221.29955-1-rosenp@gmail.com>

On Mon, 07 Sep 2026, Rosen Penev wrote:

> Convert LED and channel parsing in lpg_add_led() and
> lpg_parse_channel() from DT-specific helpers to the fwnode API.
> The probe loop now uses device_for_each_child_node_scoped(),
> dropping explicit node lifetime handling.
> 
> Behaviour is unchanged for device tree: fwnode_get_child_node_count()
> and both child iteration helpers skip unavailable children on OF,
> and the fwnode handle is passed straight to LED registration.
> 
> cdev->default_trigger is only assigned when
> fwnode_property_read_string() succeeds, so an absent
> linux,default-trigger property no longer yields an uninitialized
> pointer.
> 
> Assisted-by: opencode:deepseek-v4-flash-free
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  drivers/leds/rgb/leds-qcom-lpg.c | 36 ++++++++++++++++++--------------
>  1 file changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c
> index d7d6518de30f..dcc8e6f14c8b 100644
> --- a/drivers/leds/rgb/leds-qcom-lpg.c
> +++ b/drivers/leds/rgb/leds-qcom-lpg.c
> @@ -11,6 +11,7 @@
>  #include <linux/nvmem-consumer.h>
>  #include <linux/of.h>
>  #include <linux/platform_device.h>
> +#include <linux/property.h>
>  #include <linux/pwm.h>
>  #include <linux/regmap.h>
>  #include <linux/slab.h>
> @@ -1342,7 +1343,7 @@ static int lpg_add_pwm(struct lpg *lpg)
>  	return ret;
>  }
>  
> -static int lpg_parse_channel(struct lpg *lpg, struct device_node *np,
> +static int lpg_parse_channel(struct lpg *lpg, struct fwnode_handle *fw,
>  			     struct lpg_channel **channel)
>  {
>  	struct lpg_channel *chan;
> @@ -1350,17 +1351,18 @@ static int lpg_parse_channel(struct lpg *lpg, struct device_node *np,
>  	u32 reg;
>  	int ret;
>  
> -	ret = of_property_read_u32(np, "reg", &reg);
> +	ret = fwnode_property_read_u32(fw, "reg", &reg);
>  	if (ret || !reg || reg > lpg->num_channels)
> -		return dev_err_probe(lpg->dev, -EINVAL, "invalid \"reg\" of %pOFn\n", np);
> +		return dev_err_probe(lpg->dev, -EINVAL,
> +				     "invalid \"reg\" of %s\n", fwnode_get_name(fw));
>  
>  	chan = &lpg->channels[reg - 1];
>  	chan->in_use = true;
>  
> -	ret = of_property_read_u32(np, "color", &color);
> +	ret = fwnode_property_read_u32(fw, "color", &color);
>  	if (ret < 0 && ret != -EINVAL)
>  		return dev_err_probe(lpg->dev, ret,
> -				     "failed to parse \"color\" of %pOF\n", np);
> +				     "failed to parse \"color\" of %s\n", fwnode_get_name(fw));
>  
>  	chan->color = color;
>  
> @@ -1369,25 +1371,26 @@ static int lpg_parse_channel(struct lpg *lpg, struct device_node *np,
>  	return 0;
>  }
>  
> -static int lpg_add_led(struct lpg *lpg, struct device_node *np)
> +static int lpg_add_led(struct lpg *lpg, struct fwnode_handle *fw)
>  {
>  	struct led_init_data init_data = {};
>  	struct led_classdev *cdev;
>  	struct mc_subled *info;
>  	struct lpg_led *led;
> +	const char *trigger;
>  	const char *state;
>  	int num_channels;
>  	u32 color = 0;
>  	int ret;
>  	int i;
>  
> -	ret = of_property_read_u32(np, "color", &color);
> +	ret = fwnode_property_read_u32(fw, "color", &color);
>  	if (ret < 0 && ret != -EINVAL)
>  		return dev_err_probe(lpg->dev, ret,
> -			      "failed to parse \"color\" of %pOF\n", np);
> +			      "failed to parse \"color\" of %s\n", fwnode_get_name(fw));
>  
>  	if (color == LED_COLOR_ID_RGB || color == LED_COLOR_ID_MULTI)
> -		num_channels = of_get_available_child_count(np);
> +		num_channels = fwnode_get_child_node_count(fw);

Are you sure 'fwnode_get_child_node_count()' skips unavailable children?  It
counts all children, whereas 'of_get_available_child_count()' only counted
available ones.  If there are disabled child nodes, 'led->mcdev.num_colors' will
be larger than the number of populated subleds, leading to uninitialised memory
access in the LED core.  Should we be using 'i' for 'num_colors' instead, or
counting available nodes properly?

>  	else
>  		num_channels = 1;
>  
> @@ -1403,7 +1406,7 @@ static int lpg_add_led(struct lpg *lpg, struct device_node *np)
>  		if (!info)
>  			return -ENOMEM;
>  		i = 0;
> -		for_each_available_child_of_node_scoped(np, child) {
> +		fwnode_for_each_available_child_node_scoped(fw, child) {
>  			ret = lpg_parse_channel(lpg, child, &led->channels[i]);
>  			if (ret < 0)
>  				return ret;
> @@ -1426,7 +1429,7 @@ static int lpg_add_led(struct lpg *lpg, struct device_node *np)
>  			cdev->pattern_clear = lpg_pattern_mc_clear;
>  		}
>  	} else {
> -		ret = lpg_parse_channel(lpg, np, &led->channels[0]);
> +		ret = lpg_parse_channel(lpg, fw, &led->channels[0]);
>  		if (ret < 0)
>  			return ret;
>  
> @@ -1441,14 +1444,15 @@ static int lpg_add_led(struct lpg *lpg, struct device_node *np)
>  		}
>  	}
>  
> -	cdev->default_trigger = of_get_property(np, "linux,default-trigger", NULL);
> +	if (!fwnode_property_read_string(fw, "linux,default-trigger", &trigger))
> +		cdev->default_trigger = trigger;
>  
>  	if (lpg->lpg_chan_sdam)
>  		cdev->max_brightness = PPG_MAX_LED_BRIGHTNESS;
>  	else
>  		cdev->max_brightness = LPG_RESOLUTION_9BIT - 1;
>  
> -	if (!of_property_read_string(np, "default-state", &state) &&
> +	if (!fwnode_property_read_string(fw, "default-state", &state) &&
>  	    !strcmp(state, "on"))
>  		cdev->brightness = cdev->max_brightness;
>  	else
> @@ -1456,7 +1460,7 @@ static int lpg_add_led(struct lpg *lpg, struct device_node *np)
>  
>  	cdev->brightness_set_blocking(cdev, cdev->brightness);
>  
> -	init_data.fwnode = of_fwnode_handle(np);
> +	init_data.fwnode = fw;
>  
>  	if (color == LED_COLOR_ID_RGB || color == LED_COLOR_ID_MULTI)
>  		ret = devm_led_classdev_multicolor_register_ext(lpg->dev, &led->mcdev, &init_data);
> @@ -1638,8 +1642,8 @@ static int lpg_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> -	for_each_available_child_of_node_scoped(pdev->dev.of_node, np) {
> -		ret = lpg_add_led(lpg, np);
> +	device_for_each_child_node_scoped(&pdev->dev, child) {
> +		ret = lpg_add_led(lpg, child);
>  		if (ret)
>  			return ret;
>  	}
> -- 
> 2.55.0
> 

-- 
Lee Jones

  reply	other threads:[~2026-09-17 14:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08  5:32 Rosen Penev
2026-09-17 14:33 ` Lee Jones [this message]
2026-09-17 18:42   ` Rosen Penev

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=20260917143317.GL1605367@google.com \
    --to=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@kernel.org \
    --cc=rosenp@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®