linux-kernel - Re: [PATCH v5 1/5] dt-bindings: leds: add TI/National Semiconductor LP5812 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: <2badc360-9bfa-400a-acca-ab82f8cc5a95@kernel.org>
Date: Mon, 14 Apr 2025 17:10:16 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Nam Tran <trannamatk@...il.com>, pavel@...nel.org, lee@...nel.org,
 krzk+dt@...nel.org, robh@...nel.org, conor+dt@...nel.org, corbet@....net
Cc: devicetree@...r.kernel.org, linux-leds@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/5] dt-bindings: leds: add TI/National Semiconductor
 LP5812 LED Driver

On 14/04/2025 16:57, Nam Tran wrote:
> +
> +description: |
> +  The LP5812 is an I2C LED Driver that can support LED matrix 4x3.
> +  For more product information please see the link below:
> +  https://www.ti.com/product/LP5812#tech-docs
> +
> +properties:
> +  compatible:
> +    const: ti,lp5812
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0

No need for supply?

> +
> +patternProperties:
> +  "^led@[0-9a-b]$":
> +    type: object
> +    $ref: common.yaml#
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        minimum: 0
> +        maximum: 0xb
> +
> +      chan-name:
> +        $ref: /schemas/types.yaml#/definitions/string
> +        description: LED channel name

My comment stay valid. I don't think LEDs have channels, datasheet also
has nothing about channels, so again - use existing properties. Or
better drop it - I don't see any point in the name. The reg already
defines it.

However after dropping this, your example has nodes with only reg -
what's the point of them? Why no properties from common.yaml are
applicable? If they are not applicable, then the entire subnode should
be dropped - you don't need them to describe the hardware.

Best regards,
Krzysztof