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(-)
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
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
在 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
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
在 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
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.
在 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.
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
在 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
© 2016 - 2026 Red Hat, Inc.