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

[Marek Vasut <marek.vasut@mailbox.org>]

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