linux-kernel - Re: [PATCH 1/2] dt-bindings: leds: Document 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2d1893a8-81eb-4d7e-81df-060722c10c7d@kernel.org>
Date: Wed, 7 Jan 2026 11:57:39 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: "Escala, Edelweise" <Edelweise.Escala@...log.com>
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 1/2] dt-bindings: leds: Document LTC3220 18 channel LED
 Driver

On 07/01/2026 10:52, Escala, Edelweise wrote:
>>
>>> +
>>> +  adi,force-cpo-level:
>>> +    $ref: /schemas/types.yaml#/definitions/string
>>> +    description: Forces the Charge Pump Output to a specified multiplier.
>>> +    enum:
>>> +      - "0" # Auto(default) - Automatically selects optimal charge pump mode
>>> +      - "1.5"
>>> +      - "2"
>>> +      - "1"
>>
>> Numbers are not a string, so choose appropriate number format. Also, oddly
>> sorted. I don't understand what this property is for so not sure what to
>> recommend.
> 
> It is arranged this way to match the value for the register.

Makes no sense. The order here does not matter for driver and registers
at all.

> I plan to keep it as string and just do 
> enum:
> - auto
> - 1.5x
> - 2x
> - 1x

Still wrongly ordered and still I do not understand the purpose of this
property.

Datasheet mentions some sort of impedance. Impedance has units (see
property units in dtschema), but you call it "level". Maybe you want to
achieve some specific current on output? But for current we already have
LED related properties.

Also, "auto" is redundant unless lack of the property has a meaning?

Why exactly this varies between boards?

> 
>>
>>> +    default: "0"
>>> +
>>> +  adi,quick-write:
>>> +    type: boolean
>>> +    description: If present, LED 1 output becomes a master control that
>>> +      simultaneously updates all 18 LED outputs using the hardware's quick-
>> write
>>> +      mode. When enabled, led@1 must be defined in the device tree to
>> provide
>>> +      the control interface, even if no physical LED is connected to the D1
>>> +      output pin. When disabled or not present, LED 1 operates as a normal
>>> +      independent LED output.
>>
>> If there is no led@1 physically, you cannot add it to the DT. It seems you
>> described some sort of driver behavior, instead of hardware.
>>
> 
> This is also a hardware feature, when enabled a write to the LED 1
> output register simultaneously updates all 18 LED output registers
> to the same value.

You still cannot add fake nodes to DT. Fake means there is no actual LED.

Best regards,
Krzysztof