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] [day] [month] [year] [list]

Message-ID:
 <PH0PR03MB6525EA380BFDCB228C2A30C3ED85A@PH0PR03MB6525.namprd03.prod.outlook.com>
Date: Thu, 8 Jan 2026 06:02:53 +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 1/2] dt-bindings: leds: Document LTC3220 18 channel LED
 Driver

> >>> +  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?

After rechecking the datasheet I think, it should be dropped. 
It should be automatic so it can change the strength of the charge pump
to match the required current.

> >
> >>
> >>> +    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.
> 
I will add in the description that this should only be used when LED 1 is present

Thank You!

Best Regards,
Edelweise Escala