linux-kernel - Re: [PATCH 1/1] PCI: Use the correct bit in Link Training not active check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2403011622560.42226@angie.orcam.me.uk>
Date: Fri, 1 Mar 2024 17:22:37 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
cc: Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] PCI: Use the correct bit in Link Training not active
 check

On Fri, 1 Mar 2024, Ilpo Järvinen wrote:

> Besides Link Training bit, pcie_retrain_link() can also be asked to
> wait for Data Link Layer Link Active bit (PCIe r6.1 sec 7.5.3.8) using
> 'use_lt' parameter since the merge commit 1abb47390350 ("Merge branch
> 'pci/enumeration'").

 Nope, it was added with commit 680e9c47a229 ("PCI: Add support for 
polling DLLLA to pcie_retrain_link()"), before said merge.

> pcie_retrain_link() first tries to ensure Link Training is not
> currently active (see Implementation Note in PCIe r6.1 sec 7.5.3.7)
> which must always check Link Training bit regardless of 'use_lt'.
> Correct the pcie_wait_for_link_status() parameters to only wait for
> the correct bit to ensure there is no ongoing Link Training.

 You're talking the PCIe spec here and code is talking a bad device case.

> Since waiting for Data Link Layer Link Active bit is only used for the
> Target Speed quirk, this only impacts the case when the quirk attempts
> to restore speed to higher than 2.5 GT/s (The link is Up at that point
> so pcie_retrain_link() will fail).

 NAK.  It's used for both clamping and unclamping and it will break the 
workaround, because the whole point there is to wait until DLLA has been 
set.  Using LT is not reliable because it will oscillate in the failure 
case and seeing the bit clear does not mean link has been established.  

 What are you trying to achieve here and what problem is it to fix?

  Maciej