[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221009141434.ddijf6w76cz5ch2v@pali>
Date: Sun, 9 Oct 2022 16:14:34 +0200
From: Pali Rohár <pali@...nel.org>
To: Bjorn Helgaas <bhelgaas@...gle.com>,
Krzysztof Wilczyński <kw@...ux.com>
Cc: "Maciej W. Rozycki" <macro@...am.me.uk>, 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: Re: [PATCH v5 0/5] pci: Work around ASMedia ASM2824 PCIe link
training failures
Bjorn, Krzysztof: could you please look at this patch series and say
what do you think about it? It is quite strange issue for which is
defined PCI_ANY_ID quirk... And is needs to be somehow workarounded.
On Saturday 17 September 2022 13:03:05 Maciej W. Rozycki wrote:
> 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
Powered by blists - more mailing lists