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

[FUKAUMI Naoki]

Hi all,

I'm very sorry, but my ROCK 5C appears to be unreliable. (It worked fine 
with vanilla v6.13, so I thought it was fine.)

I replaced it with another 5C (Lite), and now every method (Niklas's 
patch, Shawn's patch, and applying patch 1 and 2) seems to work.

Testing with the 5C Lite is still not enough, further testing is 
required, but I will probably need to revise my test results.

(Those seem to work on ROCK 5A/5B, but they also need further testing.)

I truly apologize for my unreliable testing.

Best regards,

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

On 11/26/25 22:30, 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 at 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:
> 
> [    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
> 
> I am still investigating this matter, and the conditions under which it 
> occurs are currently unknown.
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
>> Kind regards,
>> Niklas
>>
>