[PATCH v5 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] Pin multiplexing conflict on GPIOX_16 between Wi-Fi reset and PWM clock.
- [Low] The LED node fails to override the legacy 'label' property, resulting in incorrect sysfs naming.
--

--- Patch [3]: [PATCH v5 3/3] arm64: dts: amlogic: add support for Orbbec Zora P1 ---
commit 92879b64fc9510d716492c86c79ec3e7f0eaad2f
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).
According to the original Linux dts, the board is a modded version
of the ODROID-N2, with Amlogic A311D instead of the original S922X
and WiFi and Bluetooth support.

> 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
> --- /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: Low]
Is this led-blue node missing a /delete-property/ for the label?

The device tree includes meson-g12b-odroid-n2.dtsi which defines a label
property for led-blue. When the LED subsystem parses this in
led_parse_fwnode_props(), it reads the inherited label and returns
immediately, ignoring the newly added color and function properties.

Will this cause the LED to appear as 'n2:blue' in sysfs instead of the
intended color-based name?

> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		reset-gpios = <&gpio GPIOX_16 GPIO_ACTIVE_LOW>;
> +		clocks = <&clock_32768>;
> +		clock-names = "ext_clock";
> +	};
> +
> +	clock_32768: clock-32768 {
> +		compatible = "pwm-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <32768>;
> +		pwms = <&pwm_ef 0 30518 0>;
> +	};
> +
> +	sound {
> +		model = "ZORA-P1";
> +	};
> +};
> +
> +&pwm_ef {
> +	status = "okay";
> +	pinctrl-0 = <&pwm_e_pins>;
> +	pinctrl-names = "default";
> +};

[Severity: High]
Does this pin configuration create a multiplexing conflict on GPIOX_16?

The sdio_pwrseq node requests GPIOX_16 as a standard GPIO for the reset
sequence. However, pwm_ef requests the pwm_e_pins pinctrl group. Based on
drivers/pinctrl/meson/pinctrl-meson-g12a.c, pwm_e_pins maps directly to
GPIOX_16.

Since the pinctrl subsystem prevents concurrent claims of the same pin for
different functions, will one of these initializations fail and prevent
Wi-Fi from working?

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