Re: [PATCH v4 2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect `reset-gpios` polarity on `dp_bridge` will permanently disable the device.
- [Medium] Missing `interrupts` property for the DisplayPort bridge despite hardware routing.
--

commit ec4a92e3f2baae5d65ed787df020c8a40c851231
Author: Paul Gerber <paul.gerber@tq-group.com>

arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP

This adds support for TQMa8MPQS module on MB-SMARC-2 board.

> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi

[ ... ]

> +&i2c3 {
> +	clock-frequency = <384000>;
> +	pinctrl-names = "default", "gpio";
> +	pinctrl-0 = <&pinctrl_i2c3>;
> +	pinctrl-1 = <&pinctrl_i2c3_gpio>;
> +	scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> +	sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> +	status = "okay";
> +
> +	dp_bridge: dp-bridge@f {
> +		compatible = "toshiba,tc9595", "toshiba,tc358767";
> +		reg = <0xf>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_tc9595>;
> +		clock-names = "ref";
> +		clocks = <&clk_dp>;

[Severity: Medium]
Is this node missing the interrupt properties for the Hot Plug Detect signal?

The pinctrl node pinctrl_tc9595 configures GPIO5_IO21 (DP_HPD_INT), but
without the interrupt-parent and interrupts properties here, the tc358767
driver won't be able to request the hardware IRQ.

Will this cause the driver to silently fall back to 10-second software
polling for HPD and link training events instead of using the hardware
interrupt?

> +		reset-gpios = <&expander0 4 GPIO_ACTIVE_HIGH>;

[Severity: High]
Will this reset-gpios polarity leave the device permanently held in reset?

The tc358767 driver initializes the reset GPIO to logical 0, pulses it to
logical 1 to assert, and returns it to logical 0 to deassert. Since this
is specified as GPIO_ACTIVE_HIGH, the final logical 0 maps to a physical
LOW signal.

If this pin controls the bridge's Enable or active-low Reset, won't holding
it physically LOW leave the bridge permanently disabled? Does this need to be
GPIO_ACTIVE_LOW so the driver's logical 0 maps to a physical HIGH instead?

> +		toshiba,hpd-pin = <0>;
> +		status = "disabled";
> +
> +		ports {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603093621.2504490-1-alexander.stein@ew.tq-group.com?part=2