From: "Pali Rohár" <pali@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Stefan Roese <sr@denx.de>, Bin Meng <bmeng.cn@gmail.com>,
Simon Glass <sjg@chromium.org>,
u-boot@lists.denx.de
Subject: Re: [PATCH] pci: Do not enable PCIe ASMedia ASM2824 workaround by default
Date: Sun, 1 May 2022 17:18:04 +0200 [thread overview]
Message-ID: <20220501151804.3hqoevejieictnox@pali> (raw)
In-Reply-To: <alpine.DEB.2.21.2204072329500.47162@angie.orcam.me.uk>
On Friday 08 April 2022 00:18:48 Maciej W. Rozycki wrote:
> On Thu, 7 Apr 2022, Stefan Roese wrote:
>
> > > Hello! What do you think about this change? I think it is good
> > > compromise between enable this workaround for all builds on all boards
> > > and enable it only based on device id. Or would it be better to restrict
> > > this workaround just for ASM2824 device like the last iteration of
> > > kernel patch?
> >
> > I'm not sure if we should name this "workaround" ASM2824, even though
> > it's currently (only) targeted exactly for this PCIe switch. It might
> > be helpful for other PCIe switches as well. So perhaps it's better to
> > give this function a more generic name instead? With this change, it
> > makes perhaps also sense to keep this function in pci_auto.c but also
> > rename the Kconfig option to some more generic version.
>
> By now I have become somewhat tired arguing and explaining matters over
> and over again as things have been moving as slow as molasses in this
> area, but one point I want to raise here is while it is indeed the ASM2824
> device that seems problematic, it may actually be downstream, so you won't
> know it's there until you go through the workaround, as observed with the
> root port of the SiFive FU740-C000 SOC (which has a separate workaround in
> U-boot, clearly for the same issue; cf. `pcie_sifive_force_gen1'). So it
> looks like the erratum is going to show up with some device combinations
> in which the device enumerator may not have a way to know an ASM2824 is
> there until the workaround applied to an upstream device has let the link
> work.
I see that Linux patch was not not merged yet and there are already
comments that this issue is probably board or arch specific and maybe
should be in arch/riscv linux dir:
https://lore.kernel.org/linux-pci/20220421202711.GA1415244@bhelgaas/
From that comment I have feeling that the issue could be really specific
to board or combination of connected devices (ASM2824+PI7C9X2G304) as
there is really no other report about this issue.
In any case it is weird.
> And as I previously already mentioned the Linux version of the workaround
> is only activated by the vendor:device ID because you cannot busy-loop
> polling on the Link Training bit in Linux (while you can do it in U-Boot,
> because U-Boot is not an OS).
Is is not _only_ because of this. For a longer time there is a direction
to specify exact list of _affected_ hw which needs workaround. And not
usage of wildcard which match all hardware, even unaffected. See for
example comments which are adding workaround for broken GIC HW:
https://lore.kernel.org/lkml/87ilsutb6w.wl-maz@kernel.org/
And this makes sense, workarounds should be targeted.
> Arguably I could have broadened it to cover
> all Gen 3+ devices and poll on the Data Link Layer Link Active bit, which
> doesn't require busy-looping for meaningful results, but that would still
> leave Gen 2 devices out and chances are the system boots from U-Boot with
> the generic workaround applied and the link already negotiated at 2.5GT/s.
>
> NB the ASM2824 switch has been used with option cards as well, e.g.
> <https://www.amazon.com/dp/B07PRN2QCV>, so it can be there in any system
> that has a connector of any kind that lets one use PCIe option cards.
>
> FWIW,
>
> Maciej
next prev parent reply other threads:[~2022-05-01 15:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-06 15:09 [PATCH] pci: Do not enable PCIe ASMedia ASM2824 workaround by default Pali Rohár
2022-04-07 6:33 ` Stefan Roese
2022-04-07 23:18 ` Maciej W. Rozycki
2022-05-01 15:18 ` Pali Rohár [this message]
2022-05-05 11:46 ` Maciej W. Rozycki
2022-05-14 13:20 ` Maciej W. Rozycki
2022-08-27 12:30 ` [PATCH v2] pci: Do not enable PCIe GEN3 link retrain " Pali Rohár
2022-08-30 2:30 ` Simon Glass
2022-08-30 9:04 ` Maciej W. Rozycki
2022-08-30 9:19 ` Pali Rohár
2022-08-30 11:15 ` Stefan Roese
2022-08-30 11:56 ` Pali Rohár
2022-09-17 13:03 ` Maciej W. Rozycki
2022-09-17 13:02 ` Maciej W. Rozycki
2022-09-17 13:02 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220501151804.3hqoevejieictnox@pali \
--to=pali@kernel.org \
--cc=bmeng.cn@gmail.com \
--cc=macro@orcam.me.uk \
--cc=sjg@chromium.org \
--cc=sr@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).