linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Nirmal Patel <nirmal.patel@linux.intel.com>,
	<linux-pci@vger.kernel.org>, <paul.m.stillwell.jr@intel.com>
Subject: Re: [PATCH v2] PCI: vmd: Clear PCI_INTERRUPT_LINE for VMD sub-devices
Date: Thu, 12 Sep 2024 11:10:21 -0700	[thread overview]
Message-ID: <66e32e8d5e19a_3263b29452@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20240912172534.ma3jc7po3ca2ytlh@thinkpad>

Manivannan Sadhasivam wrote:
[..]
> I don't think the issue should be constrained to VMD only. Based on my
> conversation with Nirmal [1], I understood that it is SPDK that makes wrong
> assumption if the device's PCI_INTERRUPT_LINE is non-zero (and I assumed that
> other application could do the same).

I am skeptical one can find an example of an application that gets
similarly confused. SPDK is not a typical consumer of PCI device
information.

> In that case, how it can be classified as the "idiosyncracy" of VMD?

If VMD were a typical PCIe switch, firmware would have already fixed up
these values. In fact this problem could likely also be fixed in
platform firmware, but the history of VMD is to leak workaround after
workaround into the kernel.

> SPDK is not tied to VMD, isn't it?

It is not, but SPDK replaces significant pieces of the kernel with
userspace drivers. In this respect a VMD driver quirk in SPDK is no
different than the NVME driver quirks it already needs to carry in its
userspace NVME driver.

Now, if you told me that the damage was more widespread than a project
that is meant to replace kernel drivers, then a kernel fix should be
explored. Until then, let SPDK carry the quirk until it becomes clear
that there are practical examples of wider damage.

  reply	other threads:[~2024-09-12 18:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-20 22:32 [PATCH v2] PCI: vmd: Clear PCI_INTERRUPT_LINE for VMD sub-devices Nirmal Patel
2024-08-22  9:48 ` Manivannan Sadhasivam
2024-08-22 18:30   ` Nirmal Patel
2024-09-12 14:36     ` Manivannan Sadhasivam
2024-09-12 15:31       ` Nirmal Patel
2024-09-12 16:47         ` Manivannan Sadhasivam
2024-09-12 17:11       ` Dan Williams
2024-09-12 17:25         ` Manivannan Sadhasivam
2024-09-12 18:10           ` Dan Williams [this message]
2024-09-12 19:15             ` Nirmal Patel
2024-09-13  0:01               ` Dan Williams
2024-09-13 10:55                 ` Manivannan Sadhasivam
2024-09-13 16:02                   ` Nirmal Patel

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=66e32e8d5e19a_3263b29452@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=nirmal.patel@linux.intel.com \
    --cc=paul.m.stillwell.jr@intel.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 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).