Re: [PATCH v1 11/11] ARM: sunxi: add B288 and the PocketBook Verse board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] arm: sunxi: uart0 console missing pinctrl configuration
- [Medium] arm: sunxi: missing enable-method and cpucfg node for Cortex-A7 SMP bringup
--

commit fe74da2c07014471bb495768fef663601319d9c4
Author: Pablo Mazzini <pmazzini@gmail.com>

ARM: sunxi: add B288 and the PocketBook Verse board

This commit adds device tree support for the Allwinner B288 SoC and the
PocketBook Verse (PB629) board. It explicitly notes that
arm,cpu-registers-not-fw-configured is required due to the boot0 bootloader
failing to set virtual timer registers.

> diff --git a/arch/arm/boot/dts/allwinner/sun8i-b288-pocketbook-verse.dts b/arch/arm/boot/dts/allwinner/sun8i-b288-pocketbook-verse.dts
> new file mode 100644
> index 0000000000000..91c89d5a097e6
> --- /dev/null
> +++ b/arch/arm/boot/dts/allwinner/sun8i-b288-pocketbook-verse.dts
[ ... ]
> +&uart0 {
> +	status = "okay";
> +};

[Severity: Medium]
Does this node need to reference the uart0_pb_pins pinctrl configuration?

The base sun8i-b288.dtsi defines uart0_pb_pins specifically to configure the 
pins for uart0, and this board file designates uart0 as the console UART.

Neither file assigns this pinctrl configuration to the uart0 node (for example,
by adding pinctrl-names = "default"; pinctrl-0 = <&uart0_pb_pins>;).

Relying on the bootloader (like boot0 or U-Boot) to implicitly leave the pins
correctly multiplexed can be brittle, and might cause the serial console to
break across suspend/resume cycles where the pinctrl driver may reinitialize
or power-cycle the pin banks.

[ ... ]
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-b288.dtsi b/arch/arm/boot/dts/allwinner/sun8i-b288.dtsi
> new file mode 100644
> index 0000000000000..58668d5813680
> --- /dev/null
> +++ b/arch/arm/boot/dts/allwinner/sun8i-b288.dtsi
[ ... ]
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu@0 {
> +			compatible = "arm,cortex-a7";
> +			device_type = "cpu";
> +			reg = <0>;
> +			clocks = <&ccu CLK_CPUX>;
> +			clock-names = "cpu";
> +		};
> +
> +		cpu1: cpu@1 {
> +			compatible = "arm,cortex-a7";
> +			device_type = "cpu";
> +			reg = <1>;
> +			clocks = <&ccu CLK_CPUX>;
> +			clock-names = "cpu";
> +		};
> +	};

[Severity: Medium]
Will the kernel fail to bring up CPU1 without an enable-method and cpucfg node?

The commit message explicitly states the platform relies on Allwinner's
proprietary boot0 bootloader, which implies it does not use TF-A and thus lacks
PSCI firmware support.

On ARMv7, without PSCI, the kernel requires an enable-method property
(e.g., enable-method = "allwinner,sun8i-a23") on the CPU nodes to route to the
correct secondary core bringup routines in mach-sunxi/platsmp.c.

Additionally, legacy Allwinner SMP bringup requires a cpucfg hardware node to
assert resets and power on the secondary cores.

Because both the enable-method property and the cpucfg node are omitted from
this DT, will this degrade the dual-core SoC to a single-core system?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923201701.43391-1-pmazzini@gmail.com?part=11