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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The patch consists entirely of temporary debugging instrumentation and is explicitly marked as 'not for merging'.

Pre-existing issues:
- [High] DBI register accesses before full Root Complex configuration cause dropped writes and a hard CPU hang with certain endpoints.
--

--- Patch [1]: [BUG] PCI: spacemit-k1: port C probe hard-hangs a CPU with one endpoint on Milk-V Jupiter ---
commit f0ecce23df303a660d238225801529617e3ee9df
Author: Bruno Banelli <bbanelli@gmail.com>

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

This patch adds debug instrumentation to k1_pcie_init() in the spacemit-k1
PCIe driver to localize a hard CPU hang during probe on the Milk-V Jupiter
board. The commit message details extensive testing and indicates the hang
occurs on the first DBI write. The diff itself consists of temporary
dev_info calls to trace the execution flow.

> diff --git a/drivers/pci/controller/dwc/pcie-spacemit-k1.c b/drivers/pci/controller/dwc/pcie-spacemit-k1.c
> index 0564c46e2f484..e35307d693360 100644
> --- a/drivers/pci/controller/dwc/pcie-spacemit-k1.c
> +++ b/drivers/pci/controller/dwc/pcie-spacemit-k1.c
> @@ -127,17 +127,21 @@ static int k1_pcie_init(struct dw_pcie_rp *pp)
>  {
>  	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>  	struct k1_pcie *k1 = to_k1_pcie(pci);
> +	struct device *dev = pci->dev;
>  	u32 reset_ctrl;
>  	u32 val;
>  	int ret;
>  
> +	dev_info(dev, "K1DBG 1 toggle_soft_reset\n");

[Severity: High]
Since this patch consists entirely of temporary debugging instrumentation and
the commit message explicitly mentions it is "not for merging", should this
patch be dropped from the merge queue?

>  	k1_pcie_toggle_soft_reset(k1);
>  
> +	dev_info(dev, "K1DBG 2 enable_resources\n");
>  	ret = k1_pcie_enable_resources(k1);
>  	if (ret)
>  		return ret;
>  
>  	/* Set the PCI vendor and device ID */
> +	dev_info(dev, "K1DBG 3 first DBI write (vendor/device ID)\n");
>  	dw_pcie_dbi_ro_wr_en(pci);
>  	dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, PCI_VENDOR_ID_SPACEMIT);
>  	dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, PCI_DEVICE_ID_SPACEMIT_K1);
>  	dw_pcie_dbi_ro_wr_dis(pci);

[Severity: High]
This is a pre-existing issue, but does performing early DBI writes (such as
the Vendor/Device ID here) before asserting PERST#, configuring Root Complex
mode, and completing PHY initialization cause the CPU to hard-hang waiting
for an unanswered completion on certain endpoints?

Is it possible to defer these DBI register accesses until after the full Root
Complex configuration is completed to prevent the CPU from wedging?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825052249.66921-1-bbanelli@gmail.com?part=1