[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

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

[Pengyu Luo]

On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> 在 2026-06-02二的 20:53 +0800，Pengyu Luo写道：
> 
> > On Tue, 02 Jun 2026 16:14:45 +0800, Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > 
> > 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?
> 

The magnetic keyboard (USB HID) can't be connected somehow, others are
fine, such as the spi touchscreen (not upstream yet), which utilizes
DMA definitely. My config is here https://pastebin.com/SdjuyJYk

Which device are you testing? Please attach more information if
possible.

> Thanks,
> Icenowy

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

[Icenowy Zheng]

在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > 在 2026-06-02二的 20:53 +0800，Pengyu Luo写道：
> > 
> > > On Tue, 02 Jun 2026 16:14:45 +0800, Icenowy Zheng
> > > <zhengxingda@iscas.ac.cn> wrote:
> > > 
> > > 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?
> > 
> 
> The magnetic keyboard (USB HID) can't be connected somehow, others
> are
> fine, such as the spi touchscreen (not upstream yet), which utilizes
> DMA definitely. My config is here https://pastebin.com/SdjuyJYk

Is this a defconfig?

BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too for
exhibiting the problem (because there should be "public" GPI DMA
consumers to trigger the stuck/reset).

> 
> Which device are you testing? Please attach more information if
> possible.

My device is gaokun3 too, although I used the mainline device tree.

> 
> > Thanks,
> > Icenowy

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

[Pengyu Luo]

On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> 
> > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > 
> > The magnetic keyboard (USB HID) can't be connected somehow, others
> > are
> > fine, such as the spi touchscreen (not upstream yet), which utilizes
> > DMA definitely. My config is here https://pastebin.com/SdjuyJYk
> 
> Is this a defconfig?
> 

Yes.

> BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too for
> exhibiting the problem (because there should be "public" GPI DMA
> consumers to trigger the stuck/reset).
> 

Is this still necessary? I checked the fedora discussion and your GPI
DMA fix. And GPI DMA is only for the QUP-supported peripherals as the
binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml

> > Which device are you testing? Please attach more information if
> > possible.
> 
> My device is gaokun3 too, although I used the mainline device tree.

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

[Icenowy Zheng]

在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > 
> > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > 
> > > The magnetic keyboard (USB HID) can't be connected somehow,
> > > others
> > > are
> > > fine, such as the spi touchscreen (not upstream yet), which
> > > utilizes
> > > DMA definitely. My config is here https://pastebin.com/SdjuyJYk
> > 
> > Is this a defconfig?
> > 
> 
> Yes.
> 
> > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too for
> > exhibiting the problem (because there should be "public" GPI DMA
> > consumers to trigger the stuck/reset).
> > 
> 
> Is this still necessary? I checked the fedora discussion and your GPI
> DMA fix. And GPI DMA is only for the QUP-supported peripherals as the
> binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml

The devicetree without this fix seems to be still incorrect, because
with the device tree fix even if the GPI DMA driver misbehaves the
system won't be stuck (although it will iterate all GPI channels and
then fail to function at all).

Thanks,
Icenowy

> 
> > > Which device are you testing? Please attach more information if
> > > possible.
> > 
> > My device is gaokun3 too, although I used the mainline device tree.

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

[Pengyu Luo]

On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > >
> > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > >
> > > > The magnetic keyboard (USB HID) can't be connected somehow,
> > > > others
> > > > are
> > > > fine, such as the spi touchscreen (not upstream yet), which
> > > > utilizes
> > > > DMA definitely. My config is here https://pastebin.com/SdjuyJYk
> > >
> > > Is this a defconfig?
> > >
> >
> > Yes.
> >
> > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too for
> > > exhibiting the problem (because there should be "public" GPI DMA
> > > consumers to trigger the stuck/reset).
> > >
> >
> > Is this still necessary? I checked the fedora discussion and your GPI
> > DMA fix. And GPI DMA is only for the QUP-supported peripherals as the
> > binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
>
> The devicetree without this fix seems to be still incorrect, because
> with the device tree fix even if the GPI DMA driver misbehaves the
> system won't be stuck (although it will iterate all GPI channels and
> then fail to function at all).
>

Back to the start. You said some GPI interfaces aren't available to
HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick test,
and spi6 consumed it, no stuck or reset. Could you give me a
unavailable channel?

Best wishes,
Pengyu

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

[Icenowy Zheng]

在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
> On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
> <zhengxingda@iscas.ac.cn> wrote:
> > 
> > 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > > > 
> > > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > > > 
> > > > > The magnetic keyboard (USB HID) can't be connected somehow,
> > > > > others
> > > > > are
> > > > > fine, such as the spi touchscreen (not upstream yet), which
> > > > > utilizes
> > > > > DMA definitely. My config is here
> > > > > https://pastebin.com/SdjuyJYk
> > > > 
> > > > Is this a defconfig?
> > > > 
> > > 
> > > Yes.
> > > 
> > > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too
> > > > for
> > > > exhibiting the problem (because there should be "public" GPI
> > > > DMA
> > > > consumers to trigger the stuck/reset).
> > > > 
> > > 
> > > Is this still necessary? I checked the fedora discussion and your
> > > GPI
> > > DMA fix. And GPI DMA is only for the QUP-supported peripherals as
> > > the
> > > binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
> > 
> > The devicetree without this fix seems to be still incorrect,
> > because
> > with the device tree fix even if the GPI DMA driver misbehaves the
> > system won't be stuck (although it will iterate all GPI channels
> > and
> > then fail to function at all).
> > 
> 
> Back to the start. You said some GPI interfaces aren't available to
> HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick test,
> and spi6 consumed it, no stuck or reset. Could you give me a
> unavailable channel?

