From: sashiko-bot@kernel.org
To: "Markus Probst" <markus.probst@posteo.de>
Cc: robh@kernel.org, linux-rtc@vger.kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH v9 1/6] dt-bindings: rtc: Add pinctrl for S35390A
Date: Wed, 16 Sep 2026 16:07:29 +0000 [thread overview]
Message-ID: <20260916160730.578441F0089C@smtp.kernel.org> (raw)
In-Reply-To: <20260916-rtc_s35390a_int1-v9-1-b2567a3e4959@posteo.de>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] dt-bindings: missing #clock-cells in required list
- [Medium] dt-bindings: undocumented clock provider capability
- [Medium] dt-bindings: missing constraint for pmin2 pin function
--
commit ee787a668e377f31a7722c1acf8927b88011aa60
Author: Markus Probst <markus.probst@posteo.de>
Subject: dt-bindings: rtc: Add pinctrl for S35390A
This commit moves the devicetree bindings for the S-35390A RTC into its own
schema file. It adds the necessary properties to configure individual pins via
pinctrl, allowing the interrupt signal to be used for a wakeup alarm.
> diff --git a/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> new file mode 100644
> index 0000000000000..f3bf5900fb3ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
> @@ -0,0 +1,121 @@
[ ... ]
> + wakeup-parent: true
> +
> + wakeup-source: true
> +
> + "#clock-cells":
> + const: 1
[Severity: Medium]
The commit message states the change adds pinctrl to allow the interrupt
signal 1 to be used for a wakeup alarm. However, the schema also introduces
"#clock-cells" and a "clock" output pin function.
Does this introduce a significant undocumented capability (clock provider
functionality) which is unstated in the commit description?
[ ... ]
> + function:
> + description: |
> + Pin function:
> + - ignore: Preserve the previous state.
> + - disable: Disable pin output.
> + - wakeup: Output wakes up the system.
> + - clock: Output clock pulse.
> + - pmin1: Minute periodical output with 50% duty.
> + - pmin2: Minute periodical output L for 7.81 ms.
> + Can only be used with pin int1.
> + enum:
> + - ignore
> + - disable
> + - wakeup
> + - clock
> + - pmin1
> + - pmin2
[Severity: Medium]
The description for the "pmin2" function explicitly states it can only be used
with pin int1.
Because there is no conditional allOf/if/then block at the pinmux node level
linking them, will a device tree incorrectly using pins = "int2"; function =
"pmin2"; silently pass schema validation despite being an invalid hardware
configuration?
[ ... ]
> +required:
> + - compatible
> + - reg
[Severity: Medium]
According to the dt-bindings subsystem rules, when hardware gains new provider
capabilities, the corresponding standard properties must be added to the
required list with appropriate constraints.
Should "#clock-cells" be added to this required list to prevent incomplete
device tree nodes from silently passing schema validation?
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + rtc@30 {
[Severity: Medium]
According to the dt-bindings subsystem rules, when hardware gains new provider
capabilities, the corresponding standard properties must appear in the examples.
Should the example device tree node be updated to include the required
"#clock-cells" property?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260916-rtc_s35390a_int1-v9-0-b2567a3e4959@posteo.de?part=1
next prev parent reply other threads:[~2026-09-16 16:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 16:00 [PATCH v9 0/6] rtc: s35390a: Allow use of output pin for interrupt signal 1 for wakealarm Markus Probst
2026-09-16 16:00 ` [PATCH v9 1/6] dt-bindings: rtc: Add pinctrl for S35390A Markus Probst
2026-09-16 16:07 ` sashiko-bot [this message]
2026-09-24 22:02 ` Rob Herring
2026-09-16 16:00 ` [PATCH v9 2/6] rtc: s35390a: Add missing newline to dev_err Markus Probst
2026-09-16 16:04 ` sashiko-bot
2026-09-16 16:00 ` [PATCH v9 3/6] rtc: s35390a: Fix alarm not disabling Markus Probst
2026-09-16 16:13 ` sashiko-bot
2026-09-16 16:00 ` [PATCH v9 4/6] rtc: s35390a: Read 24-hour mode on access Markus Probst
2026-09-16 16:10 ` sashiko-bot
2026-09-16 16:00 ` [PATCH v9 5/6] rtc: s35390a: Add pinctrl Markus Probst
2026-09-16 16:12 ` sashiko-bot
2026-09-16 16:00 ` [PATCH v9 6/6] rtc: s35390a: Add synology quirk Markus Probst
2026-09-16 16:05 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260916160730.578441F0089C@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=markus.probst@posteo.de \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox