Add documentation for TM16xx-compatible 7-segment LED display controllers with
keyscan.

Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
---

Note: The 'segments' property is intentionally not vendor-prefixed as it defines
a generic hardware description concept applicable to any 7-segment display
controller. The property describes the fundamental grid/segment coordinate
mapping that is controller-agnostic and could be reused by other LED matrix
display bindings. Similar to how 'gpios' describes GPIO connections generically,
'segments' describes segment connections in a standardized way using
uint32-matrix format.

 .../bindings/auxdisplay/titanmec,tm16xx.yaml  | 471 ++++++++++++++++++
 1 file changed, 471 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml

diff --git a/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
new file mode 100644
index 000000000..b563c6e1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
@@ -0,0 +1,471 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm16xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Auxiliary displays based on TM16xx and compatible LED controllers
+
+maintainers:
+  - Jean-François Lessard <jefflessard3@gmail.com>
+
+description: |
+  LED matrix controllers used in auxiliary display devices that drive individual
+  LED icons and 7-segment digit groups through a grid/segment addressing scheme.
+  Controllers manage a matrix of LEDs organized as grids (columns/banks in
+  vendor datasheets) and segments (rows/bit positions in vendor datasheets).
+  Maximum grid and segment indices are controller-specific.
+
+  The controller is agnostic of the display layout. Board-specific LED wiring is
+  described through child nodes that specify grid/segment coordinates for
+  individual icons and segment mapping for 7-segment digits.
+
+  The bindings use separate 'leds' and 'digits' containers to accommodate
+  different addressing schemes:
+  - LEDs use 2-cell addressing (grid, segment) for matrix coordinates
+  - Digits use 1-cell addressing with explicit segment mapping
+
+  Optional keypad scanning is supported when both 'linux,keymap' and
+  'poll-interval' properties are specified.
+
+properties:
+  compatible:
+    oneOf:
+      # Controllers with titanmec,tm1628 fallback
+      - items:
+          - enum:
+              - fdhisi,fd628
+              - princeton,pt6964
+              - wxicore,aip1628
+          - const: titanmec,tm1628
+      - const: titanmec,tm1628
+      # Controllers with titanmec,tm1618 fallback
+      - items:
+          - enum:
+              - wxicore,aip1618
+          - const: titanmec,tm1618
+      - const: titanmec,tm1618
+      # Controllers with titanmec,tm1650 fallback
+      - items:
+          - enum:
+              - fdhisi,fd650
+              - wxicore,aip650
+          - const: titanmec,tm1650
+      - const: titanmec,tm1650
+      # Canonical standalone controllers
+      - const: fdhisi,fd620
+      - const: fdhisi,fd655
+      - const: fdhisi,fd6551
+      - const: titanmec,tm1620
+      - const: titanmec,tm1638
+      - const: winrise,hbs658
+
+  reg:
+    maxItems: 1
+
+  label:
+    description: Name of the entire device
+    default: display
+
+  default-brightness:
+    description:
+      Brightness to be set if LED's default state is on. Used only during
+      initialization. If the option is not set then max brightness is used.
+    $ref: /schemas/types.yaml#/definitions/uint32
+
+  max-brightness:
+    description:
+      Normally the maximum brightness is determined by the hardware and this
+      property is not required. This property is used to put a software limit
+      on the brightness apart from what the driver says, as it could happen
+      that a LED can be made so bright that it gets damaged or causes damage
+      due to restrictions in a specific system, such as mounting conditions.
+    $ref: /schemas/types.yaml#/definitions/uint32
+
+  linux,keymap:
+    $ref: /schemas/input/matrix-keymap.yaml#/properties/linux,keymap
+
+  poll-interval:
+    $ref: /schemas/input/input.yaml#/properties/poll-interval
+
+  autorepeat:
+    $ref: /schemas/input/input.yaml#/properties/autorepeat
+
+  digits:
+    type: object
+    description: Container for 7-segment digit group definitions
+    properties:
+      "#address-cells":
+        const: 1
+      "#size-cells":
+        const: 0
+
+    patternProperties:
+      "^digit@[0-9]+$":
+        type: object
+        properties:
+          reg:
+            description: Digit position identifier
+            maxItems: 1
+          segments:
+            $ref: /schemas/types.yaml#/definitions/uint32-matrix
+            description: |
+              Array of grid/segment coordinate pairs for each 7-segment position.
+              Each entry is <grid segment> mapping to standard 7-segment positions
+              in order: a, b, c, d, e, f, g
+
+              Standard 7-segment layout:
+                 aaa
+                f   b
+                f   b
+                 ggg
+                e   c
+                e   c
+                 ddd
+            items:
+              items:
+                - description: Grid index
+                - description: Segment index
+            minItems: 7
+            maxItems: 7
+        required:
+          - reg
+          - segments
+        unevaluatedProperties: false
+
+    additionalProperties: false
+
+  leds:
+    type: object
+    description: Container for individual LED icon definitions
+    properties:
+      "#address-cells":
+        const: 2
+      "#size-cells":
+        const: 0
+
+    patternProperties:
+      "^led@[0-9]+,[0-9]+$":
+        type: object
+        $ref: /schemas/leds/common.yaml#
+        properties:
+          reg:
+            description:
+              Grid and segment indices as <grid segment> of this individual LED icon
+        required:
+          - reg
+        unevaluatedProperties: false
+
+    additionalProperties: false
+
+# SPI controllers require 3-wire (combined MISO/MOSI line)
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - fdhisi,fd620
+          - fdhisi,fd628
+          - princeton,pt6964
+          - titanmec,tm1618
+          - titanmec,tm1620
+          - titanmec,tm1628
+          - titanmec,tm1638
+          - wxicore,aip1618
+          - wxicore,aip1628
+then:
+  allOf:
+    - $ref: /schemas/spi/spi-peripheral-props.yaml#
+  properties:
+    spi-3wire: true
+  required:
+    - spi-3wire
+
+dependencies:
+  poll-interval:
+    - linux,keymap
+  linux,keymap:
+    - poll-interval
+  autorepeat:
+    - linux,keymap
+    - poll-interval
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/leds/common.h>
+
+    // I2C example: Magicsee N5 TV box with fd655 controller
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      display-controller@24 {
+        reg = <0x24>;
+        compatible = "fdhisi,fd655";
+
+        digits {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          digit@0 {
+            reg = <0>;
+            segments = <4 3>, <4 4>, <4 5>, <4 0>, <4 1>, <4 2>, <4 6>;
+          };
+
+          digit@1 {
+            reg = <1>;
+            segments = <3 3>, <3 4>, <3 5>, <3 0>, <3 1>, <3 2>, <3 6>;
+          };
+
+          digit@2 {
+            reg = <2>;
+            segments = <2 3>, <2 4>, <2 5>, <2 0>, <2 1>, <2 2>, <2 6>;
+          };
+
+          digit@3 {
+            reg = <3>;
+            segments = <1 3>, <1 4>, <1 5>, <1 0>, <1 1>, <1 2>, <1 6>;
+          };
+        };
+
+        leds {
+          #address-cells = <2>;
+          #size-cells = <0>;
+
+          led@0,0 {
+            reg = <0 0>;
+            function = LED_FUNCTION_ALARM;
+          };
+
+          led@0,1 {
+            reg = <0 1>;
+            function = LED_FUNCTION_USB;
+          };
+
+          led@0,2 {
+            reg = <0 2>;
+            function = "play";
+          };
+
+          led@0,3 {
+            reg = <0 3>;
+            function = "pause";
+          };
+
+          led@0,4 {
+            reg = <0 4>;
+            function = "colon";
+          };
+
+          led@0,5 {
+            reg = <0 5>;
+            function = LED_FUNCTION_LAN;
+          };
+
+          led@0,6 {
+            reg = <0 6>;
+            function = LED_FUNCTION_WLAN;
+          };
+        };
+      };
+    };
+
+  - |
+    #include <dt-bindings/input/input.h>
+
+    // SPI example: TM1638 module with keypad support
+    spi {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      display-controller@0 {
+        reg = <0>;
+        compatible = "titanmec,tm1638";
+        spi-3wire;
+        spi-lsb-first;
+        spi-max-frequency = <500000>;
+
+        label = "tm1638";
+        default-brightness = <2>;
+        max-brightness = <4>;
+        poll-interval = <100>;
+        linux,keymap = <MATRIX_KEY(2, 0, KEY_F1)
+                        MATRIX_KEY(2, 2, KEY_F2)
+                        MATRIX_KEY(2, 4, KEY_F3)
+                        MATRIX_KEY(2, 6, KEY_F4)
+                        MATRIX_KEY(2, 1, KEY_F5)
+                        MATRIX_KEY(2, 3, KEY_F6)
+                        MATRIX_KEY(2, 5, KEY_F7)
+                        MATRIX_KEY(2, 7, KEY_F8)>;
+
+        digits {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          digit@0 {
+            reg = <0>;
+            segments = <7 0>, <7 1>, <7 2>, <7 3>, <7 4>, <7 5>, <7 6>;
+          };
+
+          digit@1 {
+            reg = <1>;
+            segments = <6 0>, <6 1>, <6 2>, <6 3>, <6 4>, <6 5>, <6 6>;
+          };
+
+          digit@2 {
+            reg = <2>;
+            segments = <5 0>, <5 1>, <5 2>, <5 3>, <5 4>, <5 5>, <5 6>;
+          };
+
+          digit@3 {
+            reg = <3>;
+            segments = <4 0>, <4 1>, <4 2>, <4 3>, <4 4>, <4 5>, <4 6>;
+          };
+
+          digit@4 {
+            reg = <4>;
+            segments = <3 0>, <3 1>, <3 2>, <3 3>, <3 4>, <3 5>, <3 6>;
+          };
+
+          digit@5 {
+            reg = <5>;
+            segments = <2 0>, <2 1>, <2 2>, <2 3>, <2 4>, <2 5>, <2 6>;
+          };
+
+          digit@6 {
+            reg = <6>;
+            segments = <1 0>, <1 1>, <1 2>, <1 3>, <1 4>, <1 5>, <1 6>;
+          };
+
+          digit@7 {
+            reg = <7>;
+            segments = <0 0>, <0 1>, <0 2>, <0 3>, <0 4>, <0 5>, <0 6>;
+          };
+        };
+
+        leds {
+          #address-cells = <2>;
+          #size-cells = <0>;
+
+          led@0,7 {
+            reg = <0 7>;
+          };
+
+          led@1,7 {
+            reg = <1 7>;
+          };
+
+          led@2,7 {
+            reg = <2 7>;
+          };
+
+          led@3,7 {
+            reg = <3 7>;
+          };
+
+          led@4,7 {
+            reg = <4 7>;
+          };
+
+          led@5,7 {
+            reg = <5 7>;
+          };
+
+          led@6,7 {
+            reg = <6 7>;
+          };
+
+          led@7,7 {
+            reg = <7 7>;
+          };
+        };
+      };
+    };
+
+  - |
+    #include <dt-bindings/leds/common.h>
+
+    // SPI example: X96 Max with transposed layout (fd628 with tm1628 fallback)
+    spi {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      display-controller@0 {
+        reg = <0>;
+        compatible = "fdhisi,fd628", "titanmec,tm1628";
+        spi-3wire;
+        spi-lsb-first;
+        spi-max-frequency = <500000>;
+
+        digits {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          digit@0 {
+            reg = <0>;
+            segments = <0 3>, <1 3>, <2 3>, <3 3>, <4 3>, <5 3>, <6 3>;
+          };
+
+          digit@1 {
+            reg = <1>;
+            segments = <0 2>, <1 2>, <2 2>, <3 2>, <4 2>, <5 2>, <6 2>;
+          };
+
+          digit@2 {
+            reg = <2>;
+            segments = <0 1>, <1 1>, <2 1>, <3 1>, <4 1>, <5 1>, <6 1>;
+          };
+
+          digit@3 {
+            reg = <3>;
+            segments = <0 0>, <1 0>, <2 0>, <3 0>, <4 0>, <5 0>, <6 0>;
+          };
+        };
+
+        leds {
+          #address-cells = <2>;
+          #size-cells = <0>;
+
+          led@0,4 {
+            reg = <0 4>;
+            function = "apps";
+          };
+
+          led@1,4 {
+            reg = <1 4>;
+            function = "setup";
+          };
+
+          led@2,4 {
+            reg = <2 4>;
+            function = LED_FUNCTION_USB;
+          };
+
+          led@3,4 {
+            reg = <3 4>;
+            function = LED_FUNCTION_SD;
+          };
+
+          led@4,4 {
+            reg = <4 4>;
+            function = "colon";
+          };
+
+          led@5,4 {
+            reg = <5 4>;
+            function = "hdmi";
+          };
+
+          led@6,4 {
+            reg = <6 4>;
+            function = "video";
+          };
+        };
+      };
+    };
-- 
2.43.0

