dt-bindings: rtc: epson,rx6110: Convert to DT Schema
Subsystems (2)
PATCH v3 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 v2:
- Reference rtc.yaml for common RTC properties
- Add conditional validation for SPI mode properties
Link to v2:https://lore.kernel.org/all/[email protected]/
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 | 79 +++++++++++++++++++ 2 files changed, 79 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 +79 -0
79 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 1 potential issue(s) to consider: - [Medium] The use of `oneOf` in the `if` condition allows invalid configurations with exactly two SPI…
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The use of oneOf in the if condition allows invalid configurations with exactly two SPI properties to silently bypass validation. --
commit 61c42b03c451c90501fbc1f5dfb0ec651bc79cc8
Author: Udaya Kiran Challa <[email protected]>
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.
Quoted 5 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +0
-0
[ ... ]
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml line 43
Quoted 12 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +12
-0+required: + - compatible + - reg + +if: + oneOf: + - required: + - spi-cs-high + - required: + - spi-cpha + - required: + - spi-cpol
Does this oneOf condition allow invalid configurations with exactly two SPI properties to silently bypass validation?
In JSON schema, oneOf requires exactly one of the subschemas to evaluate to true. If a device tree node provides exactly two of the three SPI properties (e.g., spi-cs-high and spi-cpha, but omitting spi-cpol), the node satisfies two of the required conditions.
Because it matches two subschemas rather than one, the oneOf condition evaluates to false. Consequently, the if condition fails, the then block is skipped, and the schema successfully validates the incomplete node.
Would it be better to use anyOf here instead, to correctly trigger the requirement that all three properties must be present if at least one is provided?
Quoted 6 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +6
-0+ +then: + required: + - spi-cs-high + - spi-cpha + - spi-cpol
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Quoted 41 lines · On Sat, May 09, 2026 at 06:28:29PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The use ofoneOfin theifcondition allows invalid configurations with exactly two SPI properties to silently bypass validation. --commit
61c42b03c451c90501fbc1f5dfb0ec651bc79cc8
Author: Udaya Kiran Challa <[email protected]>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.
Quoted 5 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +0
-0[ ... ]
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml line 43
Quoted 12 lines
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml new file +12
-0+required: + - compatible + - reg + +if: + oneOf: + - required: + - spi-cs-high + - required: + - spi-cpha + - required: + - spi-cpolDoes this oneOf condition allow invalid configurations with exactly two SPI properties to silently bypass validation?
In JSON schema, oneOf requires exactly one of the subschemas to evaluate to true. If a device tree node provides exactly two of the three SPI properties (e.g., spi-cs-high and spi-cpha, but omitting spi-cpol), the node satisfies two of the required conditions.
Quoted 7 lines
Because it matches two subschemas rather than one, the oneOf condition evaluates to false. Consequently, the if condition fails, the then block is skipped, and the schema successfully validates the incomplete node.
Would it be better to use anyOf here instead, to correctly trigger the requirement that all three properties must be present if at least one is provided?
^^^ This is correct, I should have suggested anyOf not oneOf.