[PATCH 0/6] arm64: dts: qcom: sc8280xp: set GPI DMA channels according to DSDT

[PATCH 0/6] arm64: dts: qcom: sc8280xp: set GPI DMA channels according to DSDT

[Icenowy Zheng]

Some bugs of the GPI driver exhibits a fact that some GPI interfaces
aren't available to HLOS, and accessing them leads to system stucks /
resets [1] [2].

This patchset sets the DMA channel mask of sc8280xp device trees to the
values indicated by the DSDTs of the corresponding devices.

As different devices seem to have different allowed DMA channels, the
value in the SoC DTSI file is removed, to prevent new DTS's from
directly using these broken values.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142403
[2] https://discussion.fedoraproject.org/t/fedora-43-44-beta-aarch64-wont-boot-on-thinkpad-x13s/183074/13

Icenowy Zheng (6):
  arm64: dts: qcom: sc8280xp-crd: set GPI DMA channels
  arm64: dts: qcom: sc8280xp-huawei-gaokun3: set GPI DMA channels
  arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: set GPI DMA channels
  arm64: dts: qcom: sc8280xp-microsoft-arcata: set GPI DMA channels
  arm64: dts: qcom: sc8280xp-microsoft-blackrock: set GPI DMA channels
  arm64: dts: qcom: sc8280xp: remove GPI DMA channel masks

 arch/arm64/boot/dts/qcom/sc8280xp-crd.dts                  | 3 +++
 arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts       | 3 +++
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 +++
 arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts     | 3 +++
 arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dts  | 3 +++
 arch/arm64/boot/dts/qcom/sc8280xp.dtsi                     | 3 ---
 6 files changed, 15 insertions(+), 3 deletions(-)

-- 
2.52.0

[PATCH 1/6] arm64: dts: qcom: sc8280xp-crd: set GPI DMA channels

[Icenowy Zheng]

It's found that some GPI interfaces shouldn't be touched by HLOS,
otherwise system hang / reset happens.

The GPI interface availability information is available via the ACPI
DSDT table, as interrupt resources for \_SB_.QGP* devices.

Add such information to the device tree file.

The DSDT table is acquired by extraction of qcfirmware8280_NVME.cab file
version 200.0.68.0 from Windows Update.

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
index c53e00cae465a..5fcc1782ab35d 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
@@ -491,14 +491,17 @@ &dispcc0 {
 };
 
 &gpi_dma0 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma1 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma2 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
-- 
2.52.0

[PATCH 2/6] arm64: dts: qcom: sc8280xp-huawei-gaokun3: set GPI DMA channels

[Icenowy Zheng]

It's found that some GPI interfaces shouldn't be touched by HLOS,
otherwise system hang / reset happens.

The GPI interface availability information is available via the ACPI
DSDT table, as interrupt resources for \_SB_.QGP* devices.

Add such information to the device tree file.

The DSDT table is acquired at [1].

[1] https://github.com/aarch64-laptops/build/blob/2e71c8f36d0d565f01a737e9e0cd0ce3c43db0e6/misc/huawei-matebooke-go/dsdt.dsl

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts b/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
index 9819454abe131..f8171bd292e2a 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-huawei-gaokun3.dts
@@ -582,14 +582,17 @@ &dispcc0 {
 };
 
 &gpi_dma0 {
+	dma-channel-mask = <0xb>;
 	status = "okay";
 };
 
 &gpi_dma1 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma2 {
+	dma-channel-mask = <0xb>;
 	status = "okay";
 };
 
-- 
2.52.0

[PATCH 3/6] arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: set GPI DMA channels

[Icenowy Zheng]

It's found that some GPI interfaces shouldn't be touched by HLOS,
otherwise system hang / reset happens.

The GPI interface availability information is available via the ACPI
DSDT table, as interrupt resources for \_SB_.QGP* devices.

Add such information to the device tree file.

The DSDT table is acquired at [1].

[1] https://github.com/aarch64-laptops/build/blob/5e03e2900dee80877895342fa62f9a1badc785d8/misc/lenovo-thinkpad-x13s/dsdt.dsl

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index d84ca010ab9dc..119eeb1560e16 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -704,14 +704,17 @@ &dispcc0 {
 };
 
 &gpi_dma0 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma1 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma2 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
-- 
2.52.0

Re: [PATCH 3/6] arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: set GPI DMA channels

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect channel reference in error cleanup path of gpi_ch_init causes resource leaks and hardware state inconsistency.
--

commit de0b4a765a18a5d7af04a98b890d09dd31cb2362
Author: Icenowy Zheng <zhengxingda@iscas.ac.cn>

arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: set GPI DMA channels

This commit adds GPI interface availability information to the device tree by
setting the dma-channel-mask and marking the status as okay. This ensures
that HLOS does not touch restricted GPI interfaces, preventing system hangs.

> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index d84ca010ab9dc..119eeb1560e16 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -704,14 +704,17 @@ &dispcc0 {
>  };
>  
>  &gpi_dma0 {
> +	dma-channel-mask = <0x3>;

[Severity: High]
This is a pre-existing issue, but since this patch enables GPI DMA interfaces
that might fail to initialize, it could expose an error cleanup bug in the
GPI driver itself.

Looking at the error paths in drivers/dma/qcom/gpi.c:gpi_ch_init():

    error_start_chan:
        for (i = i - 1; i >= 0; i--) {
            gpi_stop_chan(&gpii->gchan[i]);
            gpi_send_cmd(gpii, gchan, GPI_CH_CMD_RESET);
        }
        i = 2;
    error_alloc_chan:
        for (i = i - 1; i >= 0; i--)
            gpi_reset_chan(gchan, GPI_CH_CMD_DE_ALLOC);

Are these loops referencing the correct channel during cleanup?

By using the fixed function argument gchan instead of the iterated channel
&gpii->gchan[i] in gpi_send_cmd() and gpi_reset_chan(), it appears this path
would repeatedly issue reset and de-alloc commands to the same fixed channel
while entirely skipping the cleanup for the successfully allocated or started
channels.

Could this leak the previously initialized DMA channels and leave their
hardware state active, potentially causing hardware lockups?

>  	status = "okay";
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602081451.3808833-1-zhengxingda@iscas.ac.cn?part=3

[PATCH 4/6] arm64: dts: qcom: sc8280xp-microsoft-arcata: set GPI DMA channels

[Icenowy Zheng]

It's found that some GPI interfaces shouldn't be touched by HLOS,
otherwise system hang / reset happens.

The GPI interface availability information is available via the ACPI
DSDT table, as interrupt resources for \_SB_.QGP* devices.

Add such information to the device tree file.

The DSDT table is acquired at [1].

[1] https://github.com/aarch64-laptops/build/blob/534b169ba00230af434ce99fca8af93dc8ec0929/misc/microsoft-surface-pro-9-5G/dsdt.dsl

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index f2b4470d4407f..0dfff4854722b 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -444,14 +444,17 @@ &dispcc1 {
 };
 
 &gpi_dma0 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma1 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma2 {
+	dma-channel-mask = <0x23>;
 	status = "okay";
 };
 
-- 
2.52.0

[PATCH 5/6] arm64: dts: qcom: sc8280xp-microsoft-blackrock: set GPI DMA channels

[Icenowy Zheng]

It's found that some GPI interfaces shouldn't be touched by HLOS,
otherwise system hang / reset happens.

The GPI interface availability information is available via the ACPI
DSDT table, as interrupt resources for \_SB_.QGP* devices.

Add such information to the device tree file.

The DSDT table is acquired at [1].

[1] https://github.com/aarch64-laptops/build/blob/db5150edc30c108662d85fa06bedf962f70e8d1e/misc/microsoft-devkit-2023/DSDT.dsl

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dts
index 00bbeeef6f14d..02075671316bd 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-blackrock.dts
@@ -561,14 +561,17 @@ &dispcc0 {
 };
 
 &gpi_dma0 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma1 {
+	dma-channel-mask = <0x3>;
 	status = "okay";
 };
 
 &gpi_dma2 {
+	dma-channel-mask = <0x23>;
 	status = "okay";
 };
 
-- 
2.52.0

[PATCH 6/6] arm64: dts: qcom: sc8280xp: remove GPI DMA channel masks

[Icenowy Zheng]

It seems that different device may have different allowed GPI
interfaces (e.g. Microsoft Surface 9 5G's gpi_dma2 mask is 0x23 while
Huawei Matebook E Go 2023's gpi_dma2 mask is 0xb).

Remove the channel masks from the SoC DTSI file.

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 761f229e8f472..d4ccca5e29319 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -937,7 +937,6 @@ gpi_dma2: dma-controller@800000 {
 				     <GIC_SPI 599 IRQ_TYPE_LEVEL_HIGH>;
 
 			dma-channels = <12>;
-			dma-channel-mask = <0xfff>;
 			#dma-cells = <3>;
 
 			iommus = <&apps_smmu 0xb6 0x0>;
@@ -1363,7 +1362,6 @@ gpi_dma0: dma-controller@900000 {
 				     <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
 
 			dma-channels = <13>;
-			dma-channel-mask = <0x1fff>;
 			#dma-cells = <3>;
 
 			iommus = <&apps_smmu 0x576 0x0>;
@@ -1770,7 +1768,6 @@ gpi_dma1: dma-controller@a00000 {
 				     <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>;
 
 			dma-channels = <12>;
-			dma-channel-mask = <0xfff>;
 			#dma-cells = <3>;
 
 			iommus = <&apps_smmu 0x96 0x0>;
-- 
2.52.0

Re: [PATCH 6/6] arm64: dts: qcom: sc8280xp: remove GPI DMA channel masks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Removing the strictly required `dma-channel-mask` property from the common `sc8280xp.dtsi` breaks DT schema validation for dependent boards (such as `sa8540p-ride.dts` and `sa8295p-adp.dts`) that do not override the mask.
--

commit 40a49ca07ecffcc445816ce06d38c8c77d95bf35
Author: Icenowy Zheng <zhengxingda@iscas.ac.cn>

arm64: dts: qcom: sc8280xp: remove GPI DMA channel masks

This commit removes the dma-channel-mask property from the GPI DMA
controller nodes in the sc8280xp device tree include file. This is
intended to allow different devices using the SoC to specify their
own channel masks.

> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 761f229e8f472..d4ccca5e29319 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -937,7 +937,6 @@ gpi_dma2: dma-controller@800000 {
>  				     <GIC_SPI 599 IRQ_TYPE_LEVEL_HIGH>;
>  
>  			dma-channels = <12>;
> -			dma-channel-mask = <0xfff>;

[Severity: Medium]
Will removing this property cause dtbs_check validation errors for dependent
boards?

The qcom,gpi.yaml device tree binding strictly requires the dma-channel-mask
property. Other boards that include this file, such as the sa8540p-ride and
sa8295p-adp targets, do not currently provide their own override for this
mask.

Since dtbs_check validates nodes even when their status is disabled, does
this change introduce schema warnings for those targets that fail to add
the property back?

>  			#dma-cells = <3>;
>  
>  			iommus = <&apps_smmu 0xb6 0x0>;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602081451.3808833-1-zhengxingda@iscas.ac.cn?part=6

Re: [PATCH 0/6] arm64: dts: qcom: sc8280xp: set GPI DMA channels according to DSDT

[Pengyu Luo]

On Tue, 02 Jun 2026 16:14:45 +0800, Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
> Some bugs of the GPI driver exhibits a fact that some GPI interfaces
> aren't available to HLOS, and accessing them leads to system stucks /
> resets [1] [2].
> 
> This patchset sets the DMA channel mask of sc8280xp device trees to the
> values indicated by the DSDTs of the corresponding devices.
> 
> As different devices seem to have different allowed DMA channels, the
> value in the SoC DTSI file is removed, to prevent new DTS's from
> directly using these broken values.
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142403
> [2] https://discussion.fedoraproject.org/t/fedora-43-44-beta-aarch64-wont-boot-on-thinkpad-x13s/183074/13
> 

I don't focus on the upstream for a while, was this problem still here
recently? Could you attach the base commit, so I can reproduce it.
About one months ago, gaokun3 worked well with Linux 7.0.0. I enabled
i2c4(gpi_dma0, seid=4), spi6(gpi_dma0, seid=6), i2c15(gpi_dma1, seid=7)

I thought this commit should have fixed the issue in [1]
https://lore.kernel.org/all/20251013115506.103649-1-mitltlatltl@gmail.com

-- 
Best wishes,
Pengyu

Re: [PATCH 0/6] arm64: dts: qcom: sc8280xp: set GPI DMA channels according to DSDT

[Icenowy Zheng]

在 2026-06-02二的 20:53 +0800，Pengyu Luo写道：
> On Tue, 02 Jun 2026 16:14:45 +0800, Icenowy Zheng
> <zhengxingda@iscas.ac.cn> wrote:
> > Some bugs of the GPI driver exhibits a fact that some GPI
> > interfaces
> > aren't available to HLOS, and accessing them leads to system stucks
> > /
> > resets [1] [2].
> > 
> > This patchset sets the DMA channel mask of sc8280xp device trees to
> > the
> > values indicated by the DSDTs of the corresponding devices.
> > 
> > As different devices seem to have different allowed DMA channels,
> > the
> > value in the SoC DTSI file is removed, to prevent new DTS's from
> > directly using these broken values.
> > 
> > [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142403
> > [2]
> > https://discussion.fedoraproject.org/t/fedora-43-44-beta-aarch64-wont-boot-on-thinkpad-x13s/183074/13
> > 
> 
> I don't focus on the upstream for a while, was this problem still
> here
> recently? Could you attach the base commit, so I can reproduce it.

I tested on v7.0.10 (with some extra patches, but not related to
sc8280xp).

It seems that raid456 module will lead to the hang because improper
usage of GPI DMA, and without it loaded it seems to be working fine.

Could you check whether you have any problems with CONFIG_MD_RAID456=y
set?

Thanks,
Icenowy

> About one months ago, gaokun3 worked well with Linux 7.0.0. I enabled
> i2c4(gpi_dma0, seid=4), spi6(gpi_dma0, seid=6), i2c15(gpi_dma1,
> seid=7)
> 
> I thought this commit should have fixed the issue in [1]
> https://lore.kernel.org/all/20251013115506.103649-1-mitltlatltl@gmail.com