Re: [PATCH v1 3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The PTN5150 USB Type-C controller's interrupt is incorrectly configured as active-high (`IRQ_TYPE_LEVEL_HIGH`), which will cause an interrupt storm.
- [Medium] The SPI chip select GPIO is configured as active-high by mistake, breaking standard SPI devices.
--

commit 640b696a79494ebf66cec9e81eee16f6d3d56651
Author: Stefano Radaelli <stefano.r@variscite.com>
Date:   Tue Jun 30 09:46:56 2026 +0000

arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

Add device tree support for the Variscite Symphony carrier board with
the VAR-SOM-MX8 QuadMax system on module.

Link: https://variscite.com/carrier-boards/symphony-board/

> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts

[ ... ]

> +&i2c1 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c1>;
> +	status = "okay";
> +
> +	pca9534: gpio@20 {
> +		compatible = "nxp,pca9534";
> +		reg = <0x20>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pca9534>;
> +		interrupt-parent = <&lsio_gpio1>;
> +		interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
> +	};
> +
> +	/* USB Type-C Controller */
> +	typec_ptn5150: typec@3d {
> +		compatible = "nxp,ptn5150";
> +		reg = <0x3d>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_ptn5150>;
> +		interrupt-parent = <&lsio_gpio3>;
> +		interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Will this active-high interrupt polarity cause an interrupt storm at boot?

The PTN5150 hardware pin INTB is open-drain and active-low, which means it
idles high. By configuring the interrupt trigger as IRQ_TYPE_LEVEL_HIGH,
the kernel expects an active-high signal. Since the idle state is high, the
interrupt will fire continuously as long as it is idle.

Other Variscite Symphony board DTs correctly configure this identical
component's interrupt as IRQ_TYPE_LEVEL_LOW.

> +
> +		port {
> +			typec_dr_sw: endpoint {
> +				remote-endpoint = <&usb3_drd_sw>;
> +			};
> +		};
> +	};
> +};

[ ... ]

> +&lpspi1 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_lpspi1>;
> +	cs-gpios = <&lsio_gpio3 24 0>;

[Severity: Medium]
Does this active-high chip select polarity break standard SPI devices
attached to the bus?

Standard SPI chip selects are active-low, expecting the line to go low to
select the peripheral. By setting the cs-gpios polarity to 0
(GPIO_ACTIVE_HIGH), the SPI subsystem will drive the pin logically true
(physically HIGH) when asserting CS, and physically LOW when idle.

This means an attached standard SPI device will be continuously selected
when idle, leading to bus contention. While gpiolib contains a legacy
quirk to rewrite this if a statically defined active-low child node is
present at parse time, this quirk will not protect dynamically added
devices.

Should this be updated to use GPIO_ACTIVE_LOW to match standard SPI
behavior?

> +	status = "okay";
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782812572.git.stefano.r@variscite.com?part=3