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@xxxxxxxxxxx> 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