On Wed, Aug 20, 2025 at 12:31:15PM -0400, Jean-François Lessard wrote:
> Add documentation for TM16xx-compatible 7-segment LED display controllers with
> keyscan.

Here and other patches - this is not wrapped.

Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597

> 
> Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
> ---
> 
> Note: The 'segments' property is intentionally not vendor-prefixed as it defines
> a generic hardware description concept applicable to any 7-segment display
> controller. The property describes the fundamental grid/segment coordinate
> mapping that is controller-agnostic and could be reused by other LED matrix
> display bindings. Similar to how 'gpios' describes GPIO connections generically,
> 'segments' describes segment connections in a standardized way using
> uint32-matrix format.
> 
>  .../bindings/auxdisplay/titanmec,tm16xx.yaml  | 471 ++++++++++++++++++
>  1 file changed, 471 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
> 
> diff --git a/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
> new file mode 100644
> index 000000000..b563c6e1e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
> @@ -0,0 +1,471 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm16xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Auxiliary displays based on TM16xx and compatible LED controllers
> +
> +maintainers:
> +  - Jean-François Lessard <jefflessard3@gmail.com>
> +
> +description: |
> +  LED matrix controllers used in auxiliary display devices that drive individual
> +  LED icons and 7-segment digit groups through a grid/segment addressing scheme.
> +  Controllers manage a matrix of LEDs organized as grids (columns/banks in
> +  vendor datasheets) and segments (rows/bit positions in vendor datasheets).
> +  Maximum grid and segment indices are controller-specific.
> +
> +  The controller is agnostic of the display layout. Board-specific LED wiring is
> +  described through child nodes that specify grid/segment coordinates for
> +  individual icons and segment mapping for 7-segment digits.
> +
> +  The bindings use separate 'leds' and 'digits' containers to accommodate
> +  different addressing schemes:
> +  - LEDs use 2-cell addressing (grid, segment) for matrix coordinates
> +  - Digits use 1-cell addressing with explicit segment mapping
> +
> +  Optional keypad scanning is supported when both 'linux,keymap' and
> +  'poll-interval' properties are specified.
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      # Controllers with titanmec,tm1628 fallback

