From: sashiko-bot@kernel.org
To: "Hung-Chun Tseng" <alan.tseng.cs@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 2/2] riscv: dts: spacemit: mark K1 board boot devices bootph-pre-ram
Date: Tue, 13 Oct 2026 00:08:28 +0000 [thread overview]
Message-ID: <sashiko-outbox-168780@kernel.org> (raw)
In-Reply-To: <20261012235624.77993-3-alan.tseng.cs@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: missing bootph-pre-ram on pinctrl and regulator dependencies for SPL
--
commit 76ae02e32445137eb75156ac64fdd5ee85cb4ef0
Author: Hung-Chun Tseng <alan.tseng.cs@gmail.com>
riscv: dts: spacemit: mark K1 board boot devices bootph-pre-ram
This patch adds the bootph-pre-ram property to I2C buses, board EEPROMs, PMICs,
and QSPI flashes on various SpacemiT K1 boards. These additions enable
U-Boot's SPL to access the devices during the early boot phase before
DRAM training.
> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-cm6.dtsi b/arch/riscv/boot/dts/spacemit/k1-bananapi-cm6.dtsi
> index 81c40df2a3663..6269d2ba78ed0 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-cm6.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-cm6.dtsi
> @@ -93,6 +95,7 @@ serial-number {
> };
>
> &i2c8 {
> + bootph-pre-ram;
> pinctrl-names = "default";
> pinctrl-0 = <&i2c8_cfg>;
> status = "okay";
[Severity: Medium]
Will this I2C pinmux setup fail in the SPL?
The I2C bus is marked for SPL, but the pin configuration node i2c8_cfg in
k1-pinctrl.dtsi and the base pinctrl controller pinctrl@d401e000 in k1.dtsi
both lack the bootph-pre-ram property.
U-Boot's fdtgrep will strip these unmarked nodes from the SPL device tree,
which will prevent the I2C pins from being multiplexed correctly.
> @@ -100,6 +103,7 @@ &i2c8 {
> pmic@41 {
> compatible = "spacemit,p1";
> reg = <0x41>;
> + bootph-pre-ram;
> interrupts = <64>;
> vin1-supply = <®_vcc_4v>;
> vin2-supply = <®_vcc_4v>;
[Severity: Medium]
Will this PMIC probe fail in the SPL phase?
The PMIC relies on the reg_vcc_4v fixed regulator as its input supply, but
the reg_vcc_4v node was not marked with bootph-pre-ram.
Without this property, the fixed regulator will be excluded from the SPL
device tree, leading to dangling phandles and early boot probe failures for
the PMIC.
> diff --git a/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts b/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts
> index 635e95aad14a5..406b7ca163db8 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts
[ ... ]
> @@ -386,6 +393,7 @@ &qspi {
> flash@0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
> + bootph-pre-ram;
> spi-max-frequency = <26500000>;
> spi-rx-bus-width = <4>;
> spi-tx-bus-width = <4>;
[Severity: Medium]
Will this flash fail to operate during early boot?
The flash@0 node uses buck4_3v3 as its vcc-supply. While buck1 and buck3 were
marked with bootph-pre-ram in this patch, buck4_3v3 was omitted.
The missing property on buck4_3v3 will cause the supply node to be stripped
from the SPL device tree, breaking flash access before RAM is initialized.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012235624.77993-1-alan.tseng.cs@gmail.com?part=2
prev parent reply other threads:[~2026-10-13 0:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 23:56 [PATCH 0/2] riscv: dts: spacemit: mark K1 boot nodes bootph-pre-ram Hung-Chun Tseng
2026-10-12 23:56 ` Hung-Chun Tseng
2026-10-12 23:56 ` [PATCH 1/2] riscv: dts: spacemit: k1: mark boot-critical SoC " Hung-Chun Tseng
2026-10-12 23:56 ` Hung-Chun Tseng
2026-10-13 0:04 ` sashiko-bot
2026-10-12 23:56 ` [PATCH 2/2] riscv: dts: spacemit: mark K1 board boot devices bootph-pre-ram Hung-Chun Tseng
2026-10-12 23:56 ` Hung-Chun Tseng
2026-10-13 0:08 ` 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=sashiko-outbox-168780@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alan.tseng.cs@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--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.