[PATCH 3/3] arm64: dts: amlogic: add support for Orbbec Zora P1

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Hardware pin multiplexing conflict on GPIOX_16 between the SDIO power sequence reset and the 32kHz PWM clock.
- [Low] The new DTB entry in the Makefile is inserted out of alphabetical order.
--

--- Patch [3]: [PATCH 3/3] arm64: dts: amlogic: add support for Orbbec Zora P1 ---
commit b7b88d4be9916c5079a86c04ae237d1db4d39b9b
Author: Alberto Robazza <robazza.alberto at proton.me>

arm64: dts: amlogic: add support for Orbbec Zora P1

This patch adds device tree support for the Orbbec Zora P1 board, an A311D
(Meson G12B) based board. It builds upon the ODROID-N2 device tree, adding
specific configurations for the AP6256 Wi-Fi/Bluetooth module and modifying
the LED settings.

> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> index 57bc440fa55cc..95e9071e0885c 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -36,6 +36,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-go-ultra.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2-plus.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2l.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-g12b-zora-p1.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-radxa-zero2.dtb

[Severity: Low]
Is this inserted out of alphabetical order? The list appears to be sorted
alphabetically, so should "meson-g12b-zora-p1.dtb" be placed at the end of
the meson-g12b block?

>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-s922x-bananapi-m2s.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-s922x-khadas-vim3.dtb

[ ... ]

> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-zora-p1.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-zora-p1.dts
> new file mode 100644
> index 0000000000000..fe20d39a82072
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-zora-p1.dts
> @@ -0,0 +1,103 @@

[ ... ]

> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		reset-gpios = <&gpio GPIOX_16 GPIO_ACTIVE_LOW>;
> +		clocks = <&wifi32k>;
> +		clock-names = "ext_clock";
> +	};

[ ... ]

> +&pwm_ef {
> +	status = "okay";
> +	pinctrl-0 = <&pwm_e_pins>;

[Severity: High]
Will this cause a pin multiplexing conflict?

The sdio_pwrseq node requests GPIOX_16 as a standard GPIO for reset-gpios,
but the pwm_ef node claims pwm_e_pins, which strictly multiplexes the exact
same GPIOX_16 pin for hardware PWM. 

When the second driver attempts to request the pin during boot, won't it
receive a -EBUSY error and fail to probe, breaking the Wi-Fi functionality?

> +	pinctrl-names = "default";
> +};

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