Re: [PATCH v5 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 3 potential issue(s) to consider:
- [High] Incorrect GPIO polarity for the DisplayPort bridge `reset-gpios`.
- [Medium] Missing `interrupts` property for the DisplayPort bridge, preventing hardware Hot-Plug Detect (HPD) interrupts.
- [Medium] Missing high-speed capability flags on SD/eMMC nodes, causing fallback to legacy speeds.
--

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

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

This adds support for the TQMa8MPQS module on the 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
> index 0000000000000..9cff5bf9162a4
> --- /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";

[Severity: Medium]
Since the DP_HPD_INT signal is routed to GPIO5_IO21 (as defined in the
dp-hpd-int-hog node), should this node include the interrupts and
interrupt-parent properties?

Without them, the driver will not register an IRQ handler for Hot-Plug
Detect events and will fall back to 10-second DRM polling.

> +		reg = <0xf>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_tc9595>;
> +		clock-names = "ref";
> +		clocks = <&clk_dp>;
> +		reset-gpios = <&expander0 4 GPIO_ACTIVE_HIGH>;

[Severity: High]
Does this leave the DP bridge permanently disabled?

The tc358767 driver initializes the reset GPIO with GPIOD_OUT_LOW
(logical 0), and returns it to logical 0 during normal operation after
pulsing it. Since the target hardware pin is an active-high enable
(DP_BRIDGE_EN), it must be physically HIGH during operation.

With GPIO_ACTIVE_HIGH, the driver's logical 0 translates to a physical LOW.
Should this use GPIO_ACTIVE_LOW instead to map the deasserted reset state
to a physical HIGH?

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

[ ... ]

> +&usdhc2 {
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> +	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> +	bus-width = <4>;
> +	vqmmc-supply = <&reg_usdhc2_vqmmc>;

[Severity: Medium]
Will this node fall back to legacy 50MHz speeds despite having 200MHz
pinctrl states?

The MMC subsystem requires explicit capability properties (like
sd-uhs-sdr104) to negotiate higher speeds. Without them, the state_100mhz
and state_200mhz definitions will not be used.

> +	/* NOTE: CD / WP and VMMC support depends on mainboard */
> +};
> +
> +&usdhc3 {
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> +	pinctrl-0 = <&pinctrl_usdhc3>;
> +	pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> +	pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> +	bus-width = <8>;
> +	non-removable;
> +	no-sdio;
> +	no-sd;
> +	vmmc-supply = <&buck4>;
> +	vqmmc-supply = <&buck5>;

[Severity: Medium]
Similar to usdhc2, is this missing eMMC high-speed capability flags like
mmc-hs200-1_8v, mmc-hs400-1_8v, or mmc-hs400-enhanced-strobe?

Without these flags, the interface will operate at legacy speeds instead
of utilizing the 100MHz or 200MHz hardware capabilities.

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

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