Re: [PATCH 02/11] PCI: rcar-gen4: Drop the APP-based link_up check

[Marek Vasut]

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

Hello Den-san,

[...]

> > > That said, I agree that in general we should follow the R-Car reference manual
> > > where possible, and your draft makes sense for that purpose. If we go that way,
> > > I have one question: would we need a polling loop with a timeout
> > > (PCIE_LINK_WAIT_MAX_RETRIES * PCIE_LINK_WAIT_SLEEP_MS) in
> > > rcar_gen4_pcie_start_link(), similar to dw_pcie_wait_for_link()?
> >
> > This is a good point, and I think we probably shouldn't do it this way,
> > because we can reuse the DWC core code for that purpose.
> >
> > How about extending the .link_up callback, and check both the SMLH/RDLH bits
> > there (to fulfill the datasheet compliance, dw_pcie_start_link() is always
> > followed by dw_pcie_wait_for_link() which calls the .link_up() callback) and
> > the DEBUG1 bits (to make sure we check the current state of the link) ?
> >
> > That should cover all our concerns (datasheet compliance, DEBUG1 current
> > state of link check, polling), shouldn't it ?
>
> If you mean AND-ing the SMLH/RDLH check with the DEBUG1 check, that sounds
> reasonable. We could clear the APP latches in .start_link(), before enabling
> LTSSM, and leave them latched across .link_up() calls.

Yes, that.

> Thanks for the suggestion!
>
> > > P.S. I'll rebase v2 onto the latest pci/controller/dwc-rcar-gen4.
> >
> > Thank you, and I apologize for the inconvenience.
>
> No worries at all. I just hadn't caught up with your X5H series.
> I've now rebased v2 onto next-20260925, since the series also needs
> b43aa6a6ebe8 ("arm64: dts: renesas: r8a779f0: Add GICv3 ITS and update PCIe nodes"),
> as noted in the cover letter.

Understood.

--
Best regards,
Marek Vasut