From: Rob Herring <robh@kernel.org>
To: Jonathan Brophy <professorjonny98@gmail.com>
Cc: lee Jones <lee@kernel.org>, Pavel Machek <pavel@kernel.org>,
Andriy Shevencho <andriy.shevchenko@linux.intel.com>,
Jonathan Brophy <professor_jonny@hotmail.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Radoslav Tsvetkov <rtsvetkov@gradotech.eu>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org
Subject: Re: [PATCH v5 0/7] leds: Add virtual LED group driver with priority arbitration
Date: Tue, 6 Jan 2026 10:59:47 -0600 [thread overview]
Message-ID: <20260106165947.GA2233601-robh@kernel.org> (raw)
In-Reply-To: <20251230082336.3308403-1-professorjonny98@gmail.com>
On Tue, Dec 30, 2025 at 09:23:13PM +1300, Jonathan Brophy wrote:
> From: Jonathan Brophy <professor_jonny@hotmail.com>
>
> This patch series introduces a new LED driver that implements virtual LED
> groups with priority-based arbitration for shared physical LEDs. The driver
> provides a multicolor LED interface while solving the problem of multiple
> subsystems needing to control the same physical LEDs.
>
> Key features:
> - Winner-takes-all priority-based arbitration
> - Full multicolor LED ABI compliance
> - Two operating modes (multicolor and standard/fixed-color)
> - Deterministic channel ordering by LED_COLOR_ID
> - Comprehensive debugfs telemetry (when CONFIG_DEBUG_FS enabled)
> - Optimized memory footprint (~200 bytes per LED in production builds)
>
> Use cases:
> - System status indicators with boot/error/update priority levels
> - RGB lighting with coordinated control
> - Multi-element LED arrays unified into single logical controls
I still don't really understand what you are trying to do. You need to
tell a story not just some bullet lists. What is it you want to do that
you can't currently support. I would start from the top level. What do
you need to be able to do from userspace. Describe what you need to do
not in terms of "here's how I solved/implemented it" but what does the
current interface lack. IOW, define the problem in a way we can provide
alternate solutions.
I see "virtual" and that screams "doesn't belong in DT" to me. I assume
there is some physical property of why certain LEDs are grouped
together. Convince me that the board designer would define
the grouping rather than the user running Linux. Multi-color LEDs are
physically packaged together for example, so defining in DT makes sense.
If you can split this up into smaller series/features, that would help
with your upstreaming. Otherwise, it looks like a huge pile to
try to understand and we'll likely just move on to other series which
are easier to review.
Rob
next prev parent reply other threads:[~2026-01-06 16:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 8:23 [PATCH v5 0/7] leds: Add virtual LED group driver with priority arbitration Jonathan Brophy
2025-12-30 8:23 ` [PATCH v5 1/7] dt-bindings: leds: add function virtual_status to led common properties Jonathan Brophy
2025-12-30 8:23 ` [PATCH v5 2/7] dt-bindings: leds: Add virtual LED class bindings Jonathan Brophy
2025-12-30 8:23 ` [PATCH v5 3/7] dt-bindings: leds: Add virtual LED group controller bindings Jonathan Brophy
2025-12-30 8:23 ` [PATCH v5 4/7] ABI: Add sysfs documentation for leds-group-virtualcolor Jonathan Brophy
2025-12-30 11:52 ` Andriy Shevencho
2025-12-30 8:23 ` [PATCH v5 5/7] leds: Add driver " Jonathan Brophy
2025-12-30 8:23 ` [PATCH v5 6/7] leds: Add fwnode_led_get() for firmware-agnostic LED resolution Jonathan Brophy
2025-12-30 12:00 ` Andriy Shevencho
2025-12-31 2:30 ` kernel test robot
2025-12-31 23:37 ` kernel test robot
2025-12-31 23:45 ` kernel test robot
2026-01-02 12:20 ` kernel test robot
2026-01-02 15:07 ` kernel test robot
2026-01-02 16:29 ` kernel test robot
2025-12-30 8:23 ` [PATCH v5 7/7] leds: Add virtual LED group driver with priority arbitration Jonathan Brophy
2025-12-30 12:19 ` Andriy Shevencho
2026-01-03 8:22 ` [PATCH v5 7/7] leds: Add virtual LED group driver Jonathan Brophy
2026-01-03 12:56 ` Andriy Shevencho
2026-01-06 16:59 ` Rob Herring [this message]
2026-01-13 11:52 ` [PATCH v5 0/7] leds: Add virtual LED group driver with priority arbitration Lee Jones
2026-01-13 11:57 ` Lee Jones
2026-01-13 20:35 ` Jonathan Brophy
2026-01-15 15:07 ` Lee Jones
2026-01-15 16:58 ` Andriy Shevencho
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=20260106165947.GA2233601-robh@kernel.org \
--to=robh@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=professor_jonny@hotmail.com \
--cc=professorjonny98@gmail.com \
--cc=rtsvetkov@gradotech.eu \
/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.