From: sashiko-bot@kernel.org
To: "Shubham Patil" <shubhamsanjay.patil@amd.com>
Cc: linux-i3c@lists.infradead.org, robh@kernel.org,
Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: i3c: dw: Document missing optional core reset
Date: Mon, 20 Jul 2026 07:43:27 +0000 [thread overview]
Message-ID: <20260720074328.1F18B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720073510.1869623-2-shubhamsanjay.patil@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The binding schema adds the `resets` property but intentionally omits `reset-names`. The driver strictly requires `reset-names = "core_rst"` to find the reset control, causing it to silently ignore the reset.
--
--- Patch [1]: [PATCH v2 1/2] dt-bindings: i3c: dw: Document missing optional core reset ---
commit 673b06088a9b59875d717db2c9afb56295ac87a9
Author: Shubham Patil <shubhamsanjay.patil@amd.com>
dt-bindings: i3c: dw: Document missing optional core reset
This commit documents an optional core reset property for the DesignWare I3C
master IP. It adds the resets property with a maxItems of 1 to the schema
but explicitly drops the reset-name property.
> diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
> index e803457d3f554..dc7ee38001d6d 100644
> --- a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
> +++ b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
> @@ -38,6 +38,9 @@ properties:
> interrupts:
> maxItems: 1
>
> + resets:
> + maxItems: 1
> +
[Severity: High]
Since this schema intentionally omits reset-names, device trees cannot
provide it without breaking schema validation.
However, doesn't the driver explicitly rely on reset-names to find this
reset control?
Looking at dw_i3c_common_probe() in drivers/i3c/master/dw-i3c-master.c:
master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(
&pdev->dev, "core_rst");
Because this searches for the "core_rst" string in the reset-names
property, won't it fail to find the reset and silently return NULL
without the property being defined in the device tree?
This would turn all subsequent reset operations into no-ops. Should
reset-names be added back to the binding to match the driver's
expectations?
> power-domains:
> maxItems: 1
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720073510.1869623-1-shubhamsanjay.patil@amd.com?part=1
next prev parent reply other threads:[~2026-07-20 7:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 7:35 [PATCH v2 0/2] i3c: dw: Document optional core reset and drop redundant name Shubham Patil
2026-07-20 7:35 ` [PATCH v2 1/2] dt-bindings: i3c: dw: Document missing optional core reset Shubham Patil
2026-07-20 7:42 ` Pandey, Radhey Shyam
2026-07-20 7:43 ` sashiko-bot [this message]
2026-07-20 15:42 ` Frank Li
2026-07-20 7:35 ` [PATCH v2 2/2] i3c: master: dw: Drop redundant core reset name Shubham Patil
2026-07-20 7:41 ` Pandey, Radhey Shyam
2026-07-20 7:45 ` sashiko-bot
2026-07-20 15:43 ` Frank Li
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=20260720074328.1F18B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shubhamsanjay.patil@amd.com \
/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