All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Xincheng Ji" <jixincheng@ultrarisc.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 5/7] riscv: dts: ultrarisc: Add initial device tree for UltraRISC DP1000
Date: Tue, 13 Oct 2026 10:36:18 +0000	[thread overview]
Message-ID: <sashiko-outbox-169523@kernel.org> (raw)
In-Reply-To: <20261013-ultrarisc-dts-v3-5-5ff3ebb2a90d@ultrarisc.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: L2 cache nodes are incorrectly nested as children of cpu nodes
--

commit 72d6d58d85f9aab9e46d9c7167175451c2551346
Author: Jia Wang <wangjia@ultrarisc.com>

riscv: dts: ultrarisc: Add initial device tree for UltraRISC DP1000

Add the base device tree for the UltraRISC DP1000 SoC. It describes
eight CP100 CPU cores, their cache topology, and essential peripherals.

> diff --git a/arch/riscv/boot/dts/ultrarisc/dp1000.dtsi b/arch/riscv/boot/dts/ultrarisc/dp1000.dtsi
> new file mode 100644
> index 0000000000000..86d7f5533aa84
> --- /dev/null
> +++ b/arch/riscv/boot/dts/ultrarisc/dp1000.dtsi
> @@ -0,0 +1,899 @@
[ ... ]
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		timebase-frequency = <10000000>;
> +
> +		cpu0: cpu@0 {
> +			compatible = "ultrarisc,cp100", "riscv";
[ ... ]
> +			cpu0_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +
> +			l2_cache0: l2-cache {

[Severity: Medium]
Does this incorrectly nest the L2 cache nodes as children of the cpu nodes?

Standard Devicetree topologies for CPU schemas require cache nodes to be
defined as siblings under the /cpus node or globally, rather than as direct
children of the cpu nodes. Instantiating l2-cache here can cause
dt_binding_check validation failures and break generic kernel cache topology
parsers that expect the cache nodes at the root of /cpus and referenced via
the next-level-cache phandle.

Should these cache nodes be moved outside of the cpu@0 node?

> +				/*
> +				 * L2 cache:
> +				 * cache-unified, block-size 64B
> +				 * 8-way set associative, size 512KB
> +				 * per-core.
> +				 */
> +				compatible = "cache";
> +				cache-block-size = <64>;
> +				cache-level = <2>;
> +				cache-size = <0x80000>;
> +				cache-sets = <1024>;
> +				cache-unified;
> +				next-level-cache = <&cluster0_l3>;
> +			};
> +		};
[ ... ]
> +		cpu4: cpu@10 {
> +			compatible = "ultrarisc,cp100", "riscv";
[ ... ]
> +			cpu4_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +
> +			l2_cache4: l2-cache {

[Severity: Medium]
The same structural error appears to be repeated across all CPU nodes in the
cluster. Could these cache nodes be moved outside their respective cpu nodes
as well?

> +				/*
> +				 * L2 cache:
> +				 * cache-unified, block-size 64B
> +				 * 8-way set associative, size 512KB

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013-ultrarisc-dts-v3-0-5ff3ebb2a90d@ultrarisc.com?part=5

  reply	other threads:[~2026-10-13 10:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13 10:21 [PATCH v3 0/7] riscv: Add device tree support for UltraRISC DP1000 Xincheng Ji via B4 Relay
2026-10-13 10:21 ` Xincheng Ji
2026-10-13 10:21 ` Xincheng Ji via B4 Relay
2026-10-13 10:21 ` [PATCH v3 1/7] dt-bindings: vendor-prefixes: Add shenrongda Xincheng Ji via B4 Relay
2026-10-13 10:21   ` Xincheng Ji
2026-10-13 10:21   ` Xincheng Ji via B4 Relay
2026-10-13 10:21 ` [PATCH v3 2/7] dt-bindings: riscv: cpus: Add UltraRISC CP100 compatible Xincheng Ji via B4 Relay
2026-10-13 10:21   ` Xincheng Ji
2026-10-13 10:21   ` Xincheng Ji via B4 Relay
2026-10-13 10:21 ` [PATCH v3 3/7] dt-bindings: riscv: Add UltraRISC DP1000 board compatibles Xincheng Ji via B4 Relay
2026-10-13 10:21   ` Xincheng Ji
2026-10-13 10:21   ` Xincheng Ji via B4 Relay
2026-10-13 10:21 ` [PATCH v3 4/7] dt-bindings: timer: Add UltraRISC DP1000 CLINT Xincheng Ji via B4 Relay
2026-10-13 10:21   ` Xincheng Ji
2026-10-13 10:21   ` Xincheng Ji via B4 Relay
2026-10-13 10:21 ` [PATCH v3 5/7] riscv: dts: ultrarisc: Add initial device tree for UltraRISC DP1000 Xincheng Ji via B4 Relay
2026-10-13 10:21   ` Xincheng Ji
2026-10-13 10:21   ` Xincheng Ji via B4 Relay
2026-10-13 10:36   ` sashiko-bot [this message]
2026-10-13 10:21 ` [PATCH v3 6/7] riscv: dts: ultrarisc: Add Shenzhen Rongda M0 board device tree Xincheng Ji via B4 Relay
2026-10-13 10:21   ` Xincheng Ji
2026-10-13 10:21   ` Xincheng Ji via B4 Relay
2026-10-13 10:21 ` [PATCH v3 7/7] riscv: dts: ultrarisc: Add Milk-V Titan " Xincheng Ji via B4 Relay
2026-10-13 10:21   ` Xincheng Ji
2026-10-13 10:21   ` Xincheng Ji via B4 Relay
2026-10-13 10:31   ` sashiko-bot
2026-10-13 17:34     ` Conor Dooley
2026-10-13 18:08       ` Andrew Lunn

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=sashiko-outbox-169523@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jixincheng@ultrarisc.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.