I think channel 0b10000 of gpi_dma2 could be an example?

It seems that 4 channels are tried on gpi_dma2 before hang on my
gaokun3, but as gaokun3 has no known serial access, it's possible that
0b100000 or 0b1000 is problematic.

(The reason gpi_dma2 is checked first is because it's the GPI DMA
controller with the smallest address)

BTW I just took the values from Windows DSDT, which is quite
conservative.

Thanks,
Icenowy

> 
> Best wishes,
> Pengyu

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

[Konrad Dybcio]

On 6/7/26 10:49 AM, Icenowy Zheng wrote:
> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
>> On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
>> <zhengxingda@iscas.ac.cn> wrote:
>>>
>>> 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
>>>> On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
>>>>> 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
>>>>>
>>>>>> On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
>>>>>>
>>>>>> The magnetic keyboard (USB HID) can't be connected somehow,
>>>>>> others
>>>>>> are
>>>>>> fine, such as the spi touchscreen (not upstream yet), which
>>>>>> utilizes
>>>>>> DMA definitely. My config is here
>>>>>> https://pastebin.com/SdjuyJYk
>>>>>
>>>>> Is this a defconfig?
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>> BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too
>>>>> for
>>>>> exhibiting the problem (because there should be "public" GPI
>>>>> DMA
>>>>> consumers to trigger the stuck/reset).
>>>>>
>>>>
>>>> Is this still necessary? I checked the fedora discussion and your
>>>> GPI
>>>> DMA fix. And GPI DMA is only for the QUP-supported peripherals as
>>>> the
>>>> binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
>>>
>>> The devicetree without this fix seems to be still incorrect,
>>> because
>>> with the device tree fix even if the GPI DMA driver misbehaves the
>>> system won't be stuck (although it will iterate all GPI channels
>>> and
>>> then fail to function at all).
>>>
>>
>> Back to the start. You said some GPI interfaces aren't available to
>> HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick test,
>> and spi6 consumed it, no stuck or reset. Could you give me a
>> unavailable channel?
> 
> I think channel 0b10000 of gpi_dma2 could be an example?
> 
> It seems that 4 channels are tried on gpi_dma2 before hang on my
> gaokun3, but as gaokun3 has no known serial access, it's possible that
> 0b100000 or 0b1000 is problematic.
> 
> (The reason gpi_dma2 is checked first is because it's the GPI DMA
> controller with the smallest address)
> 
> BTW I just took the values from Windows DSDT, which is quite
> conservative.

So, with DMA_PRIVATE set, is this series made redundant?

Konrad

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

[Icenowy Zheng]

在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
> On 6/7/26 10:49 AM, Icenowy Zheng wrote:
> > 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
> > > On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
> > > <zhengxingda@iscas.ac.cn> wrote:
> > > > 
> > > > 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > > > > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > > > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > > > > > 
> > > > > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > > > > > 
> > > > > > > The magnetic keyboard (USB HID) can't be connected
> > > > > > > somehow,
> > > > > > > others
> > > > > > > are
> > > > > > > fine, such as the spi touchscreen (not upstream yet),
> > > > > > > which
> > > > > > > utilizes
> > > > > > > DMA definitely. My config is here
> > > > > > > https://pastebin.com/SdjuyJYk
> > > > > > 
> > > > > > Is this a defconfig?
> > > > > > 
> > > > > 
> > > > > Yes.
> > > > > 
> > > > > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected
> > > > > > too
> > > > > > for
> > > > > > exhibiting the problem (because there should be "public"
> > > > > > GPI
> > > > > > DMA
> > > > > > consumers to trigger the stuck/reset).
> > > > > > 
> > > > > 
> > > > > Is this still necessary? I checked the fedora discussion and
> > > > > your
> > > > > GPI
> > > > > DMA fix. And GPI DMA is only for the QUP-supported
> > > > > peripherals as
> > > > > the
> > > > > binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
> > > > 
> > > > The devicetree without this fix seems to be still incorrect,
> > > > because
> > > > with the device tree fix even if the GPI DMA driver misbehaves
> > > > the
> > > > system won't be stuck (although it will iterate all GPI
> > > > channels
> > > > and
> > > > then fail to function at all).
> > > > 
> > > 
> > > Back to the start. You said some GPI interfaces aren't available
> > > to
> > > HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick
> > > test,
> > > and spi6 consumed it, no stuck or reset. Could you give me a
> > > unavailable channel?
> > 
> > I think channel 0b10000 of gpi_dma2 could be an example?
> > 
> > It seems that 4 channels are tried on gpi_dma2 before hang on my
> > gaokun3, but as gaokun3 has no known serial access, it's possible
> > that
> > 0b100000 or 0b1000 is problematic.
> > 
> > (The reason gpi_dma2 is checked first is because it's the GPI DMA
> > controller with the smallest address)
> > 
> > BTW I just took the values from Windows DSDT, which is quite
> > conservative.
> 
> So, with DMA_PRIVATE set, is this series made redundant?

