Re: [PATCH 07/11] PCI: rcar-gen4: Recover the Root Port on link down

[Marek Vasut]

On 9/28/26 6:06 AM, Koichiro Den wrote:

Hello Den-san,

> > > > Out of curiosity, do they trigger SError, and does the firmware (TFA)
> > > > trap/fix those up in EL3?
> > >
> > > I haven't confirmed whether those DBI accesses trigger an SError.
> > > The BL31 on the Spider I'm using should be based on rcar-s4_v2.5 [1] from the
> > > Spider BSP (as I haven't updated it). I just checked that this version also sets
> > > HANDLE_EA_EL3_FIRST=1, plus plat_ea_handler() is empty. So IIUC an SError would
> > > be taken to EL3
> >
> > Yes.
> >
> > > , and the normal path would return to the kernel without fixing
> > > the underlying error.
> >
> > That is correct.
> >
> > R-Car Gen3 does PCIe link error fixup in TFA, it looks this way:
> >
> > https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf
>
> Thanks for the info! It does look similar, so now I'm wondering about (*) below.
>
> > > And, regardless of whether it's a synchronous abort or an SError:
> > > - There was no crash report (via report_unhandled_exception) on the console.
>
> (*) I checked that CRASH_REPORTING is enabled in that version, but there might
>      be a separate issue with report_unhandled_exception.

It could be that the DBI access triggers some other type of exception, 
not SError.

> > > - Once that DBI access in the small window hangs, it never recovers,
> > >     whereas adding udelay(300) before the access avoids the hang. So I
> > >     doubt it's just retrying the same access after a transient synchronous
> > >     abort as well (though I can't rule it out).
> >
> > ( It just crossed my mind, this sounds similar to 0056d29f8c1b ("PCI:
> > rcar-gen4: Assure reset occurs before DBI access") )
>
> Yes, exactly. I'm almost ready to send v2, with an explicit mention of that
> commit in the cover letter.
>
> A delay-based approach might be an option here, but I suspect it would involve
> about the same level of complexity in the end. The reset request shares
> intreq_pcim_sub with iMSI-RX, while AER arrives on another IRQ, so we'd still
> need to coordinate both paths to avoid unsafe DBI access.

ACK

--
Best regards,
Marek Vasut