Received-SPF: pass (google.com: domain of linux-kernel+bounces-104233-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
Date: Fri, 15 Mar 2024 11:58:31 +0200 (EET)
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
cc: Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org, 
    LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] PCI: Use the correct bit in Link Training not active
 check
In-Reply-To: <alpine.DEB.2.21.2403142145010.37739@angie.orcam.me.uk>
Message-ID: <c81ecb2a-9365-dbb0-2207-ed692c8c7487@linux.intel.com>
References: <20240301150641.4037-1-ilpo.jarvinen@linux.intel.com> <alpine.DEB.2.21.2403011622560.42226@angie.orcam.me.uk> <c740c6e4-ca1a-33ad-8437-4a1219c16eb1@linux.intel.com> <alpine.DEB.2.21.2403060951310.43702@angie.orcam.me.uk>
 <01666075-504d-a434-d039-2e25db931f23@linux.intel.com> <c4fe9080-245f-7089-84c1-bb47dcf2cd83@linux.intel.com> <alpine.DEB.2.21.2403142145010.37739@angie.orcam.me.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323328-1935341792-1710496711=:1018"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-1935341792-1710496711=:1018
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 14 Mar 2024, Maciej W. Rozycki wrote:

> On Thu, 14 Mar 2024, Ilpo J=C3=A4rvinen wrote:
>=20
> > One more point to add here, I started to wonder today why that use_lt=
=20
> > parameter is needed at all for pcie_retrain_link()?
> >=20
> > Once the Target Speed has been changed to 2.5GT/s which is what the qui=
rk=20
> > does before calling retraining, LT too should work "normally" after tha=
t.
>=20
>  We don't know if the link is going to become stable with the TLS update=
=20
> to 2.5GT/s and we want to ensure that the link has reached the active=20
> state before claiming victory; LT clear does not mean the link is active,=
=20
> it only means what it means, that is that the link isn't being trained at=
=20
> the moment.

LT clear means retraining has ended which is the condition=20
pcie_retrain_link() should terminate at. It tried and finished retraining=
=20
as proven by LT clear.

>  Also we don't want to reset the TLS to the maximum before the link has=
=20
> become active.

I'm not suggesting to change the if DLLLA check that is within the quirk=20
so it will remain the same even if pcie_retrain_link() would no longer=20
have the use_lt parameter.

If LT clear after retraining does not imply DLLLA set, then this again=20
falls into the quirk territory and IMO the quirk itself should be what=20
makes the additional call to wait for DLLLA, not pcie_retrain_link().
I suspect though that DL clear does imply DLLLA set (after the target=20
speed was lowered) so my expectation is that the extra wait wouldn't be=20
necessary at that point.

>  Does this answer your question?

What I'm trying to achieve is having pcie_retrain_link() focus on=20
retraining and quirk on steps required by the quirk. Currently they're=20
kind of mixed if we assume the assumption that LT clear doesn't imply=20
active link is true. That tells quirk would need additional step,=20
that is, wait for DLLLA after the retraining has completed which is=20
currently hidden into pcie_retrain_link() rather than explicitly=20
called by the quirk.

--=20
 i.

--8323328-1935341792-1710496711=:1018--