I assume technically the trustzone is still protecting some channels,
although the system stuck issue is fixed.

This series should still be relevant, although not so emergent.

Thanks,
Icenowy

> 
> Konrad

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

[Konrad Dybcio]

On 6/9/26 5:54 PM, Icenowy Zheng wrote:
> 在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
>> On 6/7/26 10:49 AM, Icenowy Zheng wrote:
>>> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
>>>> On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
>>>> <zhengxingda@iscas.ac.cn> wrote:
>>>>>
>>>>> 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
>>>>>> On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
>>>>>>> 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
>>>>>>>
>>>>>>>> On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
>>>>>>>>
>>>>>>>> The magnetic keyboard (USB HID) can't be connected
>>>>>>>> somehow,
>>>>>>>> others
>>>>>>>> are
>>>>>>>> fine, such as the spi touchscreen (not upstream yet),
>>>>>>>> which
>>>>>>>> utilizes
>>>>>>>> DMA definitely. My config is here
>>>>>>>> https://pastebin.com/SdjuyJYk
>>>>>>>
>>>>>>> Is this a defconfig?
>>>>>>>
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>> BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected
>>>>>>> too
>>>>>>> for
>>>>>>> exhibiting the problem (because there should be "public"
>>>>>>> GPI
>>>>>>> DMA
>>>>>>> consumers to trigger the stuck/reset).
>>>>>>>
>>>>>>
>>>>>> Is this still necessary? I checked the fedora discussion and
>>>>>> your
>>>>>> GPI
>>>>>> DMA fix. And GPI DMA is only for the QUP-supported
>>>>>> peripherals as
>>>>>> the
>>>>>> binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
>>>>>
>>>>> The devicetree without this fix seems to be still incorrect,
>>>>> because
>>>>> with the device tree fix even if the GPI DMA driver misbehaves
>>>>> the
>>>>> system won't be stuck (although it will iterate all GPI
>>>>> channels
>>>>> and
>>>>> then fail to function at all).
>>>>>
>>>>
>>>> Back to the start. You said some GPI interfaces aren't available
>>>> to
>>>> HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick
>>>> test,
>>>> and spi6 consumed it, no stuck or reset. Could you give me a
>>>> unavailable channel?
>>>
>>> I think channel 0b10000 of gpi_dma2 could be an example?
>>>
>>> It seems that 4 channels are tried on gpi_dma2 before hang on my
>>> gaokun3, but as gaokun3 has no known serial access, it's possible
>>> that
>>> 0b100000 or 0b1000 is problematic.
>>>
>>> (The reason gpi_dma2 is checked first is because it's the GPI DMA
>>> controller with the smallest address)
>>>
>>> BTW I just took the values from Windows DSDT, which is quite
>>> conservative.
>>
>> So, with DMA_PRIVATE set, is this series made redundant?
> 
> I assume technically the trustzone is still protecting some channels,
> although the system stuck issue is fixed.
> 
> This series should still be relevant, although not so emergent.

So now we're down to the case of the TZ reserving some of the GPI
channels (presumably for locked down/TZ-driven QUPs) crashing the
device on access, is that right?

Konrad

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

[Konrad Dybcio]

On 6/18/26 11:04 AM, Konrad Dybcio wrote:
> On 6/9/26 5:54 PM, Icenowy Zheng wrote:
>> 在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
>>> On 6/7/26 10:49 AM, Icenowy Zheng wrote:
>>>> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
>>>>> On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
>>>>> <zhengxingda@iscas.ac.cn> wrote:
>>>>>>
>>>>>> 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
>>>>>>> On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
>>>>>>>> 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
>>>>>>>>
>>>>>>>>> On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
>>>>>>>>>
>>>>>>>>> The magnetic keyboard (USB HID) can't be connected
>>>>>>>>> somehow,
>>>>>>>>> others
>>>>>>>>> are
>>>>>>>>> fine, such as the spi touchscreen (not upstream yet),
>>>>>>>>> which
>>>>>>>>> utilizes
>>>>>>>>> DMA definitely. My config is here
>>>>>>>>> https://pastebin.com/SdjuyJYk
>>>>>>>>
>>>>>>>> Is this a defconfig?
>>>>>>>>
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>> BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected
>>>>>>>> too
>>>>>>>> for
>>>>>>>> exhibiting the problem (because there should be "public"
>>>>>>>> GPI
>>>>>>>> DMA
>>>>>>>> consumers to trigger the stuck/reset).
>>>>>>>>
>>>>>>>
>>>>>>> Is this still necessary? I checked the fedora discussion and
>>>>>>> your
>>>>>>> GPI
>>>>>>> DMA fix. And GPI DMA is only for the QUP-supported
>>>>>>> peripherals as
>>>>>>> the
>>>>>>> binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
>>>>>>
>>>>>> The devicetree without this fix seems to be still incorrect,
>>>>>> because
>>>>>> with the device tree fix even if the GPI DMA driver misbehaves
>>>>>> the
>>>>>> system won't be stuck (although it will iterate all GPI
>>>>>> channels
>>>>>> and
>>>>>> then fail to function at all).
>>>>>>
>>>>>
>>>>> Back to the start. You said some GPI interfaces aren't available
>>>>> to
>>>>> HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick
>>>>> test,
>>>>> and spi6 consumed it, no stuck or reset. Could you give me a
>>>>> unavailable channel?
>>>>
>>>> I think channel 0b10000 of gpi_dma2 could be an example?
>>>>
>>>> It seems that 4 channels are tried on gpi_dma2 before hang on my
>>>> gaokun3, but as gaokun3 has no known serial access, it's possible
>>>> that
>>>> 0b100000 or 0b1000 is problematic.
>>>>
>>>> (The reason gpi_dma2 is checked first is because it's the GPI DMA
>>>> controller with the smallest address)
>>>>
>>>> BTW I just took the values from Windows DSDT, which is quite
>>>> conservative.
>>>
>>> So, with DMA_PRIVATE set, is this series made redundant?
>>
>> I assume technically the trustzone is still protecting some channels,
>> although the system stuck issue is fixed.
>>
>> This series should still be relevant, although not so emergent.
> 
> So now we're down to the case of the TZ reserving some of the GPI
> channels (presumably for locked down/TZ-driven QUPs) crashing the
> device on access, is that right?

