From nobody Mon Feb 9 21:19:13 2026 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FDF33043DC for ; Tue, 30 Dec 2025 08:24:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767083054; cv=none; b=FivqCU1MXZ/Q5iU8ZmEqNLVLANcESYcB80SZ8+fB8yDsqS99qVE1/Hj0V9voVnDKtZsjTog3taCbKqi09oCbL5fLw7sBCDV7oqajUgFDuStrjCM8VloDXAYNhcu5/14VPwzq6gjybnxC5FfMtwL6Pz7XdKqabGjc0+c9vrc4AUw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767083054; c=relaxed/simple; bh=3pKuk8Mybw7TMm30Bo1zRUy6KDj71/Yw137ZvGyBXWY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ardBedoI8MDYGBeJbJ782GJJQaxg/crD8fXo39hWLhJb9xUCYdEYwc28CFSI6Jy/8aatzwwBEgp3xmo5WDMh+pdbC0HkxuxVgeDAPXUscn/LqkNNahArAXwAuzhctkfWpv+QiPl25kyv23UxvO4Kfslw+cnmg0BaFyEpeb/XtFI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jPZMf0j2; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jPZMf0j2" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2a0f3f74587so139093965ad.2 for ; Tue, 30 Dec 2025 00:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767083049; x=1767687849; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uxzCj7dEoeq0UKcYAHPRIErcvANPW2xJASyrOfZf5e8=; b=jPZMf0j2Gfj/TaBVfSUYJWv0BsCforBb3F83g2iygKCEuU8BchHwWtwpkEAqSKTOwt jVXk6+1SN17uMccbL3PC2jPR49L4WjlqM7jLa0rlCpKsWchQWZx5HVpSHVn9QZ6ejXB4 fUF2hbAAlj5RnC/tKABBxpuAcH9ic0y+guwSe3TijKbufejMennKQEMOFaXWmoGqp/j3 pPdnCy1UjOk0dNykw/Xu2Gy9YwI735dyeYGwJwH13U4GLtujjrJkGzHV8GIKdp1K1r8t wUptEsnaoNPYHV7UTw36Bockdgbw/HVoWng0JKCNz91T08XpGQr48wnXV8RH/I1aCXDt j1cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767083049; x=1767687849; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uxzCj7dEoeq0UKcYAHPRIErcvANPW2xJASyrOfZf5e8=; b=cpTYovTdV6BBsqwo6XjFWQ4nejmPTGTe/hmT6ZmQe4YTJCv9HD3iS0RJLE/bUT8GYS dQh5lEIdEb7+3AodlYjH+OKe4Xalg2q67y5gFhkhNK17WVAWc9fXD0YXSYOFF2C/o1hi 2gRUpUCj+s3/NkbpZ/TeMseEoHBlmFW9D0GIxcs6Zy2bF5jD+lfSg2cFUQgaLMz7DT1Z VPuwK6fqnrg2YNFyZ9+dKS3nVZlsMYTOUZqOa8okarXGLuUSX+tTRWfw64HGALU8egjD JiNpO8SkNjiyx7Ca9DxsvQ2BYhTqPNjJS2eq+994CEze2oGbWmQAn2vn3dkut6y991SX EFGg== X-Forwarded-Encrypted: i=1; AJvYcCXMz09XDFEP5J0IpBebeUR1z6w1OTF0vjrUQqOn1V6RhPqR98enrOCYIKp+4NDIF3WYObyIau4jlHMqU4U=@vger.kernel.org X-Gm-Message-State: AOJu0Yy2jkPBhtInUalnvO6h9ueLjZO+NthiCdLrawCA6NCytutB20/x QGMcd99+0K1prJNWQMPXk2Eq3MJM9lloTnssIZAHEOOT8u+e7GhtW/u3sL6Hzg== X-Gm-Gg: AY/fxX49D5AVryMmbEFO1+Q3FuO9oQw1/IiE6Sz2LRlmpYcAqjfYJ4ZGtX4tHMoOkSN Ea9TKb3wimOhNXYraWm+TrxE6dbf/qlKIvV1SXK5vdOONbWwk6a7T09r68T7kUkxGkPx267/KRp ySi73z0kCsgHghfPVCCcCaR4MwUadvkyoakH4YJd6cWeDSN4A9ZE3qEtV+tn0x5AZkjj+tO0JoU HVpOjX7wnjoqrN9QbqBa90kuub+JVOT9mSMkP/Cq42/Je9CuNUgqVXeN60vvLNdAaF4iGvwKJ7U B8Qet1bSzXhbeZoih7wamD/1JWPdnv7RPel1zcXhvkQedVAq63ZBSOoXYDa9IE98J4tCUtsM2xq n77kH8bcn89fKSZWfOC7kI+8KWfgEpSASgQ8CnkZQCh2EvW8+95xuACml85y6UMetZ9nLztKTQr CM5oUu2oCvoTI2txujV3wCkM5ehGHvySwq X-Google-Smtp-Source: AGHT+IHq0ZWVPdAhexpY/oKmiMsAeM9ej2P2taNKWdIK1MV2wjUeNhgWpuVPof8pXBllb7D7/T7pXA== X-Received: by 2002:a17:903:2442:b0:2a0:97d2:a265 with SMTP id d9443c01a7336-2a2f2231aafmr339509855ad.14.1767083049129; Tue, 30 Dec 2025 00:24:09 -0800 (PST) Received: from MRSPARKLE.localdomain ([150.228.155.85]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a2f3d76ceesm296667165ad.91.2025.12.30.00.24.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Dec 2025 00:24:08 -0800 (PST) From: Jonathan Brophy To: lee Jones , Pavel Machek , Andriy Shevencho , Jonathan Brophy , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Radoslav Tsvetkov Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org Subject: [PATCH v5 3/7] dt-bindings: leds: Add virtual LED group controller bindings Date: Tue, 30 Dec 2025 21:23:16 +1300 Message-ID: <20251230082336.3308403-4-professorjonny98@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251230082336.3308403-1-professorjonny98@gmail.com> References: <20251230082336.3308403-1-professorjonny98@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jonathan Brophy Add device tree bindings for the virtual LED group controller that provides priority-based arbitration for shared physical LEDs across multiple virtual LED instances. Bindings for the virtual driver are not describing hardware LEDs they describe virtual devices made from groups of hardware LEDs created from an = array of LED phandles. Normally the device tree is used to describe hardware not virtual hardware but it is particularly useful in situations where you require an LED to be a specific color by mixing primary colors, such as multi element multi color = LEDs to be operated from a device tree binding or a single trigger. It also becomes useful with multiple LEDs operating the same indicator such= as ring of light indicators, led rope where the LEDs are driven From different= GPIO outputs unifying the control that can give basic indication during system s= tartup, shutdown upgrade etc... The controller implements winner-takes-all arbitration where only the highest-priority active virtual LED controls the hardware at any given time. This enables multiple subsystems (boot, error, status indicators) to request LED control without explicit coordination. Binding supports: - Multiple virtual LED children with independent priorities - GPIO, PWM, I2C, and SPI physical LED devices - Multicolor and standard (fixed-color) operating modes - Global ownership tracking to prevent conflicts Example configurations include: - High-priority emergency/error RGB indicator - Medium-priority system state RGBW indicator - Low-priority warm white fixed-color indicator Co-developed-by: Radoslav Tsvetkov Signed-off-by: Radoslav Tsvetkov Signed-off-by: Jonathan Brophy --- .../leds/leds-group-virtualcolor.yaml | 170 ++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-group-virtu= alcolor.yaml diff --git a/Documentation/devicetree/bindings/leds/leds-group-virtualcolor= .yaml b/Documentation/devicetree/bindings/leds/leds-group-virtualcolor.yaml new file mode 100644 index 000000000000..88c044f42879 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-group-virtualcolor.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-group-virtualcolor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Virtual LED Group Controller with Multicolor Support + +maintainers: + - Jonathan Brophy + +description: | + The virtual LED group controller provides priority-based arbitration for + shared physical LEDs across multiple virtual LED instances. Each virtual= LED + combines physical monochromatic LEDs into logical units with: + + - Priority-based arbitration: Higher priority virtual LEDs take preceden= ce + when multiple virtual LEDs compete for the same physical LEDs + - Sequence-based tie-breaking: Among equal priorities, most recent updat= e wins + - Winner-takes-all: Only ONE virtual LED controls ALL physical LEDs at a= ny time + - Color channel grouping: Organize LEDs by color for multicolor control + - Full multicolor ABI support: multi_intensity, multi_index, multi_multi= pliers + - Two operating modes: + * Multicolor mode: Dynamic per-channel intensity control (default) + * Standard mode: Fixed color ratios via multipliers (brightness only) + - Brightness scaling: Master brightness control with per-channel intensi= ty + - Global ownership: Physical LEDs claimed exclusively per controller ins= tance + - Update batching: Optional coalescing of rapid brightness changes + + Key features: + - Supports GPIO, PWM, I2C, and SPI LED devices + - Automatic physical LED discovery and claiming + - Lock-free arbitration with atomic sequence numbers + - Suspend/resume with state preservation + - Comprehensive debugfs telemetry (when CONFIG_DEBUG_FS enabled) + + Typical use cases: + - System status indicators with boot/update/error priority levels + - RGB lighting with priority-based overrides + - Multi-element LED arrays unified into single logical controls + - LED rings or strips with coordinated color control + +properties: + compatible: + const: leds-group-virtualcolor + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^virtual-led@[0-9a-f]+$": + type: object + $ref: leds-class-virtualcolor.yaml# + +required: + - compatible + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include + #include + + /* Physical LED definitions */ + led-controller { + compatible =3D "gpio-leds"; + + led_red: led-red { + color =3D ; + function =3D LED_FUNCTION_STATUS; + gpios =3D <&gpio0 10 GPIO_ACTIVE_HIGH>; + default-state =3D "off"; + }; + + led_green: led-green { + color =3D ; + function =3D LED_FUNCTION_STATUS; + gpios =3D <&gpio0 11 GPIO_ACTIVE_HIGH>; + default-state =3D "off"; + }; + + led_blue: led-blue { + color =3D ; + function =3D LED_FUNCTION_STATUS; + gpios =3D <&gpio0 12 GPIO_ACTIVE_HIGH>; + default-state =3D "off"; + }; + + led_white: led-white { + color =3D ; + function =3D LED_FUNCTION_STATUS; + gpios =3D <&gpio0 13 GPIO_ACTIVE_HIGH>; + default-state =3D "off"; + }; + }; + + pwm-led-controller { + compatible =3D "pwm-leds"; + + pwm_red: led-1 { + color =3D ; + function =3D LED_FUNCTION_STATUS; + pwms =3D <&pwm 0 7812500>; + max-brightness =3D <255>; + }; + + pwm_green: led-2 { + color =3D ; + function =3D LED_FUNCTION_STATUS; + pwms =3D <&pwm 1 7812500>; + max-brightness =3D <255>; + }; + + pwm_blue: led-3 { + color =3D ; + function =3D LED_FUNCTION_STATUS; + pwms =3D <&pwm 2 7812500>; + max-brightness =3D <255>; + }; + }; + + /* virtual LED definitions */ + virtual-led-controller { + compatible =3D "leds-group-virtualcolor"; + #address-cells =3D <1>; + #size-cells =3D <0>; + + /* High-priority RGB virtual LED (emergency/error indicator) */ + virtual-led@0 { + reg =3D <0>; + color =3D ; + function =3D LED_FUNCTION_STATUS; + priority =3D <1000>; + led-mode =3D "multicolor"; + leds =3D <&led_red>, <&led_green>, <&led_blue>; + /* Channels ordered by color ID: [0]=3Dred, [1]=3Dgreen, [2]= =3Dblue */ + }; + + /* Medium-priority RGBW indicator (system state) */ + virtual-led@1 { + reg =3D <1>; + color =3D ; + function =3D LED_FUNCTION_STATUS; + priority =3D <500>; + led-mode =3D "multicolor"; + leds =3D <&pwm_red>, <&pwm_green>, <&pwm_blue>, <&led_white>; + /* Channels: [0]=3Dwhite (ID=3D0), [1]=3Dred, [2]=3Dgreen, [3]= =3Dblue */ + }; + + /* Low-priority warm white (fixed color ratios, standard mode) */ + virtual-led@2 { + reg =3D <2>; + color =3D ; + function =3D LED_FUNCTION_STATUS; + priority =3D <10>; + led-mode =3D "standard"; + leds =3D <&led_red>, <&led_green>, <&led_blue>; + /* Channels: [0]=3Dred, [1]=3Dgreen, [2]=3Dblue */ + mc-channel-multipliers =3D <255 180 100>; + /* Creates warm white: full red, 70% green, 40% blue */ + }; + }; + +... -- 2.43.0