Thread (19 messages) flat view 19 messages, 8 authors, 2021-05-04

Re: [PATCH 1/2] vfio/pci: remove vfio_pci_nvlink2

From: Jason Gunthorpe <jgg@nvidia.com>
Date: 2021-04-22 13:52:31
Also in: dri-devel, kvm, linuxppc-dev, lkml

On Thu, Apr 22, 2021 at 11:49:31PM +1000, Michael Ellerman wrote:
Alex Williamson [off-list ref] writes:
quoted
On Mon, 12 Apr 2021 19:41:41 +1000
Michael Ellerman [off-list ref] wrote:
quoted
Alex Williamson [off-list ref] writes:
quoted
On Fri, 26 Mar 2021 07:13:10 +0100
Christoph Hellwig [off-list ref] wrote:
 
quoted
This driver never had any open userspace (which for VFIO would include
VM kernel drivers) that use it, and thus should never have been added
by our normal userspace ABI rules.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 drivers/vfio/pci/Kconfig            |   6 -
 drivers/vfio/pci/Makefile           |   1 -
 drivers/vfio/pci/vfio_pci.c         |  18 -
 drivers/vfio/pci/vfio_pci_nvlink2.c | 490 ----------------------------
 drivers/vfio/pci/vfio_pci_private.h |  14 -
 include/uapi/linux/vfio.h           |  38 +--
 6 files changed, 4 insertions(+), 563 deletions(-)
 delete mode 100644 drivers/vfio/pci/vfio_pci_nvlink2.c  
Hearing no objections, applied to vfio next branch for v5.13.  Thanks,  
Looks like you only took patch 1?

I can't take patch 2 on its own, that would break the build.

Do you want to take both patches? There's currently no conflicts against
my tree. It's possible one could appear before the v5.13 merge window,
though it would probably just be something minor.

Or I could apply both patches to my tree, which means patch 1 would
appear as two commits in the git history, but that's not a big deal.
I've already got a conflict in my next branch with patch 1, so it's
best to go through my tree.  Seems like a shared branch would be
easiest to allow you to merge and manage potential conflicts against
patch 2, I've pushed a branch here:

https://github.com/awilliam/linux-vfio.git v5.13/vfio/nvlink
Thanks.

My next is based on rc2, so I won't pull that in directly, because I
don't want to pull all of rc6 in with it.
Linus is fine if you merge in rc's for development reasons. He doesn't
like it when people just merge rc's without a purpose.

Merge rc7 to your tree then pull the nvlink topic is acceptable.

Or just do nothing because Alex will send it through his tree - this
extra co-ordination is really only necessary if there are conflicts.

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help