From: sashiko-bot@kernel.org
To: "Yu-Chun Lin" <eleanor.lin@realtek.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v5 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
Date: Thu, 02 Jul 2026 09:07:47 +0000 [thread overview]
Message-ID: <20260702090748.2958F1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260702090115.2564318-5-eleanor.lin@realtek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Device Tree mapping conflict where two distinct GPIO controllers claim the exact same pins from the `isom_pinctrl` controller.
--
commit ca40dcb33ea07a0408e101ec08ff651fed48479b
Author: Yu-Chun Lin <eleanor.lin@realtek.com>
arm64: dts: realtek: Add GPIO support for RTD1625
This commit adds the GPIO nodes for the Realtek RTD1625 SoC.
It configures multiple GPIO controllers and establishes their
pin controller mapping ranges.
> diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
> index 8d4293cd4c036..228b82dfdb7ac 100644
> --- a/arch/arm64/boot/dts/realtek/kent.dtsi
> +++ b/arch/arm64/boot/dts/realtek/kent.dtsi
> @@ -151,6 +151,37 @@ uart0: serial@7800 {
> status = "disabled";
> };
>
> + gpio: gpio@31000 {
> + compatible = "realtek,rtd1625-iso-gpio";
> + reg = <0x31000 0x398>;
> + gpio-controller;
> + gpio-ranges = <&isom_pinctrl 0 0 2>,
> + <&ve4_pinctrl 2 0 6>,
> + <&iso_pinctrl 8 0 4>,
[ ... ]
> + <&iso_pinctrl 26 4 2>,
> + <&isom_pinctrl 28 2 2>,
[ ... ]
> + iso_m_gpio: gpio@89100 {
> + compatible = "realtek,rtd1625-isom-gpio";
> + reg = <0x89100 0x30>;
> + gpio-controller;
> + gpio-ranges = <&isom_pinctrl 0 0 4>;
[Severity: Medium]
Is it intended for both the gpio@31000 and iso_m_gpio controllers to claim
the exact same pins from the isom_pinctrl controller?
Looking at gpio@31000, it maps pins 0-1 and 2-3 from isom_pinctrl. Down here
in iso_m_gpio, the gpio-ranges property identically maps isom_pinctrl pins 0,
1, 2, and 3.
Could this cause unexpected behavior in the pinctrl subsystem? Functions like
pinctrl_find_gpio_range_from_pin() strictly return the first matched range,
which might silently shadow the other controller's reverse lookups. Also, if
both controllers attempt to request the same pin via pinctrl_gpio_request(),
would the second request fail because the pin will be marked as already in-use?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702090115.2564318-1-eleanor.lin@realtek.com?part=4
prev parent reply other threads:[~2026-07-02 9:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 9:01 [PATCH v5 0/4] gpio: realtek: Add support for Realtek DHC RTD1625 Yu-Chun Lin
2026-07-02 9:01 ` [PATCH v5 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio Yu-Chun Lin
2026-07-02 9:01 ` [PATCH v5 2/4] gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig Yu-Chun Lin
2026-07-02 9:01 ` [PATCH v5 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC Yu-Chun Lin
2026-07-02 9:16 ` sashiko-bot
2026-07-02 9:01 ` [PATCH v5 4/4] arm64: dts: realtek: Add GPIO support for RTD1625 Yu-Chun Lin
2026-07-02 9:07 ` sashiko-bot [this message]
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=20260702090748.2958F1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=eleanor.lin@realtek.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.