Re: [PATCH v2 19/19] arm64: dts: qcom: generalmobile-shamrock: new device

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dts: console UART (blsp1_uart2) is left disabled
- [Medium] dts: TUSB320 interrupt configured as rising edge causes missed events
--

commit eeb150c49a7166233f7744c010edc1dd2b105149
Author: Muzaffer Kadir <muzafferkadir@mainlining.org>

arm64: dts: qcom: generalmobile-shamrock: new device

Add General Mobile Shamrock (GM 5 Plus). Shamrock is designed similar to
L9300. Downstream reference is [1].

Link: https://github.com/Asderdd/android_kernel_generalmobile_shamrock/blob/cm-14.1/arch/arm/boot/dts/qcom/msm8952-l9300.dtsi

> diff --git a/arch/arm64/boot/dts/qcom/msm8952-generalmobile-shamrock.dts b/arch/arm64/boot/dts/qcom/msm8952-generalmobile-shamrock.dts
> new file mode 100644
> index 0000000000000..e6c92ebcbf214
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8952-generalmobile-shamrock.dts
[ ... ]
> +	aliases {
> +		mmc0 = &sdhc_1; /* SDC1 eMMC slot */
> +		mmc1 = &sdhc_2; /* SDC2 SD card slot */
> +		serial0 = &blsp1_uart2;
> +	};
[ ... ]
> +	chosen {
> +		stdout-path = "serial0:115200n8";

[Severity: Medium]
Will the kernel be able to probe the UART device intended for the console?

This configures the kernel console to use serial0, which maps to blsp1_uart2.
However, blsp1_uart2 is left with status = "disabled" in the included
msm8952.dtsi and is never explicitly enabled with status = "okay" in this
board DTS.

Since the driver will not probe, this breaks standard serial output and
serial debugging.

[ ... ]
> +	tusb320: tusb320@67 {
> +		compatible = "ti,tusb320";
> +		reg = <0x67>;
> +		interrupts-extended = <&tlmm 45 IRQ_TYPE_EDGE_RISING>;

[Severity: Medium]
Does this configure the tusb320 interrupt incorrectly for an active-low
open-drain pin?

Any Type-C event triggers an active-low interrupt from the TUSB320, which
would be missed by this rising-edge configuration. The INT_N line will remain
low indefinitely because the interrupt is never serviced and cleared,
breaking USB Type-C plug/unplug detection.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916-msm8952-initial-support-v2-0-798c2602dde1@mainlining.org?part=19