i.e. now, is requesting these channels through (wrongfully) enabling
the devices in DT the only remaining concern?

Konrad

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

[Icenowy Zheng]

在 2026-06-18四的 11:05 +0200，Konrad Dybcio写道：
> On 6/18/26 11:04 AM, Konrad Dybcio wrote:
> > On 6/9/26 5:54 PM, Icenowy Zheng wrote:
> > > 在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
> > > > On 6/7/26 10:49 AM, Icenowy Zheng wrote:
> > > > > 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
> > > > > > On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
> > > > > > <zhengxingda@iscas.ac.cn> wrote:
> > > > > > > 
> > > > > > > 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > > > > > > > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > > > > > > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > > > > > > > > 
> > > > > > > > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > > > > > > > > 
> > > > > > > > > > The magnetic keyboard (USB HID) can't be connected
> > > > > > > > > > somehow,
> > > > > > > > > > others
> > > > > > > > > > are
> > > > > > > > > > fine, such as the spi touchscreen (not upstream
> > > > > > > > > > yet),
> > > > > > > > > > which
> > > > > > > > > > utilizes
> > > > > > > > > > DMA definitely. My config is here
> > > > > > > > > > https://pastebin.com/SdjuyJYk
> > > > > > > > > 
> > > > > > > > > Is this a defconfig?
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Yes.
> > > > > > > > 
> > > > > > > > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be
> > > > > > > > > selected
> > > > > > > > > too
> > > > > > > > > for
> > > > > > > > > exhibiting the problem (because there should be
> > > > > > > > > "public"
> > > > > > > > > GPI
> > > > > > > > > DMA
> > > > > > > > > consumers to trigger the stuck/reset).
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Is this still necessary? I checked the fedora
> > > > > > > > discussion and
> > > > > > > > your
> > > > > > > > GPI
> > > > > > > > DMA fix. And GPI DMA is only for the QUP-supported
> > > > > > > > peripherals as
> > > > > > > > the
> > > > > > > > binding mentioned,
> > > > > > > > devicetree/bindings/dma/qcom,gpi.yaml
> > > > > > > 
> > > > > > > The devicetree without this fix seems to be still
> > > > > > > incorrect,
> > > > > > > because
> > > > > > > with the device tree fix even if the GPI DMA driver
> > > > > > > misbehaves
> > > > > > > the
> > > > > > > system won't be stuck (although it will iterate all GPI
> > > > > > > channels
> > > > > > > and
> > > > > > > then fail to function at all).
> > > > > > > 
> > > > > > 
> > > > > > Back to the start. You said some GPI interfaces aren't
> > > > > > available
> > > > > > to
> > > > > > HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a
> > > > > > quick
> > > > > > test,
> > > > > > and spi6 consumed it, no stuck or reset. Could you give me
> > > > > > a
> > > > > > unavailable channel?
> > > > > 
> > > > > I think channel 0b10000 of gpi_dma2 could be an example?
> > > > > 
> > > > > It seems that 4 channels are tried on gpi_dma2 before hang on
> > > > > my
> > > > > gaokun3, but as gaokun3 has no known serial access, it's
> > > > > possible
> > > > > that
> > > > > 0b100000 or 0b1000 is problematic.
> > > > > 
> > > > > (The reason gpi_dma2 is checked first is because it's the GPI
> > > > > DMA
> > > > > controller with the smallest address)
> > > > > 
> > > > > BTW I just took the values from Windows DSDT, which is quite
> > > > > conservative.
> > > > 
> > > > So, with DMA_PRIVATE set, is this series made redundant?
> > > 
> > > I assume technically the trustzone is still protecting some
> > > channels,
> > > although the system stuck issue is fixed.
> > > 
> > > This series should still be relevant, although not so emergent.
> > 
> > So now we're down to the case of the TZ reserving some of the GPI
> > channels (presumably for locked down/TZ-driven QUPs) crashing the
> > device on access, is that right?
> 
> i.e. now, is requesting these channels through (wrongfully) enabling
> the devices in DT the only remaining concern?

Yes, I think so; although I think few devices will use GPI on these
devices (usually only one or two SPI controllers according to the
DSDTs).

