From: Matthew W Carlis <mattc@purestorage.com>
To: macro@orcam.me.uk
Cc: ashishk@purestorage.com, bamstadt@purestorage.com,
bhelgaas@google.com, helgaas@kernel.org,
linux-pci@vger.kernel.org, mattc@purestorage.com,
msaggi@purestorage.com, sconnor@purestorage.com
Subject: Re: [PATCH 0/1] PCI: Add CONFIG_PCI_NOSPEED_QUIRK to remove pcie_failed_link_retrain
Date: Wed, 23 Jul 2025 13:18:37 -0600 [thread overview]
Message-ID: <20250723191837.35503-1-mattc@purestorage.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2507181435110.21783@angie.orcam.me.uk>
On Fri, 18 Jul 2025, Maciej W. Rozycki wrote:
> Bjorn, unfortunately sometimes you have to live with what you've got, in
> particular there's (I believe still) no good choice available to replace
> the HiFive Unmatched board and the PCIe splitter adapter chosen was the
> only one I could chase that is fully mechanically compatible with *ATX
> case slot space (i.e. you can actually properly mount it there next to the
> mainboard and no connector will clash with another part of the system).
>
> Matthew, please correct me if I'm wrong, but from discussion so far here
> and previously I infer the problematic part is not the essential part of
> the quirk, that is retraining at 2.5GT/s. It is leaving the speed clamp
> behind that is.
I'm just not sure what the benefit of the quirk is generally. It seems like
there are several problems with it in "well behaved" systems. I think for
people who build & sell servers they would go out and qualify a list of
devices which they will tell their customers "have been seen to work" &
therefore would be unlikely to see your specific issue. Another problem in my
mind with the quirk is that you're left trying to figure out if it should
have invoked the quirk before looking at the device interaction & so I think it
makes things a bit harder to debug.
In a way we're basically enabling future bad hardware by allowing the quirk to
run broadly on PCIe devices... Once its been around for a while will anyone ever
be able to confidently say its not necessary? In addition it sounds like both Ilpo
and I have observed LBMS to behave differently on different devices.
next prev parent reply other threads:[~2025-07-23 19:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-16 19:02 [PATCH 0/1] PCI: Add CONFIG_PCI_NOSPEED_QUIRK to remove pcie_failed_link_retrain Matthew W Carlis
2025-07-16 19:02 ` [PATCH 1/1] " Matthew W Carlis
2025-07-16 19:34 ` Bjorn Helgaas
2025-07-17 18:38 ` [PATCH 0/1] " Matthew W Carlis
2025-07-18 14:16 ` Maciej W. Rozycki
2025-07-23 19:18 ` Matthew W Carlis [this message]
2025-12-01 3:54 ` Maciej W. Rozycki
2025-07-17 17:30 ` [PATCH 1/1] " kernel test robot
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=20250723191837.35503-1-mattc@purestorage.com \
--to=mattc@purestorage.com \
--cc=ashishk@purestorage.com \
--cc=bamstadt@purestorage.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=msaggi@purestorage.com \
--cc=sconnor@purestorage.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.