linux-kernel - RE: [PATCH v2 1/2] dt-bindings: leds: Add LTC3220 18 channel LED Driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <PH0PR03MB6525EF9CDFACF871EF350119ED8FA@PH0PR03MB6525.namprd03.prod.outlook.com>
Date: Wed, 14 Jan 2026 00:16:16 +0000
From: "Escala, Edelweise" <Edelweise.Escala@...log.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>,
        Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        "linux-leds@...r.kernel.org"
	<linux-leds@...r.kernel.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 1/2] dt-bindings: leds: Add LTC3220 18 channel LED
 Driver

> On Mon, Jan 12, 2026 at 04:55:54PM +0800, Edelweise Escala wrote:
> > Document device tree bindings for the LTC3220 18-channel LED driver
> > with I2C interface, individual brightness control, and
> > hardware-assisted blink/gradation features.
> >
> > Signed-off-by: Edelweise Escala <edelweise.escala@...log.com>
> > ---
> 
> No changelog in the cover letter, no changelog here.

Apologies for my mistake in the changelog in the cover letter. For this file this should have been the changelog.
V2 Changelog:
leds-ltc3220.yaml changes
-Fix wrapping on description
-Improve description and commit messge to describe hardware
-Drop ltc3220-1
-Drop adi,force-cpo-level property

> >  .../devicetree/bindings/leds/leds-ltc3220.yaml     | 120
> +++++++++++++++++++++
> >  MAINTAINERS                                        |   7 ++
> >  2 files changed, 127 insertions(+)
> >
> 
> > +  adi,quick-write:
> > +    type: boolean
> > +    description:
> > +      Enables the hardware quick-write feature where a write to the LED 1
> > +      output register simultaneously updates all 18 LED output registers
> > +      to the same value. Only applicable when LED 1 output is physically
> > +      present and defined in the device tree.
> 
> I have doubts that this works fine. If you define 18 different LED nodes, each
> can be controlled by user-space or kernel independently, but with this
> property updates to LED 1 would overwrite updates to other LEDs.
> 
> Isn't this then an aggregated LED, so in such case only one LED can be defined
> in DT (optionally with 18 led-sources)?

Thank you for your feedback. Yes, with quick-write enabled, writing to LED 1 will overwrite the values of all other LEDs. To address this, the driver updates the cached brightness values for all LEDs whenever LED 1 is written, so that reading the brightness from any LED will always return the correct (overwritten) value. Having the property allows LED2-17 to still be used independently, while LED1 acts as a control for all LEDs.

Based on your comments, it would be better to drop the quick-write property from the device tree and binding:
-For the aggregated LED use case, the driver will automatically enable quick-write internally to efficiently update all outputs together.
-For the independent LED use case, if users want to change all LED values simultaneously, they can simply loop through each LED and set the desired value. In this scenario, the hardware quick-write feature is not used and becomes unnecessary.

Would it be useful to provide a runtime configuration (e.g., via sysfs) to allow switching between independent and quick-write modes? Please let me know your thoughts or if you have a preferred approach.

> > +
> > +patternProperties:
> > +  '^led@([1-9]|1[0-8])$':
> > +    type: object
> > +    $ref: /schemas/leds/common.yaml#
> > +    unevaluatedProperties: false
> > +    properties:
> > +      reg:
> > +        description: Output channel for the LED (1-18 maps to LED outputs
> D1-D18).
> > +        minimum: 1
> > +        maximum: 18

Best Regards,
Edelweise Escala