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

[Marek Vasut]

On 9/18/26 5:20 AM, Koichiro Den wrote:
> On R-Car, intreq_pcim_sub carries both the integrated MSI receiver and
> the controller's reset requests (smlh_req_rst_not, link_req_rst_not), so
> the generic DesignWare chained handler reads the MSI status from DBI as
> soon as the link goes down. On R-Car S4 that is a hazard: DBI accesses
> issued within a few hundred microseconds of an unexpected link down do
> not complete and hang the host. In testing, the first Root Port config
> read after powering off the link partner hung unless delayed by ~300 us.

Out of curiosity, do they trigger SError, and does the firmware (TFA) 
trap/fix those up in EL3?

> Use the pre-MSI callback to check the APP reset status before DBI is
> touched. When a reset request is latched, mask the sources, ack the
> request and schedule recovery work. The work calls
> pci_host_handle_link_down(), which runs the AER-style recovery and
> resets the controller through reset_root_port(). If the reset fails, the
> sources stay masked so nothing touches the unrecovered controller.
>
> Only unmasked status bits are handled and pending latches are cleared
> when re-arming, so requests recorded during probe or the reset itself do
> not trigger another recovery. Teardown only disables link-down
> detection: MSI delivery has to keep working while devices are removed.
>
> When iMSI-RX is not used (external MSI controller or pci=nomsi), the
> DesignWare core does not request intreq_pcim_sub, so request it in the
> driver.

Would it make sense to request the line unconditionally, to simplify the 
driver(s) ?

I also have to wonder, is this specific to R-Car or could it be this is 
a generic property of the DWC controller and this should go into the DWC 
core ?

Thank you for your help !