dt-bindings: rtc: epson,rx6110: Convert to DT Schema
Subsystems (2)
PATCH v2 1/1 dt-bindings: rtc: epson,rx6110: Convert to DT Schema
Convert the Epson RX6110 Real Time Clock devicetree binding from the legacy text format to DT schema.
---
Changelog:
Changes since v1:
- Reuse common SPI peripheral properties
- Drop redundant SPI-specific comment
- Remove unused labels from examples
Link to v1:https://lore.kernel.org/all/[email protected]/
--- .../devicetree/bindings/rtc/epson,rx6110.txt | 39 ------------ .../devicetree/bindings/rtc/epson,rx6110.yaml | 62 +++++++++++++++++++ 2 files changed, 62 insertions(+), 39 deletions(-) delete mode 100644 Documentation/devicetree/bindings/rtc/epson,rx6110.txt create mode 100644 Documentation/devicetree/bindings/rtc/epson,rx6110.yaml
Documentation/devicetree/bindings/rtc/epson,rx6110.txt deleted +0 -39
@@ -1,39 +0,0 @@ -Epson RX6110 Real Time Clock -============================ - -The Epson RX6110 can be used with SPI or I2C busses. The kind of -bus depends on the SPISEL pin and can not be configured via software. - -I2C mode --------- - -Required properties: - - compatible: should be: "epson,rx6110" - - reg : the I2C address of the device for I2C - -Example: - - rtc: rtc@32 { - compatible = "epson,rx6110" - reg = <0x32>; - }; - -SPI mode --------- - -Required properties: - - compatible: should be: "epson,rx6110" - - reg: chip select number - - spi-cs-high: RX6110 needs chipselect high - - spi-cpha: RX6110 works with SPI shifted clock phase - - spi-cpol: RX6110 works with SPI inverse clock polarity - -Example: - - rtc: rtc@3 { - compatible = "epson,rx6110" - reg = <3> - spi-cs-high; - spi-cpha; - spi-cpol; - };
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +62 -0
62 lines not on this page · raw message
Signature · 1 line
2.43.0
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] The YAML binding omits a reference to the core RTC subsystem schema (`rtc.yaml`). - [Medium] The…
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The YAML binding omits a reference to the core RTC subsystem schema (rtc.yaml).
- [Medium] The strict requirement for SPI-specific properties was lost during the schema conversion. --
commit 83ad9493a42cbad1f11db8ac3498c9be50a357d1
Author: Udaya Kiran Challa <[email protected]>
dt-bindings: rtc: epson,rx6110: Convert to DT Schema
This commit converts the Epson RX6110 Real Time Clock devicetree binding from the legacy text format to DT schema.
Quoted 4 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +0
-0
[ ... ]
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml line 18
Quoted 2 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +2
-0+allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml#
Should this also include a reference to rtc.yaml# in the allOf block? Without it, since unevaluatedProperties is false, won't valid standard RTC properties like start-year or aux-voltage-chargeable cause validation errors? This omission appears to introduce a functional regression by bypassing the standard nodename checks provided by the core schema.
[ ... ]
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml line 34
Quoted 8 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +8
-0+ spi-cpha: true + spi-cpol: true + +required: + - compatible + - reg + +unevaluatedProperties: false
The legacy text binding listed spi-cs-high, spi-cpha, and spi-cpol as mandatory required properties when the device operates in SPI mode.
Because they are omitted from the required list to support I2C mode, won't misconfigured SPI nodes missing these hardware configuration flags now silently pass validation? Would adding a conditional allOf/if block be appropriate to enforce these properties for SPI configurations and avoid this regression?
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Quoted 28 lines · On Sat, May 09, 2026 at 10:27:02AM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The YAML binding omits a reference to the core RTC subsystem schema (rtc.yaml).
- [Medium] The strict requirement for SPI-specific properties was lost during the schema conversion. --commit
83ad9493a42cbad1f11db8ac3498c9be50a357d1
Author: Udaya Kiran Challa <[email protected]>dt-bindings: rtc: epson,rx6110: Convert to DT Schema
This commit converts the Epson RX6110 Real Time Clock devicetree binding from the legacy text format to DT schema.
Quoted 4 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +0
-0[ ... ]
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml line 18
Quoted 2 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +2
-0+allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml#Should this also include a reference to rtc.yaml# in the allOf block? Without it, since unevaluatedProperties is false, won't valid standard RTC properties like start-year or aux-voltage-chargeable cause validation errors? This omission appears to introduce a functional regression by bypassing the standard nodename checks provided by the core schema.
[ ... ]
Quoted 11 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml line 34
Quoted 8 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +8
-0+ spi-cpha: true + spi-cpol: true + +required: + - compatible + - reg + +unevaluatedProperties: falseThe legacy text binding listed spi-cs-high, spi-cpha, and spi-cpol as mandatory required properties when the device operates in SPI mode.
+ the fact that cpha/cpol are listed with : true, and spi-cs-high isn't which is confusing IMO.
Quoted 5 lines
Because they are omitted from the required list to support I2C mode, won't misconfigured SPI nodes missing these hardware configuration flags now silently pass validation? Would adding a conditional allOf/if block be appropriate to enforce these properties for SPI configurations and avoid this regression?
Don't do this, since it requires knowing what the parent node is. If anything, make it something like
if: oneOf: <> then: allOf: <>