Received-SPF: pass (google.com: domain of linux-kernel+bounces-47504-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 31 Jan 2024 20:39:56 -0500
From: Aren <aren@peacevolution.org>
To: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Cc: linux-kernel@vger.kernel.org, Miles Alan <m@milesalan.com>, 
	Ondrej Jirman <megi@xff.cz>, Lee Jones <lee@kernel.org>, Pavel Machek <pavel@ucw.cz>, 
	linux-leds@vger.kernel.org
Subject: Re: [PATCH 1/4] leds: rgb: leds-group-multicolor: allow leds to stay
 on in suspend
Message-ID: <oq4zwh56l5zzhvrrvpqrhhb3ghuo5trnezkxhgb63wquhjkhhx@wajib2nwytxf>
References: <20240128204740.2355092-1-aren@peacevolution.org>
 <05f9c78d-b398-420e-bc0f-fb642e76efdc@traphandler.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <05f9c78d-b398-420e-bc0f-fb642e76efdc@traphandler.com>

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@peacevolution.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)