From: sashiko-bot@kernel.org
To: "Jisheng Zhang" <jszhang@kernel.org>
Cc: linux-i3c@lists.infradead.org, robh@kernel.org,
mfd@lists.linux.dev, Frank.Li@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-clk@vger.kernel.org, lee@kernel.org
Subject: Re: [PATCH 20/20] arm64: dts: synaptics: Add Synaptics SL261X SoC and RDK board
Date: Tue, 29 Sep 2026 06:52:09 +0000 [thread overview]
Message-ID: <20260929065210.5C08E1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260929061417.20733-21-jszhang@kernel.org>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] dt: cpu0-supply is deprecated and breaks scaling on secondary cores
- [Low] dt: missing root compatible string in sl2619.dtsi
- [Low] dt: schema violation by nesting l2-cache inside cpu node
- [Low] dt: missing whitespace before opening brace in cpu-wrap node
--
commit 58d4f39b5f4d2e3ef035e2e85d0944a8e6331b18
Author: Jisheng Zhang <jszhang@kernel.org>
arm64: dts: synaptics: Add Synaptics SL261X SoC and RDK board
Add dts(i) files for the Synaptics SL261X SoCs and corresponding
RDK boards.
> diff --git a/arch/arm64/boot/dts/synaptics/sl2611.dtsi b/arch/arm64/boot/dts/synaptics/sl2611.dtsi
> new file mode 100644
> index 0000000000000..1d640ffe4c4b2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/synaptics/sl2611.dtsi
[ ... ]
> @@ -0,0 +1,490 @@
[ ... ]
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x0>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_SLEEP_0>;
> + i-cache-size = <32768>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <128>;
> + d-cache-size = <32768>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> +
> + L2_0: l2-cache {
> + compatible = "cache";
[Severity: Low]
Could this violate the standard Device Tree schema for CPU topology? The
l2-cache nodes shouldn't be instantiated as children of the cpu nodes. Can
they be moved as siblings under the /cpus node to avoid dtbs_check validation
errors?
[ ... ]
> + chip: chip-control@f7e10000 {
> + compatible = "syna,sl261x-chip-control", "syscon", "simple-mfd";
> + reg = <0xf7e10000 0x10000>;
> +
> + clk: clock {
> + compatible = "syna,sl261x-soc-clk";
> + #clock-cells = <1>;
> + clocks = <&osc>;
> + };
> +
> + pinctrl: pin-controller {
> + compatible = "syna,sl261x-soc-pinctrl";
> + };
> +
> + rst: reset {
> + compatible = "syna,sl261x-soc-reset";
> + #reset-cells = <1>;
> + };
> + };
> +
> + cpu_wrap: cpu-wrap@f7e30000{
[Severity: Low]
Should there be a space before the opening brace for cpu-wrap@f7e30000? While
the Device Tree Compiler parses this successfully, it goes against standard
formatting conventions.
> + compatible = "syna,sl261x-cpu-wrp", "syscon", "simple-mfd";
> + reg = <0xf7e30000 0x4000>;
[ ... ]
> diff --git a/arch/arm64/boot/dts/synaptics/sl2615.dtsi b/arch/arm64/boot/dts/synaptics/sl2615.dtsi
> new file mode 100644
> index 0000000000000..11b1fe316aa6d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/synaptics/sl2615.dtsi
[ ... ]
> @@ -0,0 +1,46 @@
[ ... ]
> + cpus {
> + cpu1: cpu@100 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_SLEEP_0>;
> + i-cache-size = <32768>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <128>;
> + d-cache-size = <32768>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_1>;
> +
> + L2_1: l2-cache {
> + compatible = "cache";
[Severity: Low]
Similar to sl2611.dtsi, does this violate the standard Device Tree schema for
CPU topology? The l2-cache node is instantiated as a child of the cpu node
here, and it should likely be moved to be a sibling under the /cpus node.
[ ... ]
> diff --git a/arch/arm64/boot/dts/synaptics/sl2619.dtsi b/arch/arm64/boot/dts/synaptics/sl2619.dtsi
> new file mode 100644
> index 0000000000000..96bd58bbed3e1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/synaptics/sl2619.dtsi
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2025 Synaptics Incorporated
> + *
> + * Author: Jisheng Zhang <jszhang@kernel.org>
> + */
> +
> +#include "sl2613.dtsi"
> +
> +/ {
[Severity: Low]
Would it make sense to include the root compatible string here? sl2619.dtsi
includes sl2613.dtsi but doesn't override the root compatible string to
syna,sl2619 (unlike sl2615.dtsi and sl2617.dtsi). Even though sl2619-rdk.dts
overrides it, this omission seems logically inconsistent.
> + cpus {
> + cpu1: cpu@100 {
> + compatible = "arm,cortex-a55";
[ ... ]
> diff --git a/arch/arm64/boot/dts/synaptics/sl261x-rdk-common.dtsi b/arch/arm64/boot/dts/synaptics/sl261x-rdk-common.dtsi
> new file mode 100644
> index 0000000000000..78a9b28fdf99e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/synaptics/sl261x-rdk-common.dtsi
[ ... ]
> @@ -0,0 +1,135 @@
[ ... ]
> + cpus {
> + cpu@0 {
> + cpu0-supply = <&vcore>;
[Severity: Medium]
Will this break voltage scaling for secondary cores? cpu0-supply is deprecated
in the cpus.yaml devicetree bindings in favor of cpu-supply.
Also, since this is hardcoded strictly under cpu@0 in the common board dtsi,
any secondary cores introduced by multi-core SoCs (like cpu1 in SL2615) will
inherit no regulator supply. Could this cause the cpufreq driver to fail to
configure voltage scaling for secondary cores?
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260929061417.20733-1-jszhang@kernel.org?part=20
next prev parent reply other threads:[~2026-09-29 6:52 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 6:13 [PATCH 00/20] arm64: add Synaptics SL261X SoCs and RDK boards Jisheng Zhang
2026-09-29 6:13 ` [PATCH 01/20] dt-bindings: serial: snps-dw-apb-uart: Add Synaptics sl261x uart Jisheng Zhang
2026-09-29 6:44 ` sashiko-bot
2026-09-29 6:13 ` [PATCH 02/20] dt-bindings: i2c: dw: Add Synaptics sl261x i2c Jisheng Zhang
2026-09-29 6:39 ` sashiko-bot
2026-09-29 20:57 ` Andi Shyti
2026-09-29 6:14 ` [PATCH 03/20] spi: dt-bindings: snps,dw-apb-ssi: Add Synaptics sl261x spi Jisheng Zhang
2026-09-29 6:39 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 04/20] dt-bindings: i3c: dw: support up to two reset lines Jisheng Zhang
2026-09-29 6:43 ` sashiko-bot
2026-09-29 19:40 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 05/20] i3c: dw: switch to array-based exclusive reset control Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 15:01 ` Frank Li
2026-09-29 6:14 ` [PATCH 06/20] dt-bindings: i3c: Add Synaptics sl261x i3c Jisheng Zhang
2026-09-29 6:41 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 07/20] arm64: kconfig: let ARCH_BERLIN cover Synaptics arm64 SoCs Jisheng Zhang
2026-09-29 6:40 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 08/20] dt-bindings: reset: add Synaptics SL261X SoCs Jisheng Zhang
2026-09-29 6:42 ` sashiko-bot
2026-09-29 19:44 ` Conor Dooley
2026-09-30 15:15 ` Jisheng Zhang
2026-09-30 16:49 ` Conor Dooley
2026-10-02 15:35 ` Jisheng Zhang
2026-10-05 10:50 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 09/20] reset: add Synaptics SL261x reset support Jisheng Zhang
2026-09-29 6:47 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 10/20] pinctrl: berlin: use u16 instead of u8 for the offset Jisheng Zhang
2026-09-29 6:42 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 11/20] pinctrl: berlin: enable module build support Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 12/20] pinctrl: berlin: add optional pinconf support Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 13/20] dt-bindings: pinctrl: berlin: Support Synaptics SL261X SoCs Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 14/20] pinctrl: berlin: support " Jisheng Zhang
2026-09-29 6:47 ` sashiko-bot
2026-09-29 15:34 ` Uwe Kleine-König
2026-09-29 6:14 ` [PATCH 15/20] dt-bindings: clock: add Synaptics SL261X clock Jisheng Zhang
2026-09-29 6:44 ` sashiko-bot
2026-09-29 19:46 ` Conor Dooley
2026-09-29 20:49 ` Rob Herring (Arm)
2026-09-30 14:18 ` Jisheng Zhang
2026-09-29 6:14 ` [PATCH 16/20] clk: berlin: add Synaptics SL261X SoC clocks and plls Jisheng Zhang
2026-09-29 6:50 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 17/20] dt-bindings: mfd: Add Synaptics SL261x global block binding Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 19:55 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 18/20] regulator: dt-bindings: sy8827n: support standard properties Jisheng Zhang
2026-09-29 6:40 ` sashiko-bot
2026-09-29 19:40 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 19/20] dt-bindings: arm: berlin: Add Synaptics SL261X SoC and RDK board Jisheng Zhang
2026-09-29 6:53 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 20/20] arm64: dts: synaptics: " Jisheng Zhang
2026-09-29 6:52 ` sashiko-bot [this message]
2026-09-29 19:38 ` [PATCH 00/20] arm64: add Synaptics SL261X SoCs and RDK boards Conor Dooley
2026-09-30 14:15 ` Jisheng Zhang
2026-09-30 14:32 ` Jisheng Zhang
2026-09-30 16:35 ` Conor Dooley
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=20260929065210.5C08E1F000FF@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=jszhang@kernel.org \
--cc=lee@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=mfd@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