All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: "Marek Behún" <kabel@kernel.org>,
	linux-pci@vger.kernel.org, "Pali Rohár" <pali@kernel.org>,
	Rötti <espressobinboardarmbiantempmailaddress@posteo.de>,
	"Zachary Zhang" <zhangzg@marvell.com>,
	"Edward Cree" <ecree.xilinx@gmail.com>,
	"Martin Habets" <habetsm.xilinx@gmail.com>,
	"Keith Busch" <kbusch@kernel.org>
Subject: Re: [PATCH 1/2] PCI: Call MPS fixup quirks early
Date: Fri, 2 Jul 2021 11:24:48 -0500	[thread overview]
Message-ID: <20210702162448.GA192062@bjorn-Precision-5520> (raw)
In-Reply-To: <237a49d8a113f44b55e537f6f2f99b7db9d97485.camel@decadent.org.uk>

On Fri, Jul 02, 2021 at 05:39:43PM +0200, Ben Hutchings wrote:
> On Thu, 2021-07-01 at 10:25 -0500, Bjorn Helgaas wrote:
> [...]
> > After 27d868b5e6cfa, pci_configure_device() did actually call
> > pcie_set_mps(), which updates the Device Control register (possibly
> > restricted by dev->pcie_mpss, which is set by this quirk).
> > 
> > The fixup_mpss_256() quirk was added in 2011 by a94d072b2023 ("PCI:
> > Add quirk for known incorrect MPSS").  Interesting that 27d868b5e6cfa
> > was merged in 2015 but apparently nobody noticed until now.  I guess
> > those Solarflare devices aren't widely used?
> [...]
> 
> The key thing is that this quirk was working around an issue with
> legacy interrupts, while the sfc and sfc-falcon drivers have always
> preferred to use MSIs if available.  (But I also don't think many
> SFC4000-based NICs were sold, and they were EOL'd about 10 years ago.)

Just out of curiosity, do you happen to remember the legacy interrupt
connection?  MPS has to do with the maximum TLP size, and it's not
obvious to me why using INTx vs MSI would matter there.

I guessing the scenario is that SFC4000 uses either either INTx or
MSI to signal some kind of I/O completion, the ISR puts more I/Os in
the queue, the SFC4000 does a DMA read, and chokes on a Completion TLP
that's too big?  But somehow if it uses MSI, it can handle bigger
TLPS?

Not a big deal; I think it's obvious that we need Marek's patch to fix
the ordering issue.

Bjorn

  reply	other threads:[~2021-07-02 16:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24 17:14 [PATCH 1/2] PCI: Call MPS fixup quirks early Marek Behún
2021-06-24 17:14 ` [PATCH 2/2] PCI: Add Max Payload Size quirk for ASMedia ASM1062 SATA controller Marek Behún
2021-07-24 11:14   ` Pali Rohár
2021-07-26 17:24   ` Bjorn Helgaas
2021-07-26 21:13     ` Pali Rohár
2021-07-01 15:25 ` [PATCH 1/2] PCI: Call MPS fixup quirks early Bjorn Helgaas
2021-07-02 15:39   ` Ben Hutchings
2021-07-02 16:24     ` Bjorn Helgaas [this message]
2021-07-02 21:53       ` Ben Hutchings

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=20210702162448.GA192062@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=ben@decadent.org.uk \
    --cc=ecree.xilinx@gmail.com \
    --cc=espressobinboardarmbiantempmailaddress@posteo.de \
    --cc=habetsm.xilinx@gmail.com \
    --cc=kabel@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=zhangzg@marvell.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.