Thanks,
Icenowy

> 
> Konrad

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

[Konrad Dybcio]

On 6/18/26 12:34 PM, Icenowy Zheng wrote:
> 在 2026-06-18四的 11:05 +0200，Konrad Dybcio写道：
>> On 6/18/26 11:04 AM, Konrad Dybcio wrote:
>>> On 6/9/26 5:54 PM, Icenowy Zheng wrote:
>>>> 在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
>>>>> On 6/7/26 10:49 AM, Icenowy Zheng wrote:
>>>>>> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
>>>>>>> On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
>>>>>>> <zhengxingda@iscas.ac.cn> wrote:
>>>>>>>>
>>>>>>>> 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
>>>>>>>>> On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
>>>>>>>>>> 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
>>>>>>>>>>
>>>>>>>>>>> On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
>>>>>>>>>>>
>>>>>>>>>>> The magnetic keyboard (USB HID) can't be connected
>>>>>>>>>>> somehow,
>>>>>>>>>>> others
>>>>>>>>>>> are
>>>>>>>>>>> fine, such as the spi touchscreen (not upstream
>>>>>>>>>>> yet),
>>>>>>>>>>> which
>>>>>>>>>>> utilizes
>>>>>>>>>>> DMA definitely. My config is here
>>>>>>>>>>> https://pastebin.com/SdjuyJYk
>>>>>>>>>>
>>>>>>>>>> Is this a defconfig?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>>> BTW it seems that CONFIG_ASYNC_TX_DMA needs to be
>>>>>>>>>> selected
>>>>>>>>>> too
>>>>>>>>>> for
>>>>>>>>>> exhibiting the problem (because there should be
>>>>>>>>>> "public"
>>>>>>>>>> GPI
>>>>>>>>>> DMA
>>>>>>>>>> consumers to trigger the stuck/reset).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is this still necessary? I checked the fedora
>>>>>>>>> discussion and
>>>>>>>>> your
>>>>>>>>> GPI
>>>>>>>>> DMA fix. And GPI DMA is only for the QUP-supported
>>>>>>>>> peripherals as
>>>>>>>>> the
>>>>>>>>> binding mentioned,
>>>>>>>>> devicetree/bindings/dma/qcom,gpi.yaml
>>>>>>>>
>>>>>>>> The devicetree without this fix seems to be still
>>>>>>>> incorrect,
>>>>>>>> because
>>>>>>>> with the device tree fix even if the GPI DMA driver
>>>>>>>> misbehaves
>>>>>>>> the
>>>>>>>> system won't be stuck (although it will iterate all GPI
>>>>>>>> channels
>>>>>>>> and
>>>>>>>> then fail to function at all).
>>>>>>>>
>>>>>>>
>>>>>>> Back to the start. You said some GPI interfaces aren't
>>>>>>> available
>>>>>>> to
>>>>>>> HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a
>>>>>>> quick
>>>>>>> test,
>>>>>>> and spi6 consumed it, no stuck or reset. Could you give me
>>>>>>> a
>>>>>>> unavailable channel?
>>>>>>
>>>>>> I think channel 0b10000 of gpi_dma2 could be an example?
>>>>>>
>>>>>> It seems that 4 channels are tried on gpi_dma2 before hang on
>>>>>> my
>>>>>> gaokun3, but as gaokun3 has no known serial access, it's
>>>>>> possible
>>>>>> that
>>>>>> 0b100000 or 0b1000 is problematic.
>>>>>>
>>>>>> (The reason gpi_dma2 is checked first is because it's the GPI
>>>>>> DMA
>>>>>> controller with the smallest address)
>>>>>>
>>>>>> BTW I just took the values from Windows DSDT, which is quite
>>>>>> conservative.
>>>>>
>>>>> So, with DMA_PRIVATE set, is this series made redundant?
>>>>
>>>> I assume technically the trustzone is still protecting some
>>>> channels,
>>>> although the system stuck issue is fixed.
>>>>
>>>> This series should still be relevant, although not so emergent.
>>>
>>> So now we're down to the case of the TZ reserving some of the GPI
>>> channels (presumably for locked down/TZ-driven QUPs) crashing the
>>> device on access, is that right?
>>
>> i.e. now, is requesting these channels through (wrongfully) enabling
>> the devices in DT the only remaining concern?
> 
> Yes, I think so; although I think few devices will use GPI on these
> devices (usually only one or two SPI controllers according to the
> DSDTs).

IIRC there's a configuration table that lets OEMs decide which ones
should fall under the secure umbrella (although most never seem to
change the defaults).

I don't think we need to care too much about the mask being ultra-correct,
since as we've established only QUPs are "valid" consumers and we're not
going to enable them globally by default, since there are conflicting pin
assignments (i.e. there are many more QUPs than allocated GPIOs)

Konrad

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

[Icenowy Zheng]

