Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Board-level regulator constraints are dangerously overly permissive, reflecting PMIC hardware limits instead of the board's electrical design.
- [Medium] Mismatch between the commit message and device tree configuration regarding the PMIC model.
- [Medium] Missing DT bindings for new compatible strings and vendor prefix.
- [Low] Typo in the new device tree include filename.
--

commit 995a0c0548d7cc620abeca1987efff325083911e
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>

arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

This commit adds initial support for the Baijie Helper A133 board and its
core SBC. It enables UART, PMU, eMMC, USB, and Ethernet peripherals.

> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
> 
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC

The commit message mentions an AXP707 PMIC, but the device tree configures
an x-powers,axp803 PMIC. Is AXP707 a typo in the message, or does the
hardware actually use an AXP707?

Also, are the new compatible strings baijie,helper-a133 and
baijie,helper-a133-core, along with the baijie vendor prefix, included in a
separate dt-bindings patch? I don't see them documented here, which might
cause schema validation failures.

> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> new file mode 100644
> index 0000000000000..65b094f30bf5b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi

This isn't a bug, but there is a typo in the filename. The vendor prefix is
baijie but the file is named baije.

[ ... ]

> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1600000>;
> +	regulator-max-microvolt = <3400000>;
> +	regulator-name = "vcc-3v3";
> +};

Does this overly permissive voltage range match the physical board design?

Since this rail is named vcc-3v3 and shared by multiple 3.3V IO banks,
allowing the voltage to drop to 1.6V could undervolt other components if a
driver dynamically requests a lower voltage. 

Could the constraints be tightened to match the safe operating limits of
the board layout, rather than the PMIC hardware capabilities?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510201644.4143710-1-alexander.sverdlin@gmail.com?part=3