[PATCH 2/2] PCI: brcmstb: Add panic/die handler to driver

Manivannan Sadhasivam mani at kernel.org
Wed Aug 6 22:26:46 PDT 2025


On Wed, Aug 06, 2025 at 01:41:35PM GMT, Florian Fainelli wrote:
> On 8/6/25 11:50, Bjorn Helgaas wrote:
> > > I'm not sure I understand the "racy" comment.  If the PCIe bridge is
> > > off, we do not read the PCIe error registers.  In this case, PCIe is
> > > probably not the cause of the panic.   In the rare case the PCIe
> > > bridge is off  and it was the PCIe that caused the panic, nothing
> > > gets reported, and this is where we are without this commit.
> > > Perhaps this is what you mean by "mostly-works".  But this is the
> > > best that can be done with SW given our HW.
> > 
> > Right, my fault.  The error report registers don't look like standard
> > PCIe things, so I suppose they are on the host side, not the PCIe
> > side, so they're probably guaranteed to be accessible and non-racy
> > unless the bridge is in reset.
> 
> To expand upon that part, the situation that I ran in we had the PCIe link
> down and therefore clock gated the PCIe root complex hardware to conserve
> power. Eventually I did hit a voluntary panic, and since all panic notifiers
> registered are invoked in succession, the one registered for the PCIe RC was
> invoked as well and accessing clock gated registers would not work and
> trigger another fault which would be confusing and mingle with the panic I
> was trying to debug initially. Hence this check, and a clock gated PCIe RC
> would not be logging any errors anyway.

May I ask how you are recovering from link down? Can the driver detect link down
using any platform IRQ?

- Mani

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



More information about the linux-arm-kernel mailing list