Drop comment, obvious. Schema tells that.

> +      - items:
> +          - enum:
> +              - fdhisi,fd628
> +              - princeton,pt6964
> +              - wxicore,aip1628
> +          - const: titanmec,tm1628
> +      - const: titanmec,tm1628

This is part of one enum

> +      # Controllers with titanmec,tm1618 fallback
> +      - items:
> +          - enum:
> +              - wxicore,aip1618
> +          - const: titanmec,tm1618
> +      - const: titanmec,tm1618

Enum...

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

> +
> +  reg:
> +    maxItems: 1
> +
> +  label:
> +    description: Name of the entire device
> +    default: display

Huh? Why do you need label? Are you sure auxdisplays have labels?


> +
> +  default-brightness:
> +    description:
> +      Brightness to be set if LED's default state is on. Used only during
> +      initialization. If the option is not set then max brightness is used.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +
> +  max-brightness:
> +    description:
> +      Normally the maximum brightness is determined by the hardware and this
> +      property is not required. This property is used to put a software limit
> +      on the brightness apart from what the driver says, as it could happen
> +      that a LED can be made so bright that it gets damaged or causes damage
> +      due to restrictions in a specific system, such as mounting conditions.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +
> +  linux,keymap:
> +    $ref: /schemas/input/matrix-keymap.yaml#/properties/linux,keymap
> +
> +  poll-interval:
> +    $ref: /schemas/input/input.yaml#/properties/poll-interval
> +
> +  autorepeat:
> +    $ref: /schemas/input/input.yaml#/properties/autorepeat