在 2026-06-19五的 14:27 +0200，Konrad Dybcio写道：
> On 6/18/26 12:34 PM, Icenowy Zheng wrote:
> > 在 2026-06-18四的 11:05 +0200，Konrad Dybcio写道：
> > > On 6/18/26 11:04 AM, Konrad Dybcio wrote:
> > > > On 6/9/26 5:54 PM, Icenowy Zheng wrote:
> > > > > 在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
> > > > > > On 6/7/26 10:49 AM, Icenowy Zheng wrote:
> > > > > > > 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
> > > > > > > > On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
> > > > > > > > <zhengxingda@iscas.ac.cn> wrote:
> > > > > > > > > 
> > > > > > > > > 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > > > > > > > > > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > > > > > > > > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > > > > > > > > > > 
> > > > > > > > > > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > The magnetic keyboard (USB HID) can't be
> > > > > > > > > > > > connected
> > > > > > > > > > > > somehow,
> > > > > > > > > > > > others
> > > > > > > > > > > > are
> > > > > > > > > > > > fine, such as the spi touchscreen (not upstream
> > > > > > > > > > > > yet),
> > > > > > > > > > > > which
> > > > > > > > > > > > utilizes
> > > > > > > > > > > > DMA definitely. My config is here
> > > > > > > > > > > > https://pastebin.com/SdjuyJYk
> > > > > > > > > > > 
> > > > > > > > > > > Is this a defconfig?
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Yes.
> > > > > > > > > > 
> > > > > > > > > > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be
> > > > > > > > > > > selected
> > > > > > > > > > > too
> > > > > > > > > > > for
> > > > > > > > > > > exhibiting the problem (because there should be
> > > > > > > > > > > "public"
> > > > > > > > > > > GPI
> > > > > > > > > > > DMA
> > > > > > > > > > > consumers to trigger the stuck/reset).
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Is this still necessary? I checked the fedora
> > > > > > > > > > discussion and
> > > > > > > > > > your
> > > > > > > > > > GPI
> > > > > > > > > > DMA fix. And GPI DMA is only for the QUP-supported
> > > > > > > > > > peripherals as
> > > > > > > > > > the
> > > > > > > > > > binding mentioned,
> > > > > > > > > > devicetree/bindings/dma/qcom,gpi.yaml
> > > > > > > > > 
> > > > > > > > > The devicetree without this fix seems to be still
> > > > > > > > > incorrect,
> > > > > > > > > because
> > > > > > > > > with the device tree fix even if the GPI DMA driver
> > > > > > > > > misbehaves
> > > > > > > > > the
> > > > > > > > > system won't be stuck (although it will iterate all
> > > > > > > > > GPI
> > > > > > > > > channels
> > > > > > > > > and
> > > > > > > > > then fail to function at all).
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Back to the start. You said some GPI interfaces aren't
> > > > > > > > available
> > > > > > > > to
> > > > > > > > HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did
> > > > > > > > a
> > > > > > > > quick
> > > > > > > > test,
> > > > > > > > and spi6 consumed it, no stuck or reset. Could you give
> > > > > > > > me
> > > > > > > > a
> > > > > > > > unavailable channel?
> > > > > > > 
> > > > > > > I think channel 0b10000 of gpi_dma2 could be an example?
> > > > > > > 
> > > > > > > It seems that 4 channels are tried on gpi_dma2 before
> > > > > > > hang on
> > > > > > > my
> > > > > > > gaokun3, but as gaokun3 has no known serial access, it's
> > > > > > > possible
> > > > > > > that
> > > > > > > 0b100000 or 0b1000 is problematic.
> > > > > > > 
> > > > > > > (The reason gpi_dma2 is checked first is because it's the
> > > > > > > GPI
> > > > > > > DMA
> > > > > > > controller with the smallest address)
> > > > > > > 
> > > > > > > BTW I just took the values from Windows DSDT, which is
> > > > > > > quite
> > > > > > > conservative.
> > > > > > 
> > > > > > So, with DMA_PRIVATE set, is this series made redundant?
> > > > > 
> > > > > I assume technically the trustzone is still protecting some
> > > > > channels,
> > > > > although the system stuck issue is fixed.
> > > > > 
> > > > > This series should still be relevant, although not so
> > > > > emergent.
> > > > 
> > > > So now we're down to the case of the TZ reserving some of the
> > > > GPI
> > > > channels (presumably for locked down/TZ-driven QUPs) crashing
> > > > the
> > > > device on access, is that right?
> > > 
> > > i.e. now, is requesting these channels through (wrongfully)
> > > enabling
> > > the devices in DT the only remaining concern?
> > 
> > Yes, I think so; although I think few devices will use GPI on these
> > devices (usually only one or two SPI controllers according to the
> > DSDTs).
> 
> IIRC there's a configuration table that lets OEMs decide which ones
> should fall under the secure umbrella (although most never seem to
> change the defaults).

Ah then what's the default value?

Radxa Dragon Q8B seems to have GPII0-5 enabled for all GPI controllers
[1].

Thanks,
Icenowy

[1]
https://github.com/strongtz/linux-radxa-qcom/commit/99878a41264ef4f2a77783676de36a80de7103ba

> 
> I don't think we need to care too much about the mask being ultra-
> correct,
> since as we've established only QUPs are "valid" consumers and we're
> not
> going to enable them globally by default, since there are conflicting
> pin
> assignments (i.e. there are many more QUPs than allocated GPIOs)
> 
> Konrad

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

[Konrad Dybcio]

