| 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
| ||
|
Message-Id: <20250331153138.52539-1-trannamatk@gmail.com>
Date: Mon, 31 Mar 2025 22:31:38 +0700
From: Nam Tran <trannamatk@...il.com>
To: krzk+dt@...nel.org
Cc: pavel@...nel.org,
lee@...nel.org,
robh@...nel.org,
conor+dt@...nel.org,
devicetree@...r.kernel.org,
linux-leds@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: leds: Add LP5812 LED driver
On 18 Mar 2025 19:59:51, Krzysztof Kozlowski wrote:
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/leds/ti,lp5812.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +$ref: /schemas/leds/common.yaml#
>>> +
>>> +title: Linux driver for LP5812 LED from Texas Instruments
>>
>> Nothing improved.
>>
>> Nam: Do you mean the title should focus on the LP5812 hardware itself? If so, I will update it accordingly to better describe the device.
>
>No, I mean you should say what this device is, not what the driver is
>for. Bindings are about hardware, not drivers.
Thank you for the clarification.
I will change the title to “TI/National Semiconductor LP5812 LED Drivers”.
>>
>>> +
>>> +maintainers:
>>> + - Nam Tran <trannamatk@...il.com>
>>> +
>>> +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
>>
>>
>> This improved... but:
>>
>>> +
>>> + "#address-cells":
>>> + const: 1
>>> +
>>> + "#size-cells":
>>> + const: 0
>>
>> What are these?
>>
>> Nam: I included the #address-cells and #size-cells properties to resolve a warning encountered when running:
>> make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/leds/ti,lp5812.yaml
>> The specific warning was:
>> Documentation/devicetree/bindings/leds/ti,lp5812.example.dts:23.17-30: Warning (reg_format): /example-0/i2c/led-controller@1b:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
>
>This makes no sense.
>
>> This warning suggests that the default values for #address-cells and #size-cells in the schema context are not aligned with the LP5812's expected usage. To explicitly define the correct values, I set these properties as mentioned.
>> This ensures that the binding schema validation passes without warnings. If you believe a different approach is more appropriate, I’m happy to adjust the binding accordingly.
>
>I can barely parse your messages. They are neither properly quoting my
>replies, nor wrapped according to email style. Use standard format,
>expressed in countless guides bout netiquette and mailing lists.
>
>You added properties to hide warning, instead of fixing the warning, but
>these properties make nos sense here.
#address-cells is 1 because I only one cell to define address of a child node of LP5812
#size-cells is 0 because I don't need to define size of reg properly of child node.
Reg properly of child node is describe for address only.
>>
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> +
>>
>> Nothing improved here.
>> Your previous comment
>> No ref to LED common schema? No other properties? This is too incomplete
>>
>> Nam: I have chosen not to reference common.yaml in the LP5812 binding because the LP5812 does not fully align with the standard LED properties defined in the common schema. Since the driver does
>
>That's a no go.
>
>> not use standard properties like function, color, or max-brightness, I believe referencing the common schema would introduce unnecessary constraints.
>
>Driver? Please describe hardware, not driver.
>
>> Currently, I have included compatible and reg as required properties, as they are essential for describing the LP5812 device. Are there additional properties that should be marked as required? Or if you have specific improvements in mind, I would appreciate your guidance.
>
>Look at other bindings and do not re-invent.
I checked other bindings and I will update LP5812 yaml follow multi color led and describe LP5812 hardware in the yaml.
My new yaml will update as below
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/ti,lp5812.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
$ref: /schemas/leds/common.yaml#
title: TI/National Semiconductor LP5812 LED Drivers
maintainers:
- Nam Tran <trannamatk@...il.com>
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
description:
I2C slave address
lp5812/12- 0x1b
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
'^multi-led@[0-3]$':
type: object
$ref: leds-class-multicolor.yaml#
unevaluatedProperties: false
properties:
reg:
minItems: 1
maxItems: 12
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^led@[0-9a-f]+$":
type: object
$ref: common.yaml#
unevaluatedProperties: false
properties:
reg:
maxItems: 1
required:
- reg
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/leds/common.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
led-controller@1b {
compatible = "ti,lp5812";
reg = <0x1b>;
#address-cells = <1>;
#size-cells = <0>;
multi-led@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0>;
color = <LED_COLOR_ID_RGB>;
led@0 {
reg = <0x0>;
color = <LED_COLOR_ID_GREEN>;
};
led@1 {
reg = <0x1>;
color = <LED_COLOR_ID_RED>;
};
led@2 {
reg = <0x2>;
color = <LED_COLOR_ID_BLUE>;
};
};
multi-led@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x1>;
color = <LED_COLOR_ID_RGB>;
led@3 {
reg = <0x3>;
color = <LED_COLOR_ID_GREEN>;
};
led@4 {
reg = <0x4>;
color = <LED_COLOR_ID_RED>;
};
led@5 {
reg = <0x5>;
color = <LED_COLOR_ID_BLUE>;
};
};
multi-led@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x2>;
color = <LED_COLOR_ID_RGB>;
led@6 {
reg = <0x6>;
color = <LED_COLOR_ID_GREEN>;
};
led@7 {
reg = <0x7>;
color = <LED_COLOR_ID_RED>;
};
led@8 {
reg = <0x8>;
color = <LED_COLOR_ID_BLUE>;
};
};
multi-led@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x3>;
color = <LED_COLOR_ID_RGB>;
led@9 {
reg = <0x9>;
color = <LED_COLOR_ID_GREEN>;
};
led@a {
reg = <0xA>;
color = <LED_COLOR_ID_RED>;
};
led@b {
reg = <0xB>;
color = <LED_COLOR_ID_BLUE>;
};
};
};
};
...
>>
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + i2c {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + led-controller@1b {
>>> + compatible = "ti,lp5812";
>>> + reg = <0x1b>;
>>> + };
>>> + };
>>> +
>>> +...
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 8e0736dc2ee0..2bd9f5132cab 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -23506,6 +23506,12 @@ S: Maintained
>>> F: Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml
>>> F: drivers/leds/leds-lp8864.c
>>>
>>> +TEXAS INSTRUMENTS' LP5812 LED DRIVER
>>
>> Nothing improved.
>> Your previous comment
>> 5 is before 8, so this does not look sorted.
>>
>> Nam: I have reviewed the sorting order in MAINTAINERS, and I believe the current placement of LP5812 is correct. Since "LB" comes before "LP" alphabetically, "TEXAS INSTRUMENTS' LB8864 LED DRIVER" is correctly listed before "TEXAS INSTRUMENTS' LP5812 LED BACKLIGHT DRIVER".
>
>
>Indeed, existing entry has typo, so code is fine. Is it such a big deal
>to answer to reviewer to his comment?
Thank you for the clarification. I now understand that the existing entry contains a typo.
I will make sure to response to reviewer comments more promtly in the future.
Is it acceptable if I modify MAINTAINERS file to adjust LB8864 to LP8864?
Best regards,
Nam Tran
Powered by blists - more mailing lists