You rather miss some reference to input or touchscreen.

> +
> +  digits:
> +    type: object
> +    description: Container for 7-segment digit group definitions

additionalProperties go here

and blank line

> +    properties:
> +      "#address-cells":
> +        const: 1
> +      "#size-cells":
> +        const: 0
> +
> +    patternProperties:
> +      "^digit@[0-9]+$":
> +        type: object

unevaluatedProperties

Blank line

> +        properties:
> +          reg:
> +            description: Digit position identifier
> +            maxItems: 1

Blank line

> +          segments:
> +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +            description: |
> +              Array of grid/segment coordinate pairs for each 7-segment position.
> +              Each entry is <grid segment> mapping to standard 7-segment positions
> +              in order: a, b, c, d, e, f, g
> +
> +              Standard 7-segment layout:
> +                 aaa
> +                f   b
> +                f   b
> +                 ggg
> +                e   c
> +                e   c
> +                 ddd
> +            items:
> +              items:
> +                - description: Grid index
> +                - description: Segment index
> +            minItems: 7
> +            maxItems: 7
> +        required:
> +          - reg
> +          - segments
> +        unevaluatedProperties: false
> +
> +    additionalProperties: false
> +
> +  leds:
> +    type: object
> +    description: Container for individual LED icon definitions
> +    properties:
> +      "#address-cells":
> +        const: 2
> +      "#size-cells":
> +        const: 0
> +
> +    patternProperties:
> +      "^led@[0-9]+,[0-9]+$":
> +        type: object
> +        $ref: /schemas/leds/common.yaml#
> +        properties:
> +          reg:
> +            description:
> +              Grid and segment indices as <grid segment> of this individual LED icon
> +        required:
> +          - reg
> +        unevaluatedProperties: false
> +
> +    additionalProperties: false

