Re: [PATCH v2 2/4] arm64: dts: rk3399-rock-4c-plus: Use device tree bindings constants for SYR828 regulator initial mode

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The fan53555 regulator driver lacks an `of_map_mode` callback, causing the `regulator-initial-mode` device tree property to be ignored.
--

--- Patch [2]: [PATCH v2 2/4] arm64: dts: rk3399-rock-4c-plus: Use device tree bindings constants for SYR828 regulator initial mode ---
commit bd8e5b9ed62ff2e741725d000597a403df903434
Author: Victor Krawiec <victor.krawiec@arturia.com>

arm64: dts: rk3399-rock-4c-plus: Use device tree bindings constants for SYR828 regulator initial mode

This patch updates the device tree to prefer using a bindings constant
over a hardcoded value for the regulator initial mode.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
> @@ -448,7 +449,7 @@ vdd_gpu: regulator@41 {
>  		regulator-always-on;
>  		regulator-boot-on;
>  		vin-supply = <&vcc5v0_sys>;
> -		regulator-initial-mode = <1>; /* 1:force PWM 2:auto */
> +		regulator-initial-mode = <FAN53555_REGULATOR_MODE_FORCE_PWM>;

[Severity: High]
This is a pre-existing issue, but does the underlying fan53555 regulator
driver actually support mapping this property?

Looking at the driver initialization in fan53555_regulator_register(), the
regulator_desc lacks an of_map_mode callback:

drivers/regulator/fan53555.c:fan53555_regulator_register() {
    ...
	rdesc->ops = &fan53555_regulator_ops;
	rdesc->type = REGULATOR_VOLTAGE;
    ...
}

When the regulator core parses this device tree property, it requires that
callback to translate the value:

drivers/regulator/of_regulator.c:of_get_regulation_constraints() {
    ...
		if (desc && desc->of_map_mode) {
			mode = desc->of_map_mode(pval);
			if (mode == REGULATOR_MODE_INVALID)
				pr_err("%pOFn: invalid mode %u\n", np, pval);
			else
				constraints->initial_mode = mode;
		} else {
			pr_warn("%pOFn: mapping for mode %d not defined\n",
				np, pval);
		}
    ...
}

Without the callback, constraints->initial_mode is never populated, a warning
is printed, and the hardware defaults to its reset mode (Auto-PFM) instead of
the requested Forced PWM mode. Could failing to apply the Forced PWM mode lead
to hardware instability or crashes under light load conditions?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720100336.62004-1-victor.krawiec@arturia.com?part=2