Re: [PATCH 1/2] PCI/IOV: Add function to allow Function Dependency Link override.

Hi David & Omer, On Fri, Aug 19, 2016 at 03:32:12PM -0700, Omer Khaliq wrote: > From: David Daney > > Some hardware presents an incorrect SR-IOV Function Dependency Link, > add a function to allow this to be overridden in the PF driver for > such devices. > >

Re: [PATCH 1/2] PCI/IOV: Add function to allow Function Dependency Link override.

On Mon, Aug 22, 2016 at 07:49:09AM -0700, David Daney wrote: > On 08/22/2016 07:36 AM, Bjorn Helgaas wrote: > >Hi David & Omer, > > > >On Fri, Aug 19, 2016 at 03:32:12PM -0700, Omer Khaliq wrote: > >>From: David Daney <david.da...@cavium.com> > >&g

Re: export pcie_flr and remove copies of it in drivers

On Fri, Apr 14, 2017 at 9:41 AM, Bjorn Helgaas <helg...@kernel.org> wrote: > On Thu, Apr 13, 2017 at 04:53:32PM +0200, Christoph Hellwig wrote: >> Hi all, >> >> this exports the PCI layer pcie_flr helper, and removes various opencoded >> copies of it. > &g

Re: [PATCH 1/7] PCI: export pcie_flr

[+cc Alex] On Thu, Apr 13, 2017 at 04:53:33PM +0200, Christoph Hellwig wrote: > Currently we opencode the FLR sequence in lots of place, export a core > helper instead. We split out the probing for FLR support as all the > non-core callers already know their hardware. > > Signed-off-by:

Re: export pcie_flr and remove copies of it in drivers

non-PCI tree, here's my ack for the drivers/pci parts, assuming the probe thing is resolved: Acked-by: Bjorn Helgaas <bhelg...@google.com> Otherwise, I'd be glad to take the series given acks for the non-PCI parts. Just let me know. Bjorn

Re: export pcie_flr and remove copies of it in drivers V2

On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote: > Hi all, > > this exports the PCI layer pcie_flr helper, and removes various opencoded > copies of it. > > Changes since V1: > - rebase on top of the pci/virtualization branch > - fixed the probe case in __pci_dev_reset > -

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The use of ioremap will force the setup data to be mapped decrypted even > though setup data is encrypted. Switch to using memremap which will be > able to perform the proper

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > This RFC series provides support for AMD's new Secure Encrypted Virtualization > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 > [1]. What kernel version is this series based on?

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On Fri, Mar 03, 2017 at 03:15:34PM -0600, Tom Lendacky wrote: > On 3/3/2017 2:42 PM, Bjorn Helgaas wrote: > >On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: > >>From: Tom Lendacky <thomas.lenda...@amd.com> > >> > >>The use of ioremap will f

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Thu, Apr 27, 2017 at 08:47:58AM +0200, Christoph Hellwig wrote: > On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote: > > This still leaves these: > > > > [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it > > [PATCH 6/7] crypto: qat: use pcie

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Mon, Apr 24, 2017 at 04:35:07PM +0200, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: > > Tested-by: Jakub Byczkowski > > Are you (and Doug) ok with queueing this up in the PCI tree? Applied this with Jakub's