From: Lee Jones <lee@kernel.org>
To: Stefan Wahren <wahrenst@gmx.net>
Cc: sashiko-reviews@lists.linux.dev, linux-leds@vger.kernel.org,
devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
Jonas Rebmann <jre@pengutronix.de>
Subject: Re: [PATCH V4] leds: rgb: leds-group-multicolor: Implement default-intensity
Date: Thu, 27 Aug 2026 18:03:01 +0100 [thread overview]
Message-ID: <20260827170301.GI2943942@google.com> (raw)
In-Reply-To: <aaeb87f7-5a04-4592-ab59-b4114b005aab@gmx.net>
On Thu, 13 Aug 2026, Stefan Wahren wrote:
> Hi,
>
> Am 13.08.26 um 11:53 schrieb Lee Jones:
> > On Thu, 13 Aug 2026, sashiko-bot@kernel.org wrote:
> >
> > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > - [Medium] The `default-intensity` property read from individual monochromatic LED nodes is applied to the multicolor group without rescaling, causing incorrect brightness calculations.
> > Please review, explain or fix the Sashiko review(s).
> >
> > If this is a set, this request includes the other patches too.
> Sorry, I don't get the problem with "incorrect brightness calculation", I
> tought the intensity setting is independent from the brightness. Btw the
> intensity is applied to the monochromatic LED not to the group itself.
> hallucination?
>
> Does mixing PWM and GPIO LED in a RGB multicolor group make sense at all?
I asked my little helper for you:
<gemini>
While mixing a GPIO LED (essentially binary) and a PWM LED in a single
multicolor group is technically possible, it is indeed highly unusual and
unlikely to produce a desirable colour-mixing effect in practice.
Regarding the Sashiko review, there is a valid point hidden in the noise.
The multicolor framework uses 'subled[i].intensity' as a relative ratio
against the overall group's 'max_brightness'. If a sub-LED's native
intensity scale differs from the group's scale, assigning the raw value
from the 'default-intensity' property directly without scaling it could
lead to unexpected dimness or brightness. Should we look into whether we
need to normalise this value against 'max_brightness' to maintain
consistency?
</gemini>
Hope it helps.
> >
> > > --
> > >
> > > --- Patch [1]: [PATCH V4] leds: rgb: leds-group-multicolor: Implement default-intensity ---
> > > commit 13399f1aaceaf09afa7e252e35000d7d61ab1925
> > > Author: Stefan Wahren <wahrenst@gmx.net>
> > >
> > > leds: rgb: leds-group-multicolor: Implement default-intensity
> > >
> > > This commit introduces support for the default-intensity property during
> > > boot for LED multicolor groups. If the property is missing, the code falls
> > > back to the previous behavior of configuring the sub-LED intensity to its
> > > maximum.
> > >
> > > > diff --git a/drivers/leds/rgb/leds-group-multicolor.c b/drivers/leds/rgb/leds-group-multicolor.c
> > > > --- a/drivers/leds/rgb/leds-group-multicolor.c
> > > > +++ b/drivers/leds/rgb/leds-group-multicolor.c
> > > > @@ -108,8 +108,10 @@ static int leds_gmc_probe(struct platform_device *pdev)
> > > > subled[i].color_index = led_cdev->color;
> > > > - /* Configure the LED intensity to its maximum */
> > > > - subled[i].intensity = max_brightness;
> > > > + ret = device_property_read_u32(led_cdev->dev, "default-intensity",
>
> Should we verify if 'led_cdev->dev' is the correct device to query here?
> Normally, 'led_cdev->dev' is the class device and might not have the fwnode
> associated directly in the same way as the underlying platform or fwnode
> device. Would using 'led_cdev->dev->parent' or querying the fwnode directly
> be safer?
>
> > > > + &subled[i].intensity);
> > > > + if (ret || subled[i].intensity > max_brightness)
> > > > + subled[i].intensity = max_brightness;
> > > [Severity: Medium]
> > > Does this logic properly scale the intensity when the individual LEDs in the
> > > group have different maximum brightness values?
> > >
> > > If a multicolor group consists of LEDs with vastly different maximum brightness
> > > capabilities (like a GPIO LED maxing at 1 and a PWM LED maxing at 255), the
> > > overall group max_brightness will evaluate to 255.
> > >
> > > When reading the default-intensity from the device tree, the value is typically
> > > specified on the scale of the individual sub-LED's max brightness. If this
> > > value is assigned directly to subled[i].intensity without being scaled up to
> > > the group's max_brightness, the sub-LED might be initialized with only a tiny
> > > fraction of its intended intensity, often resulting in the LED being completely
> > > unlit instead of at the requested intensity.
> > >
> > > > }
> > > > /* Initialise the multicolor's LED class device */
> > > --
> > > Sashiko AI review · https://sashiko.dev/#/patchset/20260813091428.9072-1-wahrenst@gmx.net?part=1
>
>
--
Lee Jones
next prev parent reply other threads:[~2026-08-27 17:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 9:14 [PATCH V4] leds: rgb: leds-group-multicolor: Implement default-intensity Stefan Wahren
2026-08-13 9:25 ` sashiko-bot
2026-08-13 9:53 ` Lee Jones
2026-08-13 10:50 ` Stefan Wahren
2026-08-27 16:56 ` Lee Jones
2026-08-27 17:03 ` Lee Jones [this message]
2026-08-27 16:55 ` 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=20260827170301.GI2943942@google.com \
--to=lee@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jre@pengutronix.de \
--cc=linux-leds@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wahrenst@gmx.net \
/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.