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: <oq4zwh56l5zzhvrrvpqrhhb3ghuo5trnezkxhgb63wquhjkhhx@wajib2nwytxf>
Date: Wed, 31 Jan 2024 20:39:56 -0500
From: Aren <aren@...cevolution.org>
To: Jean-Jacques Hiblot <jjhiblot@...phandler.com>
Cc: linux-kernel@...r.kernel.org, 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 Wed, Jan 31, 2024 at 08:39:01AM +0100, Jean-Jacques Hiblot wrote:
> 
> 
> 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 ?

Yes, good catch, thanks!

I'm not sure how I missed that when I tested this, I must've gotten
(un)lucky with the value that was in ram before.

 - Aren

> >   	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)