On 6/19/26 2:50 PM, Icenowy Zheng wrote:
> 在 2026-06-19五的 14:27 +0200，Konrad Dybcio写道：
>> On 6/18/26 12:34 PM, Icenowy Zheng wrote:
>>> 在 2026-06-18四的 11:05 +0200，Konrad Dybcio写道：
>>>> On 6/18/26 11:04 AM, Konrad Dybcio wrote:
>>>>> On 6/9/26 5:54 PM, Icenowy Zheng wrote:
>>>>>> 在 2026-06-09二的 14:23 +0200，Konrad Dybcio写道：
>>>>>>> On 6/7/26 10:49 AM, Icenowy Zheng wrote:
>>>>>>>> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
>>>>>>>>> On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
>>>>>>>>> <zhengxingda@iscas.ac.cn> wrote:
>>>>>>>>>>
>>>>>>>>>> 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
>>>>>>>>>>> On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
>>>>>>>>>>>> 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
>>>>>>>>>>>>
>>>>>>>>>>>>> On 2026-06-02 21:21:27+08:00, Icenowy Zheng
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The magnetic keyboard (USB HID) can't be
>>>>>>>>>>>>> connected
>>>>>>>>>>>>> somehow,
>>>>>>>>>>>>> others
>>>>>>>>>>>>> are
>>>>>>>>>>>>> fine, such as the spi touchscreen (not upstream
>>>>>>>>>>>>> yet),
>>>>>>>>>>>>> which
>>>>>>>>>>>>> utilizes
>>>>>>>>>>>>> DMA definitely. My config is here
>>>>>>>>>>>>> https://pastebin.com/SdjuyJYk
>>>>>>>>>>>>
>>>>>>>>>>>> Is this a defconfig?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes.
>>>>>>>>>>>
>>>>>>>>>>>> BTW it seems that CONFIG_ASYNC_TX_DMA needs to be
>>>>>>>>>>>> selected
>>>>>>>>>>>> too
>>>>>>>>>>>> for
>>>>>>>>>>>> exhibiting the problem (because there should be
>>>>>>>>>>>> "public"
>>>>>>>>>>>> GPI
>>>>>>>>>>>> DMA
>>>>>>>>>>>> consumers to trigger the stuck/reset).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is this still necessary? I checked the fedora
>>>>>>>>>>> discussion and
>>>>>>>>>>> your
>>>>>>>>>>> GPI
>>>>>>>>>>> DMA fix. And GPI DMA is only for the QUP-supported
>>>>>>>>>>> peripherals as
>>>>>>>>>>> the
>>>>>>>>>>> binding mentioned,
>>>>>>>>>>> devicetree/bindings/dma/qcom,gpi.yaml
>>>>>>>>>>
>>>>>>>>>> The devicetree without this fix seems to be still
>>>>>>>>>> incorrect,
>>>>>>>>>> because
>>>>>>>>>> with the device tree fix even if the GPI DMA driver
>>>>>>>>>> misbehaves
>>>>>>>>>> the
>>>>>>>>>> system won't be stuck (although it will iterate all
>>>>>>>>>> GPI
>>>>>>>>>> channels
>>>>>>>>>> and
>>>>>>>>>> then fail to function at all).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Back to the start. You said some GPI interfaces aren't
>>>>>>>>> available
>>>>>>>>> to
>>>>>>>>> HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did
>>>>>>>>> a
>>>>>>>>> quick
>>>>>>>>> test,
>>>>>>>>> and spi6 consumed it, no stuck or reset. Could you give
>>>>>>>>> me
>>>>>>>>> a
>>>>>>>>> unavailable channel?
>>>>>>>>
>>>>>>>> I think channel 0b10000 of gpi_dma2 could be an example?
>>>>>>>>
>>>>>>>> It seems that 4 channels are tried on gpi_dma2 before
>>>>>>>> hang on
>>>>>>>> my
>>>>>>>> gaokun3, but as gaokun3 has no known serial access, it's
>>>>>>>> possible
>>>>>>>> that
>>>>>>>> 0b100000 or 0b1000 is problematic.
>>>>>>>>
>>>>>>>> (The reason gpi_dma2 is checked first is because it's the
>>>>>>>> GPI
>>>>>>>> DMA
>>>>>>>> controller with the smallest address)
>>>>>>>>
>>>>>>>> BTW I just took the values from Windows DSDT, which is
>>>>>>>> quite
>>>>>>>> conservative.
>>>>>>>
>>>>>>> So, with DMA_PRIVATE set, is this series made redundant?
>>>>>>
>>>>>> I assume technically the trustzone is still protecting some
>>>>>> channels,
>>>>>> although the system stuck issue is fixed.
>>>>>>
>>>>>> This series should still be relevant, although not so
>>>>>> emergent.
>>>>>
>>>>> So now we're down to the case of the TZ reserving some of the
>>>>> GPI
>>>>> channels (presumably for locked down/TZ-driven QUPs) crashing
>>>>> the
>>>>> device on access, is that right?
>>>>
>>>> i.e. now, is requesting these channels through (wrongfully)
>>>> enabling
>>>> the devices in DT the only remaining concern?
>>>
>>> Yes, I think so; although I think few devices will use GPI on these
>>> devices (usually only one or two SPI controllers according to the
>>> DSDTs).
>>
>> IIRC there's a configuration table that lets OEMs decide which ones
>> should fall under the secure umbrella (although most never seem to
>> change the defaults).
> 
> Ah then what's the default value?
> 
> Radxa Dragon Q8B seems to have GPII0-5 enabled for all GPI controllers

