Re: [PATCH] arm64: dts: qcom: sc8280xp: Flatten usb controller nodes

[Manivannan Sadhasivam]

On Mon, Jul 20, 2026 at 12:07:06PM +0200, Konrad Dybcio wrote:
> On 7/1/26 6:12 PM, Konrad Dybcio wrote:
> > On 7/1/26 6:04 PM, Xilin Wu wrote:
> >> On 7/1/2026 11:10 PM, Konrad Dybcio wrote:
> >>> On 5/7/26 4:29 PM, Xilin Wu wrote:
> >>>> Flatten usb controller nodes and update to using latest bindings
> >>>> and flattened driver approach.
> >>>>
> >>>> Signed-off-by: Xilin Wu <sophon@xxxxxxxxx>
> >>>> ---
> >>>
> >>> I tested this on a CRD and an x13s, both work fine across suspend.
> >>>
> >>> Turned out in my local experiments I made a typo in the name of the
> >>> interrupt that was carried over to the big node..
> >>>
> >>> Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
> >>> Tested-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> # X13s, CRD8280
> >>>
> >>> Konrad
> >>>
> >>
> >> Unfortunately as I mentioned on IRC [1], this actually causes random NoC timeout on reboot, which seems to be related to pcie.
> >>
> >> [1] https://oftc.catirclogs.org/linux-msm/2026-06-11#35405057;
> > 
> > Ah, you mentioned this:
> > 
> > https://gist.github.com/strongtz/50bbd71a9f41d0d1aa9849b8cf1dce21
> > 
> > This is an attempt to read CONFIG_SPACE+0x0.. I don't really know..
> 
> Could you try adding something like this
> 
> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> index b123da16b63b..5e08cb239e78 100644
> --- a/drivers/pci/access.c
> +++ b/drivers/pci/access.c
> @@ -43,6 +43,7 @@ int noinline pci_bus_read_config_##size \
>         if (PCI_##size##_BAD)                                           \
>                 return PCIBIOS_BAD_REGISTER_NUMBER;                     \
>                                                                         \
> +       dev_err(&bus->dev, "Reading configspace+0x%x as %s\n", pos, #size); \
>         pci_lock_config(flags);                                         \
>         res = bus->ops->read(bus, devfn, pos, len, &data);              \
>         if (res)                                                        
> 
> (perhaps with a WARN_ON(1) to get a stack trace and only print for the
> crashing reg)?
> 

We've seen these kind of late access causing NoC crash on S2R enabled platforms
before, but only during system suspend, not reboot. Due to various reasons,
kernel tries to mask the PCIe device's MSIs very late during the suspend cycle.
If the PCIe bus resources like ICC is disabled at that point, the config access
will cause the NoC crash.

But here, the crash seems to be happening in the reboot (shutdown) path. We
don't have the shutdown handler in the pcie-qcom driver. So the PCIe controller
driver is not disabling any resources here. Since the crash is being caused due
to this USB patch, I would assume that the USB driver ends up disabling an
unvoted shared PCIe resource in the shutdown path, causing the crash.

We need to find out which resource is being left unvoted by the PCIe controller
here.

- Mani

-- 
மணிவண்ணன் சதாசிவம்