From: sashiko-bot@kernel.org
To: Frank.Li@oss.nxp.com
Cc: robh@kernel.org, devicetree@vger.kernel.org, Frank.Li@kernel.org,
imx@lists.linux.dev, dri-devel@lists.freedesktop.org,
conor+dt@kernel.org
Subject: Re: [PATCH v2 2/4] dt-bindings: soc: imx-iomuxc-gpr: allow bridge@18 as child node
Date: Sat, 18 Jul 2026 14:57:30 +0000 [thread overview]
Message-ID: <20260718145730.8D5831F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260718-arm_dts_ldb-v2-2-f5669571aa2b@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing `ranges` property in `fsl,imx-iomuxc-gpr` schema will cause kernel WARN_ON at boot.
--
--- Patch [2]: [PATCH v2 2/4] dt-bindings: soc: imx-iomuxc-gpr: allow bridge@18 as child node ---
commit 5e999c2b583f7149956f10a90d92e24192451d5a
Author: Frank Li <Frank.Li@nxp.com>
dt-bindings: soc: imx-iomuxc-gpr: allow bridge@18 as child node
The legacy i.MX6SX SoC imx-iomuxc-gpr contains one LDB_CTRL register.
This patch updates the dt-bindings to allow the LVDS Display Bridge (LDB)
child node under imx-iomuxc-gpr to resolve CHECK_DTBS warnings.
> diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
> index 721a67e84c137..1879638918bab 100644
> --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
> +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
> @@ -47,10 +47,21 @@ properties:
> reg:
> maxItems: 1
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
[Severity: High]
Will this omission of ranges cause a kernel WARN_ON at boot?
Because the syscon node includes the simple-mfd compatible, the kernel
function of_platform_default_populate() will attempt to create platform
devices for its children. For the bridge@18 child, of_device_alloc()
attempts to parse its reg property.
Since the parent lacks a ranges property, of_translate_address() fails and
returns OF_BAD_ADDR. This causes of_address_to_resource() to return
-EINVAL, which is passed directly to a WARN_ON() in of_device_alloc().
Because additionalProperties is set to false in this schema, users are
actively prevented from adding a valid ranges property to their device trees
to fix this.
Should the ranges property be added to this schema and explicitly permitted
so that device trees can provide the required address translation mapping?
[ ... ]
> @@ -87,4 +110,39 @@ examples:
> };
> };
>
> + - |
> + #include <dt-bindings/clock/imx6sx-clock.h>
> +
> + syscon@20e4000 {
> + compatible = "fsl,imx6sx-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd";
> + reg = <0x020e4000 0x4000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
[Severity: High]
Does this example also need a ranges property?
Without it, this example demonstrates an invalid configuration that will
trigger the boot warning described above when the device tree is processed.
> + bridge@18 {
> + compatible = "fsl,imx6sx-ldb";
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-arm_dts_ldb-v2-0-f5669571aa2b@nxp.com?part=2
next prev parent reply other threads:[~2026-07-18 14:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 14:45 [PATCH v2 0/4] ARM: dts: imx: fix ldb related CHECK_DTBS warnings Frank.Li
2026-07-18 14:45 ` [PATCH v2 1/4] dt-bindings: display: bridge: ldb: allow a single reg for fsl,imx6sx-ldb Frank.Li
2026-07-18 14:45 ` [PATCH v2 2/4] dt-bindings: soc: imx-iomuxc-gpr: allow bridge@18 as child node Frank.Li
2026-07-18 14:57 ` sashiko-bot [this message]
2026-07-18 14:45 ` [PATCH v2 3/4] dt-bindings: display: lcdif: Allow display0 child node for i.MX6UL Frank.Li
2026-07-18 14:57 ` sashiko-bot
2026-07-18 14:45 ` [PATCH v2 4/4] ARM: dts: imx6ul-tx6ul: rename disp0 to display0 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=20260718145730.8D5831F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=Frank.Li@oss.nxp.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=imx@lists.linux.dev \
--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