This matches what I can find in the default config

Konrad

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

[Pengyu Luo]

On Sun, Jun 7, 2026 at 4:49 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
> > On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > >
> > > 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > > > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > > > >
> > > > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > > > >
> > > > > > The magnetic keyboard (USB HID) can't be connected somehow,
> > > > > > others
> > > > > > are
> > > > > > fine, such as the spi touchscreen (not upstream yet), which
> > > > > > utilizes
> > > > > > DMA definitely. My config is here
> > > > > > https://pastebin.com/SdjuyJYk
> > > > >
> > > > > Is this a defconfig?
> > > > >
> > > >
> > > > Yes.
> > > >
> > > > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too
> > > > > for
> > > > > exhibiting the problem (because there should be "public" GPI
> > > > > DMA
> > > > > consumers to trigger the stuck/reset).
> > > > >
> > > >
> > > > Is this still necessary? I checked the fedora discussion and your
> > > > GPI
> > > > DMA fix. And GPI DMA is only for the QUP-supported peripherals as
> > > > the
> > > > binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
> > >
> > > The devicetree without this fix seems to be still incorrect,
> > > because
> > > with the device tree fix even if the GPI DMA driver misbehaves the
> > > system won't be stuck (although it will iterate all GPI channels
> > > and
> > > then fail to function at all).
> > >
> >
> > Back to the start. You said some GPI interfaces aren't available to
> > HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick test,
> > and spi6 consumed it, no stuck or reset. Could you give me a
> > unavailable channel?
>
> I think channel 0b10000 of gpi_dma2 could be an example?
>
> It seems that 4 channels are tried on gpi_dma2 before hang on my
> gaokun3, but as gaokun3 has no known serial access, it's possible that
> 0b100000 or 0b1000 is problematic.
>

I see. I may test it on the weekend. Thanks!

Best wishes,
Pengyu

> (The reason gpi_dma2 is checked first is because it's the GPI DMA
> controller with the smallest address)
>
> BTW I just took the values from Windows DSDT, which is quite
> conservative.
>
> Thanks,
> Icenowy
>
> >
> > Best wishes,
> > Pengyu
>

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

[Pengyu Luo]

On Sun, Jun 7, 2026 at 4:49 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-06-06六的 21:51 +0800，Pengyu Luo写道：
> > On Sat, Jun 6, 2026 at 9:21 PM Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > >
> > > 在 2026-06-06六的 17:46 +0800，Pengyu Luo写道：
> > > > On 2026-06-06 17:28:35+08:00, Icenowy Zheng wrote:
> > > > > 在 2026-06-06六的 17:22 +0800，Pengyu Luo写道：
> > > > >
> > > > > > On 2026-06-02 21:21:27+08:00, Icenowy Zheng wrote:
> > > > > >
> > > > > > The magnetic keyboard (USB HID) can't be connected somehow,
> > > > > > others
> > > > > > are
> > > > > > fine, such as the spi touchscreen (not upstream yet), which
> > > > > > utilizes
> > > > > > DMA definitely. My config is here
> > > > > > https://pastebin.com/SdjuyJYk
> > > > >
> > > > > Is this a defconfig?
> > > > >
> > > >
> > > > Yes.
> > > >
> > > > > BTW it seems that CONFIG_ASYNC_TX_DMA needs to be selected too
> > > > > for
> > > > > exhibiting the problem (because there should be "public" GPI
> > > > > DMA
> > > > > consumers to trigger the stuck/reset).
> > > > >
> > > >
> > > > Is this still necessary? I checked the fedora discussion and your
> > > > GPI
> > > > DMA fix. And GPI DMA is only for the QUP-supported peripherals as
> > > > the
> > > > binding mentioned, devicetree/bindings/dma/qcom,gpi.yaml
> > >
> > > The devicetree without this fix seems to be still incorrect,
> > > because
> > > with the device tree fix even if the GPI DMA driver misbehaves the
> > > system won't be stuck (although it will iterate all GPI channels
> > > and
> > > then fail to function at all).
> > >
> >
> > Back to the start. You said some GPI interfaces aren't available to
> > HLOS, your mask is 0xb(0b1011), so I use 0x4(0b100) did a quick test,
> > and spi6 consumed it, no stuck or reset. Could you give me a
> > unavailable channel?
>
> I think channel 0b10000 of gpi_dma2 could be an example?
>
> It seems that 4 channels are tried on gpi_dma2 before hang on my
> gaokun3, but as gaokun3 has no known serial access, it's possible that
> 0b100000 or 0b1000 is problematic.
>
> (The reason gpi_dma2 is checked first is because it's the GPI DMA
> controller with the smallest address)
>

Sad to say, I cannot test gpi_dma2, only the stylus is under qup2
(spi20) which consumes gpi_dma2, but it is unsupported. So I have
tested gpi_dma0 with BIT(3)/BIT(4)/BIT(5) as you mentioned. No crash.

```
cat /sys/kernel/debug/dmaengine/summary
dma0 (800000.dma-controller): number of channels: 24

dma1 (900000.dma-controller): number of channels: 2
dma1chan0    | 998000.spi:tx
dma1chan1    | 998000.spi:rx

dma2 (a00000.dma-controller): number of channels: 24
```
Best wishes,
Pengyu