Add documentation for TM16xx-compatible 7-segment LED display controllers
with keyscan.
Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
---
Notes:
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.
The property uses explicit coordinate pairs to handle real-world
hardware variations. Some board manufacturers use standard layouts
(same grid, different segments per digit) while others use transposed
layouts (same segment, different grids per digit). The coordinate-pair
approach accommodates both patterns without requiring separate arrays
or boolean flags, as confirmed acceptable by DT maintainers.
.../bindings/auxdisplay/titanmec,tm16xx.yaml | 463 ++++++++++++++++++
MAINTAINERS | 5 +
2 files changed, 468 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 000000000000..d324023bbffb
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
@@ -0,0 +1,463 @@
+# 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 brightness and grid/segment indices are controller-specific.
+ Controller-specific maximum are validated in the driver.
+
+ 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
+
+ The controller node exposes a logical LED-like control for the aggregate
+ display brightness. Child nodes describe individual icons and 7-seg digits.
+ The top-level control supports only label and brightness-related properties
+ and does not support other common LED properties such as color or function.
+ Child LED nodes use the standard LED binding.
+
+ Optional keypad scanning is supported when both 'linux,keymap' and
+ 'poll-interval' properties are specified.
+
+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:
+ - fdhisi,fd620
+ - fdhisi,fd655
+ - fdhisi,fd6551
+ - titanmec,tm1618
+ - titanmec,tm1620
+ - titanmec,tm1628
+ - titanmec,tm1638
+ - titanmec,tm1650
+ - winrise,hbs658
+
+ reg:
+ maxItems: 1
+
+ label:
+ description:
+ The label for the top-level LED. If omitted, the label is taken from the
+ node name (excluding the unit address). It has to uniquely identify a
+ device, i.e. no other LED class device can be assigned the same label.
+
+ max-brightness:
+ minimum: 0 # 0=off
+ maximum: 8 # Maximum across all TM16xx controllers
+ 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.
+
+ default-brightness:
+ minimum: 0 # 0=off
+ maximum: 8 # Maximum across all TM16xx controllers
+ 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.
+
+ digits:
+ type: object
+ description: Container for 7-segment digit group definitions
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^digit@[0-9]+$":
+ type: object
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ Digit position identifier numbered sequentially left-to-right,
+ with reg=0 representing the leftmost digit position as displayed
+ to the user.
+ 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
+
+ leds:
+ type: object
+ description: Container for individual LED icon definitions
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 2
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-9]+,[0-9]+$":
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ Grid and segment indices as <grid segment> of this individual LED icon
+
+ required:
+ - reg
+
+dependencies:
+ poll-interval:
+ - linux,keymap
+ linux,keymap:
+ - poll-interval
+ autorepeat:
+ - linux,keymap
+ - poll-interval
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/leds/common.yaml#
+ properties:
+ color: false
+ function: false
+ function-enumerator: false
+ - $ref: /schemas/input/input.yaml#
+ - $ref: /schemas/input/matrix-keymap.yaml#
+ # 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:
+ $ref: /schemas/spi/spi-peripheral-props.yaml#
+ properties:
+ spi-3wire: true
+ required:
+ - spi-3wire
+
+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@24 {
+ reg = <0x24>;
+ compatible = "fdhisi,fd655";
+
+ digits {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ digit@0 {
+ reg = <0>;
+ segments = <1 3>, <1 4>, <1 5>, <1 0>, <1 1>, <1 2>, <1 6>;
+ };
+ digit@1 {
+ reg = <1>;
+ segments = <2 3>, <2 4>, <2 5>, <2 0>, <2 1>, <2 2>, <2 6>;
+ };
+ digit@2 {
+ reg = <2>;
+ segments = <3 3>, <3 4>, <3 5>, <3 0>, <3 1>, <3 2>, <3 6>;
+ };
+ digit@3 {
+ reg = <3>;
+ segments = <4 3>, <4 4>, <4 5>, <4 0>, <4 1>, <4 2>, <4 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@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@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 7>, <1 7>, <2 7>, <3 7>, <4 7>, <5 7>, <6 7>;
+ };
+ digit@1 {
+ reg = <1>;
+ segments = <0 6>, <1 6>, <2 6>, <3 6>, <4 6>, <5 6>, <6 6>;
+ };
+ digit@2 {
+ reg = <2>;
+ segments = <0 5>, <1 5>, <2 5>, <3 5>, <4 5>, <5 5>, <6 5>;
+ };
+ digit@3 {
+ reg = <3>;
+ segments = <0 4>, <1 4>, <2 4>, <3 4>, <4 4>, <5 4>, <6 4>;
+ };
+ };
+
+ leds {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ led@0,3 {
+ reg = <0 3>;
+ function = "apps";
+ };
+ led@1,3 {
+ reg = <1 3>;
+ function = "setup";
+ };
+ led@2,3 {
+ reg = <2 3>;
+ function = LED_FUNCTION_USB;
+ };
+ led@3,3 {
+ reg = <3 3>;
+ function = LED_FUNCTION_SD;
+ };
+ led@4,3 {
+ reg = <4 3>;
+ function = "colon";
+ };
+ led@5,3 {
+ reg = <5 3>;
+ function = "hdmi";
+ };
+ led@6,3 {
+ reg = <6 3>;
+ function = "video";
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index f6206963efbf..9449dfc43a15 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25441,6 +25441,11 @@ W: http://sourceforge.net/projects/tlan/
F: Documentation/networking/device_drivers/ethernet/ti/tlan.rst
F: drivers/net/ethernet/ti/tlan.*
+TM16XX-COMPATIBLE LED CONTROLLERS DISPLAY DRIVER
+M: Jean-François Lessard <jefflessard3@gmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
+
TMIO/SDHI MMC DRIVER
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
L: linux-mmc@vger.kernel.org
--
2.43.0
On Fri, Sep 26, 2025 at 10:19:04AM -0400, Jean-François Lessard wrote: > Add documentation for TM16xx-compatible 7-segment LED display controllers > with keyscan. > > Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com> > --- > > Notes: > 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. > > The property uses explicit coordinate pairs to handle real-world > hardware variations. Some board manufacturers use standard layouts > (same grid, different segments per digit) while others use transposed > layouts (same segment, different grids per digit). The coordinate-pair > approach accommodates both patterns without requiring separate arrays > or boolean flags, as confirmed acceptable by DT maintainers. > > .../bindings/auxdisplay/titanmec,tm16xx.yaml | 463 ++++++++++++++++++ > MAINTAINERS | 5 + > 2 files changed, 468 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 000000000000..d324023bbffb > --- /dev/null > +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml > @@ -0,0 +1,463 @@ > +# 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 brightness and grid/segment indices are controller-specific. > + Controller-specific maximum are validated in the driver. > + > + 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 > + > + The controller node exposes a logical LED-like control for the aggregate > + display brightness. Child nodes describe individual icons and 7-seg digits. > + The top-level control supports only label and brightness-related properties > + and does not support other common LED properties such as color or function. > + Child LED nodes use the standard LED binding. > + > + Optional keypad scanning is supported when both 'linux,keymap' and > + 'poll-interval' properties are specified. > + > +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: > + - fdhisi,fd620 > + - fdhisi,fd655 > + - fdhisi,fd6551 > + - titanmec,tm1618 > + - titanmec,tm1620 > + - titanmec,tm1628 > + - titanmec,tm1638 > + - titanmec,tm1650 > + - winrise,hbs658 > + > + reg: > + maxItems: 1 > + > + label: > + description: > + The label for the top-level LED. If omitted, the label is taken from the > + node name (excluding the unit address). It has to uniquely identify a > + device, i.e. no other LED class device can be assigned the same label. > + > + max-brightness: > + minimum: 0 # 0=off > + maximum: 8 # Maximum across all TM16xx controllers > + 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. > + > + default-brightness: > + minimum: 0 # 0=off > + maximum: 8 # Maximum across all TM16xx controllers > + 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. > + > + digits: > + type: object > + description: Container for 7-segment digit group definitions > + additionalProperties: false > + > + properties: > + "#address-cells": > + const: 1 > + "#size-cells": > + const: 0 > + > + patternProperties: > + "^digit@[0-9]+$": Unit addresses are typically hex, so: [0-9a-f]+ > + type: object > + unevaluatedProperties: false > + > + properties: > + reg: > + description: > + Digit position identifier numbered sequentially left-to-right, > + with reg=0 representing the leftmost digit position as displayed > + to the user. > + 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 > + > + leds: > + type: object > + description: Container for individual LED icon definitions > + additionalProperties: false > + > + properties: > + "#address-cells": > + const: 2 > + "#size-cells": > + const: 0 > + > + patternProperties: > + "^led@[0-9]+,[0-9]+$": Again, hex please. I assume this is <grid>,<segment>? Please add a description for the node and say that. > + type: object > + $ref: /schemas/leds/common.yaml# > + unevaluatedProperties: false > + > + properties: > + reg: > + description: > + Grid and segment indices as <grid segment> of this individual LED icon > + > + required: > + - reg > + > +dependencies: > + poll-interval: > + - linux,keymap > + linux,keymap: > + - poll-interval > + autorepeat: > + - linux,keymap > + - poll-interval > + > +required: > + - compatible > + - reg > + > +allOf: > + - $ref: /schemas/leds/common.yaml# > + properties: > + color: false > + function: false > + function-enumerator: false > + - $ref: /schemas/input/input.yaml# > + - $ref: /schemas/input/matrix-keymap.yaml# > + # 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: > + $ref: /schemas/spi/spi-peripheral-props.yaml# > + properties: > + spi-3wire: true You can drop properties. > + required: > + - spi-3wire With those nits fixed, Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Le 1 octobre 2025 22 h 44 min 31 s HAE, Rob Herring <robh@kernel.org> a écrit : >On Fri, Sep 26, 2025 at 10:19:04AM -0400, Jean-François Lessard wrote: >> Add documentation for TM16xx-compatible 7-segment LED display controllers >> with keyscan. >> ... >> + >> + digits: >> + type: object >> + description: Container for 7-segment digit group definitions >> + additionalProperties: false >> + >> + properties: >> + "#address-cells": >> + const: 1 >> + "#size-cells": >> + const: 0 >> + >> + patternProperties: >> + "^digit@[0-9]+$": > >Unit addresses are typically hex, so: [0-9a-f]+ > Acknowledged. Will change to hex pattern. >> + type: object >> + unevaluatedProperties: false >> + >> + properties: >> + reg: >> + description: >> + Digit position identifier numbered sequentially left-to-right, >> + with reg=0 representing the leftmost digit position as displayed >> + to the user. >> + 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 >> + >> + leds: >> + type: object >> + description: Container for individual LED icon definitions >> + additionalProperties: false >> + >> + properties: >> + "#address-cells": >> + const: 2 >> + "#size-cells": >> + const: 0 >> + >> + patternProperties: >> + "^led@[0-9]+,[0-9]+$": > >Again, hex please. > Acknowledged. Will change to hex pattern. >I assume this is <grid>,<segment>? Please add a description for the >node and say that. > Yes this is <grid>,<segment>. Will add description. >> + type: object >> + $ref: /schemas/leds/common.yaml# >> + unevaluatedProperties: false >> + >> + properties: >> + reg: >> + description: >> + Grid and segment indices as <grid segment> of this individual LED icon >> + >> + required: >> + - reg >> + >> +dependencies: >> + poll-interval: >> + - linux,keymap >> + linux,keymap: >> + - poll-interval >> + autorepeat: >> + - linux,keymap >> + - poll-interval >> + >> +required: >> + - compatible >> + - reg >> + >> +allOf: >> + - $ref: /schemas/leds/common.yaml# >> + properties: >> + color: false >> + function: false >> + function-enumerator: false >> + - $ref: /schemas/input/input.yaml# >> + - $ref: /schemas/input/matrix-keymap.yaml# >> + # 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: >> + $ref: /schemas/spi/spi-peripheral-props.yaml# >> + properties: >> + spi-3wire: true > >You can drop properties. > The issue is spi-3wire is defined in the child node of spi/spi-controller.yaml, not in spi-peripheral-props.yaml. Removing properties did not pass dt validation. Am I missing something? >> + required: >> + - spi-3wire > >With those nits fixed, > >Reviewed-by: Rob Herring (Arm) <robh@kernel.org> > Thank you!
Hi Rob,
Thank you for the review and Reviewed-by tag. I've addressed all your feedback
except one item that's causing validation issues.
Le 1 octobre 2025 22 h 58 min 38 s HAE, "Jean-François Lessard" <jefflessard3@gmail.com> a écrit :
>Le 1 octobre 2025 22 h 44 min 31 s HAE, Rob Herring <robh@kernel.org> a écrit :
>>On Fri, Sep 26, 2025 at 10:19:04AM -0400, Jean-François Lessard wrote:
>>> Add documentation for TM16xx-compatible 7-segment LED display controllers
>>> with keyscan.
...
>>> +
>>> +allOf:
>>> + - $ref: /schemas/leds/common.yaml#
>>> + properties:
>>> + color: false
>>> + function: false
>>> + function-enumerator: false
>>> + - $ref: /schemas/input/input.yaml#
>>> + - $ref: /schemas/input/matrix-keymap.yaml#
>>> + # 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:
>>> + $ref: /schemas/spi/spi-peripheral-props.yaml#
>>> + properties:
>>> + spi-3wire: true
>>
>>You can drop properties.
>>
>
>The issue is spi-3wire is defined in the child node of spi/spi-controller.yaml,
>not in spi-peripheral-props.yaml.
>
>Removing properties did not pass dt validation. Am I missing something?
>
You suggested dropping "properties:" in the SPI 3-wire section:
then:
$ref: /schemas/spi/spi-peripheral-props.yaml#
spi-3wire: true
required:
- spi-3wire
However, this causes dt_binding_check to fail with:
'spi-3wire' is not one of ['$ref', 'additionalItems', ... 'properties',
'required', 'then', ...]
Unevaluated properties are not allowed ('spi-3wire' was unexpected)
It appears the schema requires "properties:" to recognize spi-3wire as a
property constraint rather than a schema keyword. Should I keep the properties
wrapper, or is there a different way to structure this that I'm missing?
>>> + required:
>>> + - spi-3wire
>>
>>With those nits fixed,
>>
>>Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
>>
Thanks for clarifying.
Best regards,
Jean-François
© 2016 - 2026 Red Hat, Inc.