linux-kernel - Re: [PATCH 1/4] leds: rgb: leds-group-multicolor: allow leds to stay on in suspend

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: <05f9c78d-b398-420e-bc0f-fb642e76efdc@traphandler.com>
Date: Wed, 31 Jan 2024 08:39:01 +0100
From: Jean-Jacques Hiblot <jjhiblot@...phandler.com>
To: Aren Moynihan <aren@...cevolution.org>, <linux-kernel@...r.kernel.org>
CC: Miles Alan <m@...esalan.com>, Ondrej Jirman <megi@....cz>, Lee Jones
	<lee@...nel.org>, Pavel Machek <pavel@....cz>, <linux-leds@...r.kernel.org>
Subject: Re: [PATCH 1/4] leds: rgb: leds-group-multicolor: allow leds to stay
 on in suspend



On 28/01/2024 21:45, Aren Moynihan wrote:
> If none of the managed leds enable LED_CORE_SUSPENDRESUME, then we
> shouldn't need to set it here. This makes it possible to use multicolor
> groups with gpio leds that enable retain-state-suspended in the device
> tree.
> 
> Signed-off-by: Aren Moynihan <aren@...cevolution.org>
> ---
> 
>   drivers/leds/rgb/leds-group-multicolor.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/leds/rgb/leds-group-multicolor.c b/drivers/leds/rgb/leds-group-multicolor.c
> index 39f58be32af5..194c6a33640b 100644
> --- a/drivers/leds/rgb/leds-group-multicolor.c
> +++ b/drivers/leds/rgb/leds-group-multicolor.c
> @@ -69,7 +69,7 @@ static int leds_gmc_probe(struct platform_device *pdev)
>   	struct mc_subled *subled;
>   	struct leds_multicolor *priv;
>   	unsigned int max_brightness = 0;
> -	int i, ret, count = 0;
> +	int i, ret, count, common_flags = 0;

count is not initialized anymore. Isn't it a problem ?
>   
>   	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>   	if (!priv)
> @@ -91,6 +91,7 @@ static int leds_gmc_probe(struct platform_device *pdev)
>   		if (!priv->monochromatics)
>   			return -ENOMEM;
>   
> +		common_flags |= led_cdev->flags;
>   		priv->monochromatics[count] = led_cdev;
>   
>   		max_brightness = max(max_brightness, led_cdev->max_brightness);
> @@ -114,12 +115,15 @@ static int leds_gmc_probe(struct platform_device *pdev)
>   
>   	/* Initialise the multicolor's LED class device */
>   	cdev = &priv->mc_cdev.led_cdev;
> -	cdev->flags = LED_CORE_SUSPENDRESUME;
>   	cdev->brightness_set_blocking = leds_gmc_set;
>   	cdev->max_brightness = max_brightness;
>   	cdev->color = LED_COLOR_ID_MULTI;
>   	priv->mc_cdev.num_colors = count;
>   
> +	/* we only need suspend/resume if a sub-led requests it */
> +	if (common_flags & LED_CORE_SUSPENDRESUME)
> +		cdev->flags = LED_CORE_SUSPENDRESUME;
> +
>   	init_data.fwnode = dev_fwnode(dev);
>   	ret = devm_led_classdev_multicolor_register_ext(dev, &priv->mc_cdev, &init_data);
>   	if (ret)