Re: [PATCH 1/2] riscv: dts: spacemit: k1: mark boot-critical SoC nodes bootph-pre-ram

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt: spacemit: k1: boot media incorrectly marked bootph-pre-ram in SoC dtsi
--

commit 8f0e131a27a4e9b047773ff808813b281fae2061
Author: Hung-Chun Tseng <alan.tseng.cs@gmail.com>

riscv: dts: spacemit: k1: mark boot-critical SoC nodes bootph-pre-ram

This commit marks several K1 SoC nodes with the bootph-pre-ram tag to allow
a U-Boot SPL to use the upstream device tree directly. It adds the tag to
clocks, system controllers, UART, and boot media controllers (SD, eMMC,
and QSPI).

> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> index 3fabfd34114b2..8ca98d15a117a 100644
> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi

[ ... ]

> @@ -1085,6 +1094,7 @@ qspi: spi@d420c000 {
>  				reg = <0x0 0xd420c000 0x0 0x1000>,
>  				      <0x0 0xb8000000 0x0 0xc00000>;
>  				reg-names = "QuadSPI", "QuadSPI-memory";
> +				bootph-pre-ram;

[Severity: Low]
Does adding the bootph-pre-ram tag globally to the QSPI boot media controller
in the SoC dtsi prevent individual boards from excluding the QSPI driver from
their SPL if they don't use it for early boot?

When a board includes k1.dtsi and enables a peripheral like QSPI for OS-level
storage but does not use it as the early boot medium, this inherited tag
forces the QSPI driver and node into the SPL anyway.

This unnecessarily inflates the U-Boot SPL binary size and increases SRAM
memory pressure.

Standard devicetree practice mandates that boot media phase tags be defined
in per-board .dts files or -u-boot.dtsi overlays corresponding to the actual
boot interfaces wired and used by that specific board.

>  				clocks = <&syscon_apmu CLK_QSPI_BUS>,
>  					 <&syscon_apmu CLK_QSPI>;
>  				clock-names = "qspi_en", "qspi";

[ ... ]

> @@ -1328,6 +1338,7 @@ usb_dwc3: usb@c0a00000 {
>  			sdhci0: mmc@d4280000 {
>  				compatible = "spacemit,k1-sdhci";
>  				reg = <0x0 0xd4280000 0x0 0x200>;
> +				bootph-pre-ram;

[Severity: Low]
Could this global bootph-pre-ram tag force the SD card controller driver into
the SPL even for boards that do not use it as their early boot medium?

>  				clocks = <&syscon_apmu CLK_SDH_AXI>,
>  					 <&syscon_apmu CLK_SDH0>;
>  				clock-names = "core", "io";
> @@ -1341,6 +1352,7 @@ sdhci0: mmc@d4280000 {
>  			emmc: mmc@d4281000 {
>  				compatible = "spacemit,k1-sdhci";
>  				reg = <0x0 0xd4281000 0x0 0x200>;
> +				bootph-pre-ram;

[Severity: Low]
Does adding this tag to the eMMC controller in the SoC dtsi cause the same
issue of forcing unnecessary drivers into the SPL for boards that boot from
other media?

>  				clocks = <&syscon_apmu CLK_SDH_AXI>,
>  					 <&syscon_apmu CLK_SDH2>;
>  				clock-names = "core", "io";

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012235624.77993-1-alan.tseng.cs@gmail.com?part=1