Best regards,
Krzysztof

Le 21 août 2025 03 h 48 min 21 s HAE, Krzysztof Kozlowski <krzk@kernel.org> a écrit :
>On Wed, Aug 20, 2025 at 12:31:15PM -0400, Jean-François Lessard wrote:
>> Add documentation for TM16xx-compatible 7-segment LED display controllers with
>> keyscan.
>
>Here and other patches - this is not wrapped.
>
>Please wrap commit message according to Linux coding style / submission
>process (neither too early nor over the limit):
>https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>

Well received. Will wrap at 75 instead of 80 for commit messages.

>> 
>> Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
>> ---
>> 
>> Note: The 'segments' property is intentionally not vendor-prefixed as it defines
>> a generic hardware description concept applicable to any 7-segment display
>> controller. The property describes the fundamental grid/segment coordinate
>> mapping that is controller-agnostic and could be reused by other LED matrix
>> display bindings. Similar to how 'gpios' describes GPIO connections generically,
>> 'segments' describes segment connections in a standardized way using
>> uint32-matrix format.
>> 
>>  .../bindings/auxdisplay/titanmec,tm16xx.yaml  | 471 ++++++++++++++++++
>>  1 file changed, 471 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
>> 
>> diff --git a/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
>> new file mode 100644
>> index 000000000..b563c6e1e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
>> @@ -0,0 +1,471 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm16xx.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Auxiliary displays based on TM16xx and compatible LED controllers
>> +
>> +maintainers:
>> +  - Jean-François Lessard <jefflessard3@gmail.com>
>> +
>> +description: |
>> +  LED matrix controllers used in auxiliary display devices that drive individual
>> +  LED icons and 7-segment digit groups through a grid/segment addressing scheme.
>> +  Controllers manage a matrix of LEDs organized as grids (columns/banks in
>> +  vendor datasheets) and segments (rows/bit positions in vendor datasheets).
>> +  Maximum grid and segment indices are controller-specific.
>> +
>> +  The controller is agnostic of the display layout. Board-specific LED wiring is
>> +  described through child nodes that specify grid/segment coordinates for
>> +  individual icons and segment mapping for 7-segment digits.
>> +
>> +  The bindings use separate 'leds' and 'digits' containers to accommodate
>> +  different addressing schemes:
>> +  - LEDs use 2-cell addressing (grid, segment) for matrix coordinates
>> +  - Digits use 1-cell addressing with explicit segment mapping
>> +
>> +  Optional keypad scanning is supported when both 'linux,keymap' and
>> +  'poll-interval' properties are specified.
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      # Controllers with titanmec,tm1628 fallback
>
>Drop comment, obvious. Schema tells that.
>

Well received.

>> +      - items:
>> +          - enum:
>> +              - fdhisi,fd628
>> +              - princeton,pt6964
>> +              - wxicore,aip1628
>> +          - const: titanmec,tm1628
>> +      - const: titanmec,tm1628
>
>This is part of one enum
>
>> +      # Controllers with titanmec,tm1618 fallback
>> +      - items:
>> +          - enum:
>> +              - wxicore,aip1618
>> +          - const: titanmec,tm1618
>> +      - const: titanmec,tm1618
>
>Enum...
>
>> +      # 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.

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

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

