linux-kernel - Re: [PATCH v3 2/4] dt-bindings: auxdisplay: add Titan Micro Electronics TM16xx

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: <68ff2e14-19db-4d4c-8390-8fd2ec9e2c48@kernel.org>
Date: Fri, 22 Aug 2025 08:44:26 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jean-François Lessard <jefflessard3@...il.com>
Cc: Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>,
 devicetree@...r.kernel.org, linux-leds@...r.kernel.org,
 linux-kernel@...r.kernel.org, Andreas Färber
 <afaerber@...e.de>, Boris Gjenero <boris.gjenero@...il.com>,
 Christian Hewitt <christianshewitt@...il.com>,
 Heiner Kallweit <hkallweit1@...il.com>,
 Paolo Sabatino <paolo.sabatino@...il.com>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Subject: Re: [PATCH v3 2/4] dt-bindings: auxdisplay: add Titan Micro
 Electronics TM16xx

On 21/08/2025 17:16, Jean-François Lessard wrote:
>>
>>> +      # Controllers with titanmec,tm1650 fallback
>>> +      - items:
>>> +          - enum:
>>> +              - fdhisi,fd650
>>> +              - wxicore,aip650
>>> +          - const: titanmec,tm1650
>>> +      - const: titanmec,tm1650
>>> +      # Canonical standalone controllers
>>
>> Drop
>>
>>> +      - const: fdhisi,fd620
>>> +      - const: fdhisi,fd655
>>> +      - const: fdhisi,fd6551
>>> +      - const: titanmec,tm1620
>>> +      - const: titanmec,tm1638
>>> +      - const: winrise,hbs658
>>
>> This is one enum
>>
> 
> Well received. I followed the older style and will adopt the modern approach:
> 
> properties:
>   compatible:
>     items:
>       - enum:
>           - fdhisi,fd628
>           - princeton,pt6964
>           - wxicore,aip1628
>           - wxicore,aip1618
>           - fdhisi,fd650
>           - wxicore,aip650
>           - fdhisi,fd620
>           - fdhisi,fd655
>           - fdhisi,fd6551
>           - titanmec,tm1620
>           - titanmec,tm1638
>           - winrise,hbs658
>       - enum:
>           - titanmec,tm1628
>           - titanmec,tm1618
>           - titanmec,tm1650
>     minItems: 1
>     maxItems: 2
> 
> Fallback relationships will be documented explicitly in the binding’s description.

Sorry, but what? I commented under specific lines. Why are you changing
other things?


> 
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  label:
>>> +    description: Name of the entire device
>>> +    default: display
>>
>> Huh? Why do you need label? Are you sure auxdisplays have labels?
>>
>>
> 
> Display integrates with the LED subsystem (/sys/class/leds), where label is
> a standard property per leds/common.yaml. It ensures predictable LED class
> device naming when multiple display instances are present, following established
> LED subsystem conventions rather than general DT naming rules.

You want to say that top level node is like LED? Then probably it misses
common.yaml reference. Although I am still puzzled... you have sub nodes
for actual LEDs, no?

> 
> If helpful, I can add a $ref to /schemas/leds/common.yaml#/properties/label
> or include its description explicitly.
> 


Best regards,
Krzysztof