linux-kernel - [PATCH v5 0/5] pci: Work around ASMedia ASM2824 PCIe link training failures

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-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2209061238050.2275@angie.orcam.me.uk>
Date:   Sat, 17 Sep 2022 13:03:05 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Bjorn Helgaas <bhelgaas@...gle.com>
cc:     Stefan Roese <sr@...x.de>, Jim Wilson <wilson@...iptree.org>,
        David Abdurachmanov <david.abdurachmanov@...il.com>,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH v5 0/5] pci: Work around ASMedia ASM2824 PCIe link training
 failures

Hi,

 This is v5 of the change to work around a PCIe link training phenomenon 
where a pair of devices both capable of operating at a link speed above 
2.5GT/s seems unable to negotiate the link speed and continues training 
indefinitely with the Link Training bit switching on and off repeatedly 
and the data link layer never reaching the active state.

 This was originally observed in a configuration featuring a downstream 
port of the ASMedia ASM2824 Gen 3 switch wired to the upstream port of the 
Pericom PI7C9X2G304 Gen 2 switch.  However in the course of review I have 
come to the conclusion that similarly to the earlier similar change to 
U-Boot it is indeed expected to be safe to apply this workaround to any 
downstream port that has failed link negotiation provided that:

1. the port is capable of reporting the data link layer link active 
   status (because unlike U-Boot we cannot busy-loop continuously polling 
   the link training bit),

and:

2. we don't attempt to lift the 2.5GT/s speed restriction, imposed as the
   basis of the workaround, for devices not explicitly known to continue 
   working in that case.

It is expected to be safe because the workaround is applied to a failed 
link, that is one that does not (at the time this code is executed) work 
anyway, so trying to bring it up cannot make the situation worse.  So this 
version of the workaround is attempted for all PCIe devices discovered, 
and only the lifting of the 2.5GT/s speed restriction is qualified by the 
vendor:device ID, currently one of the ASMedia ASM2824 device only.

 Broadening the scope of the quirk has in turn made it necessary to make 
some adjustments to code elsewhere and consequently what was originally a 
single patch has now become a small series instead.

 This has been verified with a SiFive HiFive unmatched board, booting with 
or without the workaround activated in U-Boot, which covered both the link 
retraining part of the quirk and the lifting of speed restriction already 
imposed by U-Boot.

 Please see individual change descriptions for further details.

 Questions or comments?  Otherwise please apply.

  Maciej