On Tue, Sep 15, 2026 at 11:04:25PM +0800, Xilin Wu wrote:
> On 9/10/2026 11:04 PM, Manivannan Sadhasivam wrote:
> > On Tue, Sep 01, 2026 at 04:47:54PM +0800, Xilin Wu wrote:
> > > The TC9563 PCI power-control driver powers off external downstream ports
> > > whose device tree nodes have status = "disabled".
> > >
> > > On the Radxa Dragon Q8B, reading the Vendor ID from one of these
> > > powered-off port functions during PCI enumeration raises an Arm SError
> > > instead of returning an all-ones PCI error response. This prevents the
> > > board from completing boot.
> > >
> > > Commit 1a8c251cff20 ("PCI: move OF status = "disabled" detection to
> > > dev->match_driver") made disabled PCI functions remain discoverable so
> > > PCI fixups can still be applied, while suppressing driver binding later.
> > > Preserve that behavior for endpoint functions.
> > >
> > > For an unavailable node describing a PCI-to-PCI bridge, however, the
> > > node also represents a subordinate bus that must not be enumerated.
> > > Check the device tree node before reading the Vendor ID and return a PCI
> > > error response without accessing config space when such a bridge is
> > > disabled.
> > >
> > > Functions not described by device tree and disabled endpoint functions
> > > remain discoverable.
> > >
> > > Signed-off-by: Xilin Wu <[email protected]>
> >
> > Does this patch help?
> > https://lore.kernel.org/linux-pci/[email protected]/
> >
> > - Mani
> >
>
> Thanks for the pointer. I don't think it helps in this case. That patch
> enables the Qualcomm ECAM blocker when the Root Port link goes down. Here,
> the link between the Root Port and the TC9563 remains up; only some TC9563
> downstream port functions are powered off, and probing those functions
> triggers the SError. Therefore, we still need to avoid these config-space
> reads.
>
Sorry, I misread the problem statement and your analysis about the patch I
pointed out is correct. Here, there won't be any LDn as the PCIe link between
the RP and Switch upstream would be active.
But looking at the patch, I think it is going in the right direction because,
this issue of probing the unavailable PCI devices is not Qcom specific. So
adding the check in the generic PCI code is the right thing to do.
- Mani
--
மணிவண்ணன் சதாசிவம்
