Re: [PATCH v7 5/7] ARM: dts: stm32: Add boot phase tags for STMicroelectronics mp13 boards

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing Parent Boot Phase Tags
- [High] Missing Supplier Boot Phase Tags
- [High] Unfulfilled Commit Message Claim
--

commit 7c0b7128d099d18d1bcdd89ea128ab291f4eeb89
Author: Patrice Chotard <patrice.chotard@foss.st.com>

ARM: dts: stm32: Add boot phase tags for STMicroelectronics mp13 boards

This commit adds bootph-all and bootph-pre-ram flags to various device
tree nodes for STMicroelectronics mp13 boards. The stated goal is to ensure
these nodes are present in all boot stages to support SD boot.

> To ensure SD boot, timer, gpio, syscfg, clock and uart nodes need to be
> present in all boot stages, so add missing bootph-all phase flag
> to these nodes to support SD boot.

[Severity: High]
The commit message mentions adding the bootph-all flag to timer nodes to
support SD boot, but no timer nodes appear to be modified in this patch.

Does this patch miss the required timer updates, or is the commit message
inaccurate?

Without the timer node in the early boot device tree, could system timing
functions and SD boot break?

> diff --git a/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts b/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts
> index 70d85af467353..06b5b68e5f784 100644
> --- a/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts
> +++ b/arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dts
[ ... ]
> @@ -436,6 +455,7 @@ connector {
>  
>  /* LDO2 is expansion connector 3V3 supply on STM32MP13xx DHCOR DHSBC rev.200 */
>  &vdd_ldo2 {
> +	bootph-all;
>  	regulator-always-on;
>  	regulator-boot-on;

[Severity: High]
Will this bootph-all tag, as well as the ones added to child regulators
like vdd_sd, vdd, vddcpu, vddcore, vdd_ddr, and vref_ddr, be effective
during early boot?

Under U-Boot's fdtgrep reduction rules, while parents of tagged nodes are
structurally retained, their properties (including the compatible string)
are stripped unless explicitly tagged. Without a compatible string, U-Boot's
Driver Model will fail to bind drivers for the PMIC and I2C controller.

Do the parent nodes (e.g., the I2C controller and PMIC) also need the
bootph-all tag to ensure these regulators are probed in early boot?

> diff --git a/arch/arm/boot/dts/st/stm32mp135f-dk.dts b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
> index 6022e73f58afd..43b8a7eed01b9 100644
> --- a/arch/arm/boot/dts/st/stm32mp135f-dk.dts
> +++ b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
[ ... ]
> @@ -448,9 +518,24 @@ &sdmmc1 {
>  	st,neg-edge;
>  	bus-width = <4>;
>  	vmmc-supply = <&scmi_vdd_sd>;
> +	bootph-pre-ram;
>  	status = "okay";
>  };

[Severity: High]
Since sdmmc1 is tagged with bootph-pre-ram, does its vmmc-supply
(&scmi_vdd_sd) also need a corresponding boot phase tag?

If neither the scmi_vdd_sd node nor its parent scmi_regu are given a
bootph-pre-ram or bootph-all tag, fdtgrep will strip the target node
from the early boot device tree.

Could this result in a dangling phandle reference for vmmc-supply
that prevents the MMC driver from resolving its power supply during
early boot?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-upstream_uboot_properties-v7-0-e17cd424d5db@foss.st.com?part=5