[PATCH v3 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
- [Medium] Logic Error / Device Tree Overrides (Failed LED Rename)
--

--- Patch [3]: [PATCH v3 3/3] arm64: dts: amlogic: add support for Orbbec Zora P1 ---
commit a86fe3a994f708a5d2fc9e72b435f89e92f8a493
Author: Alberto Robazza <robazzalberto at gmail.com>

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

The Orbbec Zora P1 is an A311D (Meson G12B) board with 2/4 GiB DDR4,
an Ampak AP6256 combo module (Broadcom BCM43456 Wi-Fi over SDIO and
BCM4345C5 Bluetooth over UART_A).

> 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..d003582fd9e95
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-zora-p1.dts

[ ... ]

> +	leds {
> +		/* Status led on Zora is actually green, same pin as N2, but reversed polarity */
> +		led-blue {
> +			function = LED_FUNCTION_STATUS;
> +			color = <LED_COLOR_ID_GREEN>;
> +			gpios = <&gpio_ao GPIOAO_11 GPIO_ACTIVE_LOW>;
> +		};

[Severity: Medium]
Will this still result in the LED being named n2:blue in sysfs?

Since this node inherits from meson-g12b-odroid-n2.dtsi, it looks like the
original label property might still be present. Because led_compose_name()
in drivers/leds/led-core.c prioritizes the label property over function and
color, the inherited label may bypass these new properties.

Would we need to add /delete-property/ label; here to ensure the new color
is properly reflected in the sysfs name?

[ ... ]

> +	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>;
> +	pinctrl-names = "default";
> +};

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

It appears GPIOX_16 is requested as a static GPIO reset line for
sdio_pwrseq above, but pwm_ef also requests pwm_e_pins, which maps to the
exact same GPIOX_16 pin for the 32kHz clock output.

Could this cause the pinctrl subsystem to reject the secondary request with
-EBUSY during boot, or potentially force the pin into conflicting
electrical states?

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