Re: [PATCH v3] PCI: Skip Target Speed quirk on clamped ports with no link

On 8/11/26 08:42, Andreas Wild wrote:
> On Mon, 11 Aug 2026, Aoxtj wrote:
> 
>> Diagnostic result: link is genuinely down, not recovering.
>>
>> [1.623701] diag: pre  ret=-110 DLLLA=0 sta=0x9023 ctl2=0x0023
>> [3.734697] diag: post DLLLA=0 after 1010ms sta=0x9823
>> [3.734702] diag: post ctl2=0x0021
> 
> So the link really isn't coming back at all rather than too late for the
> bus scan.
> [...]
> If you would like something to try, the change below skips lifting the
> restriction if HASD is set.  It applies to your tree (I checked it against
> v7.1.6 and on top of v3). Mainline would need a small adaptation, since
> that block no longer has the LNKCAP test.

Side note: what's the status of all this? From the outside things looks
stalled, but maybe there was progress and I just missed it.

Are we waiting for a reply from Aoxtj before moving on with the fix at
the start of the thread? And whatever the answer is: would it make sense
to move on with that independently to get the other regression (boot
time delay) resolved?

Ciao, Thorsten
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -115,6 +115,11 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
>  	pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
>  	if ((lnkctl2 & PCI_EXP_LNKCTL2_TLS) == PCI_EXP_LNKCTL2_TLS_2_5GT &&
>  	    (lnkcap & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
> +		if (lnkctl2 & PCI_EXP_LNKCTL2_HASD) {
> +			pci_info(dev, "2.5GT/s restriction left, firmware set HASD\n");
> +			return ret;
> +		}
> +
>  		pci_info(dev, "removing 2.5GT/s downstream link speed restriction\n");
>  		ret = pcie_set_target_speed(dev, PCIE_LNKCAP_SLS2SPEED(lnkcap), false);
>  		if (ret)
> 
> Some things to consider:
> 
> I cannot verify the change myself - it compiles without warnings and that
> is all I can say.
> 
> HASD is specified as disabling *hardware autonomous* speed changes, so it
> does not strictly forbid a software-initiated retrain.  Interpreting it as
> "firmware meant this" is just my guess.
> 
> As I said before, I have no background in this code.  I came to it through
> one boot-time regression on my own machine, and that is the extent of it.
> 
> So please take it as "here is one thing that could help this particular
> case", not as a view on how the quirk ought to work.  Maciej and Bjorn are
> far better placed to judge whether the answer is this, or restoring the
> device ID match, or something else entirely.
> 
> One further thought for people who know the code better than I do:
> 
> Since retraining apparently cannot recover the link once it is wedged,
> would a secondary bus reset be the appropriate recovery in the error path?
> 
> Best regards,
> Andreas
>