Devicetree
 help / color / mirror / Atom feed
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

  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