public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, timur@codeaurora.org,
	alex.williamson@redhat.com, vikrams@codeaurora.org,
	Lorenzo.Pieralisi@arm.com, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V4] PCI: handle CRS returned by device after FLR
Date: Fri, 14 Jul 2017 10:28:58 -0400	[thread overview]
Message-ID: <ae1846b2-1752-577b-e651-ef864953af8e@codeaurora.org> (raw)
In-Reply-To: <20170713234910.GB5944@bhelgaas-glaptop.roam.corp.google.com>

Hi Bjorn,

On 7/13/2017 7:49 PM, Bjorn Helgaas wrote:
> How VFs report vendor ID is irrelevant.

I was trying to highlight this. 

"SR-IOV spec rev 1.1, 3.4.1.1 & 3.4.1.2, Vendor ID and Device ID fields
for the VF return 0xFFFF when read.  The "Virtualization Intermediary"
is supposed to use the vendor ID from the PF and the device ID defined
in the PF SR-IOV capability."

https://www.spinics.net/lists/linux-pci/msg58530.html

The point is we can't use pci_bus_read_dev_vendor_id() for both
virtual and physical functions as in my V3 patch.

> 
> What *is* relevant is how FLR affects VFs.  The SR-IOV spec, r1.1,
> sec 2.2.2, says FLR doesn't affect a VF's existence in config space.
> 

I see.

> That suggests to me that reading a VF's PCI_COMMAND register after an
> FLR should always return valid data (never ~0).  I suppose an FLR VF
> reset isn't instantaneous, though, so I suppose we do need the 100ms
> delay.  But maybe we should just return immediately after that,
> without reading any VF config space?

make sense.

> 
> pci_flr_wait() was added by 5adecf817dd6 ("PCI: Wait for up to 1000ms
> after FLR reset"); maybe Alex has more insight into this.

I think code is handling both virtual and physical functions. 1 second
is nice to have for physical functions. See this comment at the top.

/*
 * We should only need to wait 100ms after FLR, but some devices take longer.
 * Wait for up to 1000ms for config space to return something other than -1.
 * Intel IGD requires this when an LCD panel is attached.  We read the 2nd
 * dword because VFs don't implement the 1st dword.
 */

Since we are separating the handling of physical and virtual functions,
we could go back to 100ms for virtual functions and handle CRS/wait for
physical functions.

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

  reply	other threads:[~2017-07-14 14:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 21:07 [PATCH V4] PCI: handle CRS returned by device after FLR Sinan Kaya
2017-07-13 12:17 ` Bjorn Helgaas
2017-07-13 15:44   ` Sinan Kaya
2017-07-13 16:29     ` Keith Busch
2017-07-13 16:42       ` Sinan Kaya
2017-07-13 17:24         ` Keith Busch
2017-07-13 23:38     ` Bjorn Helgaas
2017-07-14 14:10       ` Sinan Kaya
2017-07-13 16:03   ` Keith Busch
2017-07-13 23:49 ` Bjorn Helgaas
2017-07-14 14:28   ` Sinan Kaya [this message]
2017-07-31 21:45   ` Sinan Kaya
2017-07-31 22:19     ` Bjorn Helgaas

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=ae1846b2-1752-577b-e651-ef864953af8e@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=timur@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    /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