>> +
>> +  default-brightness:
>> +    description:
>> +      Brightness to be set if LED's default state is on. Used only during
>> +      initialization. If the option is not set then max brightness is used.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +  max-brightness:
>> +    description:
>> +      Normally the maximum brightness is determined by the hardware and this
>> +      property is not required. This property is used to put a software limit
>> +      on the brightness apart from what the driver says, as it could happen
>> +      that a LED can be made so bright that it gets damaged or causes damage
>> +      due to restrictions in a specific system, such as mounting conditions.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +  linux,keymap:
>> +    $ref: /schemas/input/matrix-keymap.yaml#/properties/linux,keymap
>> +
>> +  poll-interval:
>> +    $ref: /schemas/input/input.yaml#/properties/poll-interval
>> +
>> +  autorepeat:
>> +    $ref: /schemas/input/input.yaml#/properties/autorepeat
>
>You rather miss some reference to input or touchscreen.
>

Well received. I will replace the individual references with:

allOf:
  - $ref: /schemas/input/input.yaml#
  - $ref: /schemas/input/matrix-keymap.yaml#

>> +
>> +  digits:
>> +    type: object
>> +    description: Container for 7-segment digit group definitions
>
>additionalProperties go here
>
>and blank line
>
>> +    properties:
>> +      "#address-cells":
>> +        const: 1
>> +      "#size-cells":
>> +        const: 0
>> +
>> +    patternProperties:
>> +      "^digit@[0-9]+$":
>> +        type: object
>
>unevaluatedProperties
>
>Blank line
>
>> +        properties:
>> +          reg:
>> +            description: Digit position identifier
>> +            maxItems: 1
>
>Blank line
>

Well received.

>> +          segments:
>> +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
>> +            description: |
>> +              Array of grid/segment coordinate pairs for each 7-segment position.
>> +              Each entry is <grid segment> mapping to standard 7-segment positions
>> +              in order: a, b, c, d, e, f, g
>> +
>> +              Standard 7-segment layout:
>> +                 aaa
>> +                f   b
>> +                f   b
>> +                 ggg
>> +                e   c
>> +                e   c
>> +                 ddd
>> +            items:
>> +              items:
>> +                - description: Grid index
>> +                - description: Segment index
>> +            minItems: 7
>> +            maxItems: 7
>> +        required:
>> +          - reg
>> +          - segments
>> +        unevaluatedProperties: false
>> +
>> +    additionalProperties: false
>> +
>> +  leds:
>> +    type: object
>> +    description: Container for individual LED icon definitions
>> +    properties:
>> +      "#address-cells":
>> +        const: 2
>> +      "#size-cells":
>> +        const: 0
>> +
>> +    patternProperties:
>> +      "^led@[0-9]+,[0-9]+$":
>> +        type: object
>> +        $ref: /schemas/leds/common.yaml#
>> +        properties:
>> +          reg:
>> +            description:
>> +              Grid and segment indices as <grid segment> of this individual LED icon
>> +        required:
>> +          - reg
>> +        unevaluatedProperties: false
>> +
>> +    additionalProperties: false
>
>Best regards,
>Krzysztof
>

Thanks for your detailed feedback.

Best regards,
Jean-François Lessard

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

Le 22 août 2025 02 h 44 min 26 s HAE, Krzysztof Kozlowski <krzk@kernel.org> a écrit :
>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?
>
>

I apologize for misunderstanding. I hope this fits your specific comments:

properties:
  compatible:
    oneOf:
      - items:
          - enum:
              - fdhisi,fd628
              - princeton,pt6964
              - wxicore,aip1628
          - const: titanmec,tm1628  
      - items:
          - enum:
              - wxicore,aip1618
          - const: titanmec,tm1618
      - items:
          - enum:
              - fdhisi,fd650
              - wxicore,aip650
          - const: titanmec,tm1650
      - enum:
          - titanmec,tm1628
          - titanmec,tm1618
          - titanmec,tm1650
          - fdhisi,fd620
          - fdhisi,fd655
          - fdhisi,fd6551
          - titanmec,tm1620
          - titanmec,tm1638
          - winrise,hbs658

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

The top-level device node is registered as a pseudo-LED device to control the
entire display (brightness 0-7, digits) via /sys/class/leds/{label}.
Individual LED icons are separate LED devices at
/sys/class/leds/{label}::{function} with on/off status control (brightness 0-1).

However, the top-level pseudo-LED shouldn't support all LED properties
(no color, function, trigger-sources, etc.), so I'll reference specific
properties from leds/common.yaml rather than the entire schema:

  label:
    $ref: /schemas/leds/common.yaml#/properties/label
  max-brightness:
    $ref: /schemas/leds/common.yaml#/properties/max-brightness

This approach provides LED subsystem consistency while avoiding inappropriate 
properties for the entire display.

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

Best Regards,
Jean-François Lessard