From: sashiko-bot@kernel.org
To: "Jingyi Wang" <jingyi.wang@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 3/5] arm64: dts: qcom: Introduce Maili SoC
Date: Wed, 30 Sep 2026 06:49:25 +0000 [thread overview]
Message-ID: <20260930064926.551261F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260929-maili-dts-v2-3-965688646c4b@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: maili: pcie1_opp_table defines x2 OPPs for an x1 PHY
- [Medium] arm64: dts: qcom: maili: impossible QUP pinmux function definitions
- [Medium] arm64: dts: qcom: maili: gpi_dma channel masks exclude requested QUPv3 channels
--
commit a14e352543affb0d0357fd40cb50b296dee6d5e7
Author: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
arm64: dts: qcom: Introduce Maili SoC
This commit introduces the Maili Snapdragon SoC device tree. It includes
various features such as CPUs with PSCI, PCIe, QUPv3 serial engines, UFS,
and GPI DMA.
> diff --git a/arch/arm64/boot/dts/qcom/maili.dtsi b/arch/arm64/boot/dts/qcom/maili.dtsi
> new file mode 100644
> index 0000000000000..c420b709cc7de
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/maili.dtsi
[ ... ]
> + gpi_dma1: dma-controller@a00000 {
> + compatible = "qcom,maili-gpi-dma", "qcom,sm6350-gpi-dma";
> + reg = <0x0 0x00a00000 0x0 0x60000>;
[ ... ]
> + dma-channels = <16>;
> + dma-channel-mask = <0x7f>;
[Severity: Medium]
Does this channel mask intentionally exclude channel 7? The mask <0x7f> enables
channels 0 through 6, but later in the file i2c7 and spi7 explicitly request
channel 7 from gpi_dma1. This could cause the DMA controller to reject the
channel allocation during boot when QUP drivers probe.
[ ... ]
> + gpi_dma3: dma-controller@1900000 {
> + compatible = "qcom,maili-gpi-dma", "qcom,sm6350-gpi-dma";
> + reg = <0x0 0x01900000 0x0 0x60000>;
[ ... ]
> + dma-channels = <12>;
> + dma-channel-mask = <0x1f>;
[Severity: Medium]
Similarly, does this dma-channel-mask exclude channel 5? The mask <0x1f>
only covers channels 0 through 4, but i2c18 and spi18 explicitly request
channel 5 from gpi_dma3. This will cause DMA initialization to fail for those
serial engines.
[ ... ]
> + pcie1: pcie@1c18000 {
[ ... ]
> + pcie1_opp_table: opp-table {
> + compatible = "operating-points-v2";
[ ... ]
> + /* 8.0 GT/s x2 */
> + opp-16000000-3 {
> + opp-hz = /bits/ 64 <16000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + opp-peak-kBps = <1969000 1>;
> + opp-level = <3>;
> + };
[Severity: Medium]
Is it correct to define x2 (2-lane) operating points for pcie1_opp_table?
Later in the file, the PHY is explicitly declared as a 1-lane PHY
(qcom,maili-qmp-gen4x1-pcie-phy). Attempting to scale to these impossible
states could cause mismatched bandwidth expectations or incorrect power
scaling votes in the OPP framework when parsed during runtime.
[ ... ]
> + qup_uart12_default: qup-uart12-default-state {
> + /* TX, RX */
> + pins = "gpio208", "gpio209";
> + function = "qup2_se4_23";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
[Severity: Medium]
Can these pins actually use the _23 function? These pins appear to be wired
to the _01 lanes, as qup_i2c12_data_clk uses qup2_se4_01 for the same pins.
Assigning an incorrect mux function here will cause UART initialization to
fail or silently misroute signals when the pinctrl states are applied.
[ ... ]
> + qup_uart22_default: qup-uart22-default-state {
> + /* TX, RX */
> + pins = "gpio121", "gpio98";
> + function = "qup4_se3_23";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
[Severity: Medium]
Are these the correct pins for this UART? This pairs mismatched pins
(gpio121 with gpio98) while asserting the _23 function. This directly
conflicts with the corresponding I2C node which uses gpio121 and gpio84
for qup4_se3_01. This structural misconfiguration will prevent successful
UART initialization.
[ ... ]
> + qup_uart23_default: qup-uart23-default-state {
> + /* TX, RX */
> + pins = "gpio161", "gpio162";
> + function = "qup4_se4_23";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
[Severity: Medium]
Does this function assignment match the hardware? Like qup_uart12_default,
it assigns the _23 mux function to pins used for TX/RX that are wired to
_01 lanes.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260929-maili-dts-v2-0-965688646c4b@oss.qualcomm.com?part=3
next prev parent reply other threads:[~2026-09-30 6:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 6:31 [PATCH v2 0/5] arm64: dts: qcom: Introduce Maili platform device tree Jingyi Wang
2026-09-30 6:31 ` [PATCH v2 1/5] dt-bindings: arm: qcom: Document Maili SoC and its reference board Jingyi Wang
2026-09-30 6:31 ` [PATCH v2 2/5] arm64: dts: qcom: Add header file for IPCC physical client IDs for Maili platforms Jingyi Wang
2026-09-30 6:31 ` [PATCH v2 3/5] arm64: dts: qcom: Introduce Maili SoC Jingyi Wang
2026-09-30 6:49 ` sashiko-bot [this message]
2026-10-12 6:29 ` Jingyi Wang
2026-09-30 6:31 ` [PATCH v2 4/5] arm64: dts: qcom: Add PMIC support for Maili platforms Jingyi Wang
2026-09-30 6:31 ` [PATCH v2 5/5] arm64: dts: qcom: maili: Add base MTP board Jingyi Wang
2026-09-30 6:40 ` sashiko-bot
2026-10-12 8:11 ` Jingyi Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930064926.551261F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jingyi.wang@oss.qualcomm.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.