Re: [PATCH 1/6] riscv: dts: spacemit: k1-bananapi-f3: fix maximum CPU core voltage

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Incomplete fix leaves other K1 boards vulnerable to permanent CPU damage due to dangerous regulator limits.
- [High] buck2 is orphaned from the CPU scaling topology, risking undervoltage crashes or hardware damage.
--

--- Patch [1]: [PATCH 1/6] riscv: dts: spacemit: k1-bananapi-f3: fix maximum CPU core voltage ---
commit 7fc7f69c1396ecd57da9622a68f4d3d15ff81423
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Wed Jul 29 15:02:18 2026 +0000

riscv: dts: spacemit: k1-bananapi-f3: fix maximum CPU core voltage

This patch lowers the maximum CPU core voltage on the Banana Pi BPI-F3 from
3.45V to 1.050V. This prevents potential permanent CPU damage that could
occur if a bug or privileged user requests a voltage above the safe limit.

Link: https://sashiko.dev/#/message/20260728211020.1248676-2-aurelien%40aurel32.net

> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> index e2961b7e0a3eb..58035d886bf67 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> @@ -237,14 +237,14 @@ pmic@41 {
>  		regulators {
>  			buck1_0v9: buck1 {
>  				regulator-min-microvolt = <500000>;
> -				regulator-max-microvolt = <3450000>;
> +				regulator-max-microvolt = <1050000>;

[Severity: Critical]
This is a pre-existing issue, but since this patch correctly identifies that
setting regulator-max-microvolt to 3.45V for the K1 CPU core regulators
can cause permanent physical damage, should this fix also be applied to
the other boards using the same K1 SoC?

Looking at the other device trees like k1-milkv-jupiter.dts and
k1-orangepi-rv2.dts, they still permit 3.45V on the buck1 and buck2 rails:

arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts:
    buck1 {
        regulator-max-microvolt = <3450000>;

arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts:
    buck1 {
        regulator-max-microvolt = <3450000>;

Could this incomplete fix leave these other boards vulnerable to the same
hardware damage from an OPP misconfiguration or privileged userspace request?

>  				regulator-ramp-delay = <5000>;
>  				regulator-always-on;
>  			};
>  
>  			buck2 {
>  				regulator-min-microvolt = <500000>;
> -				regulator-max-microvolt = <3450000>;
> +				regulator-max-microvolt = <1050000>;

[Severity: High]
This is a pre-existing issue, but since this commit confirms both buck1 and
buck2 supply the CPU core voltage, does the current CPU scaling topology
properly manage buck2?

In k1-bananapi-f3.dts, all eight CPUs currently point to buck1:

    cpu_4: cpu@4 {
        ...
        cpu-supply = <&buck1_0v9>;

If buck2 powers cluster 1, will scaling cluster 1 erroneously scale buck1
instead, leaving buck2 at a low boot voltage and causing cluster 1 to crash?

Alternatively, if buck1 and buck2 are physically tied together to share the
load, would leaving buck2 unmanaged while scaling buck1 cause severe
cross-conduction current between the regulators?

>  				regulator-ramp-delay = <5000>;
>  				regulator-always-on;
>  			};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729150722.1598630-1-aurelien@aurel32.net?part=1