[BUG] PCI: spacemit-k1: port C probe hard-hangs a CPU with one endpoint on Milk-V Jupiter

[Encrow Thorne]

On Mon Sep 21, 2026 at 4:03 PM CST, Manivannan Sadhasivam wrote:
> On Mon, Sep 21, 2026 at 01:55:42PM +0800, Encrow Thorne wrote:
>
> [...]
>
>> Hi Bruno,
>> 
>> The issue was caused by a missing hardware configuration in the K1 PCIe
>> initialization.
>> 
>> The PMU PCIE_CONTROL_LOGIC register contains an IGNORE_PERSTN bit (BIT(2)).
>> The hardware manual describes it as follows:
>> 
>> “When set to 1, the PCIe controller and PHY ignore the PERSTN signal from
>> the link partner in both RC and EP modes.”
>> 
>> This bit was not configured during RC initialization. As a result, the
>> controller and PHY could still be affected by the PERSTN input during the
>> early DBI accesses. With the Intel I225-V installed, the first DBI access
>> could remain pending and hang the CPU.
>> 
>

Hi Mani,

> What does this 'PERSTN' bit controls? PERST# or something else? PERST# is
> controlled only by the Root Complex btw. Also, why does this missing register
> configuration only affecting Intel I225-V endpoint and not others?
>
> - Mani

PCIE_IGNORE_PERSTN masks the PERST# pad input to the local K1
controller and PHY. It does not control the external PERST# output.
On K1, this input path remains active even in RC mode, so a low
level on the pad can also hold the local controller in reset.

We found a 1 kOhm pull-down on the PERST# line of the particular
Intel card we tested. Together with the Jupiter board's 10 kOhm
pull-up, this kept PERST# low from power-on, including during the
first DBI access. The other devices we tested did not hold the
line low in this way.

After removing the card's pull-down, PERST# reached 3.3 V.

Regards,
Encrow Thorne