All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew W Carlis <mattc@purestorage.com>
To: helgaas@kernel.org
Cc: ashishk@purestorage.com, bamstadt@purestorage.com,
	bhelgaas@google.com, linux-pci@vger.kernel.org,
	macro@orcam.me.uk, 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: Thu, 17 Jul 2025 12:38:02 -0600	[thread overview]
Message-ID: <20250717183802.22810-1-mattc@purestorage.com> (raw)
In-Reply-To: <20250716193411.GA2551185@bhelgaas>

On Wed, 16 Jul 2025, Bjorn Helgaas wrote:
> Maybe we should just accept that broken hardware exists and add quirks
> to limit link speed or tell the user to buy a working device.

I was actually wondering if we should define a new kind of
DECLARE_PCI_FIXUP_<LINKUP> which allows vendors/users to implement an
appropriate link recovery for their circumstances. In one of our storage
appliance product-lines we actually have a kind of quirk of our own which is
implemented to work-around some older Gen3 PCIe switches that had some official
erratum. Honestly we would like to not have to carry these patches, but there
wasn't an obvious way to upstream them. We could probably re-work them to fit
into a kind of new fixup.

My belief is that we try to not bend the generic handling in the kernel around
specific device issues because once implemented we are essentially enabling
devices in the future to have such bugs/interactions.

In the case of this ASMedia/Pericom switch combination I'm told from others
internally that its possibly that changing the link presets or other settings
may resolve the ltssm looping issue, but it would probably require
ASMedia/Pericom to look into.

Cheers!
- Matt

  reply	other threads:[~2025-07-17 18:38 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     ` Matthew W Carlis [this message]
2025-07-18 14:16       ` [PATCH 0/1] " Maciej W. Rozycki
2025-07-23 19:18         ` Matthew W Carlis
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=20250717183802.22810-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.