[PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[FUKAUMI Naoki]

Hi Mani,

On 11/26/25 22:54, Manivannan Sadhasivam wrote:
> On Wed, Nov 26, 2025 at 10:30:06PM +0900, FUKAUMI Naoki wrote:
>> Hi Niklas,
>>
>> I apologize for the delayed response.
>>
>> On 11/24/25 23:02, Niklas Cassel wrote:
>>> On Mon, Nov 24, 2025 at 06:07:44PM +0530, Manivannan Sadhasivam wrote:
>>>> While I suggested to revert the link up IRQ patch for rockchip earlier, I didn't
>>>> expect to drop the support for Qcom. The reason is, on Qcom SoCs, we have not
>>>> seen a case where people connect a random PCIe switch and saw failures. Most of
>>>> the Qcom usecases were around the M.2 and other proprietary connectors. There is
>>>> only one in-house PCIe switch that is being actively used in our products, but
>>>> so far, none of the bootloaders have turned them ON before kernel booting. So
>>>> kernel relies on the newly merged pwrctrl driver to do the job. Even though it
>>>> also suffers from the same resource allocation issue, this series won't help in
>>>> any way as pwrctrl core performs rescan after the switch power ON, and by that
>>>> time, it will be very late anyway.
>>>>
>>>> So I'm happy to take the rockhip patches from this series as they fix the real
>>>> issue that people have reported. But once the pwrctrl rework series gets merged,
>>>> and the rockchip drivers support them, we can bring back the reverted changes.
>>>
>>> FUKAUMI Naoki, just to confirm:
>>>
>>> Neither my suggested approach:
>>> https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/
>>>
>>> nor Shawn's suggested approach:
>>> https://lore.kernel.org/linux-pci/dc932773-af5b-4af7-a0d0-8cc72dfbd3c7@rock-chips.com/
>>>
>>> worked for you?
>>
>> Yes, I re-tested the two methods mentioned above, separately, on v6.18-rc7,
>> but neither of them resolved the issue in my environment (ROCK 5C +
>> ASM2806).
>>
>>> If so, I don't see many alternative but for Mani to apply patch 1 and
>>> patch 2 from this series.
>>
>> I believe applying patch 1 and patch 2 should be sufficient.
>>
>> ----
>>
>> Incidentally, (probably) while applying patch 1 and patch 2, I have
>> encountered the following issue several times:
>>
> 
> Do you see the below issue *after* applying the patches? I don't know how to
> interpret "while applying".
>   
>> [    1.709614] pcieport 0004:41:00.0: of_irq_parse_pci: failed with rc=134
>> [    1.710208] pcieport 0004:41:00.0: Unable to change power state from
>> D3cold to D0, device inaccessible
>>
> 
> Looks like the device was seen during bus scan, but then it went down
> afterwards.

Sorry, I meant "after". But I guess it occurred with vanilla kernel in 
the past:

  https://lore.kernel.org/linux-pci/4487DA40249CC821+19232169-a096-4737-bc6a-5cec9592d65f@radxa.com/
  https://gist.github.com/RadxaNaoki/b42252ce3209d9f6bc2d4c90c71956ae#file-gistfile1-txt-L551

This time I unset CONFIG_PCI_DYNAMIC_OF_NODES, but this error occurred 
at same location when kernel oops occurred.

It might be a problem with ROCK 5C, (or *my* ROCK 5C), so I'll test 
again with ROCK 5B.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> - Mani
>