linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the iommufd tree with the vfio-fixes tree
@ 2022-11-11  4:37 Stephen Rothwell
  2022-11-14 13:35 ` Jason Gunthorpe
  0 siblings, 1 reply; 4+ messages in thread
From: Stephen Rothwell @ 2022-11-11  4:37 UTC (permalink / raw)
  To: Jason Gunthorpe, Alex Williamson
  Cc: Anthony DeRossi, Jason Gunthorpe, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

Hi all,

Today's linux-next merge of the iommufd tree got a conflict in:

  drivers/vfio/vfio_main.c

between commit:

  7fdba0011157 ("vfio: Fix container device registration life cycle")

from the vfio-fixes tree and commit:

  55e16a188913 ("vfio: Move vfio_device driver open/close code to a function")

from the iommufd tree.

I fixed it up (I just used the latter version since it seems to
incorporate the former change) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: linux-next: manual merge of the iommufd tree with the vfio-fixes tree
  2022-11-11  4:37 linux-next: manual merge of the iommufd tree with the vfio-fixes tree Stephen Rothwell
@ 2022-11-14 13:35 ` Jason Gunthorpe
  2022-11-14 15:32   ` Alex Williamson
  0 siblings, 1 reply; 4+ messages in thread
From: Jason Gunthorpe @ 2022-11-14 13:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Alex Williamson, Anthony DeRossi, Linux Kernel Mailing List,
	Linux Next Mailing List

On Fri, Nov 11, 2022 at 03:37:35PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the iommufd tree got a conflict in:
> 
>   drivers/vfio/vfio_main.c
> 
> between commit:
> 
>   7fdba0011157 ("vfio: Fix container device registration life cycle")
> 
> from the vfio-fixes tree and commit:
> 
>   55e16a188913 ("vfio: Move vfio_device driver open/close code to a function")
> 
> from the iommufd tree.
> 
> I fixed it up (I just used the latter version since it seems to
> incorporate the former change) and can carry the fix as necessary. 

Yes, that is right, it is as Alex and I discussed

Thanks
Jason


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: linux-next: manual merge of the iommufd tree with the vfio-fixes tree
  2022-11-14 13:35 ` Jason Gunthorpe
@ 2022-11-14 15:32   ` Alex Williamson
  2022-11-14 15:34     ` Jason Gunthorpe
  0 siblings, 1 reply; 4+ messages in thread
From: Alex Williamson @ 2022-11-14 15:32 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Stephen Rothwell, Anthony DeRossi, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, 14 Nov 2022 09:35:39 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Fri, Nov 11, 2022 at 03:37:35PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the iommufd tree got a conflict in:
> > 
> >   drivers/vfio/vfio_main.c
> > 
> > between commit:
> > 
> >   7fdba0011157 ("vfio: Fix container device registration life cycle")
> > 
> > from the vfio-fixes tree and commit:
> > 
> >   55e16a188913 ("vfio: Move vfio_device driver open/close code to a function")
> > 
> > from the iommufd tree.
> > 
> > I fixed it up (I just used the latter version since it seems to
> > incorporate the former change) and can carry the fix as necessary.   
> 
> Yes, that is right, it is as Alex and I discussed

My plan is to merge back my fixes branch after it gets pulled into
v6.1-rc so the vfio-iommufd support can be re-based to avoid this for
v6.2.  Thanks,

Alex


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: linux-next: manual merge of the iommufd tree with the vfio-fixes tree
  2022-11-14 15:32   ` Alex Williamson
@ 2022-11-14 15:34     ` Jason Gunthorpe
  0 siblings, 0 replies; 4+ messages in thread
From: Jason Gunthorpe @ 2022-11-14 15:34 UTC (permalink / raw)
  To: Alex Williamson
  Cc: Stephen Rothwell, Anthony DeRossi, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, Nov 14, 2022 at 08:32:07AM -0700, Alex Williamson wrote:
> On Mon, 14 Nov 2022 09:35:39 -0400
> Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Fri, Nov 11, 2022 at 03:37:35PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the iommufd tree got a conflict in:
> > > 
> > >   drivers/vfio/vfio_main.c
> > > 
> > > between commit:
> > > 
> > >   7fdba0011157 ("vfio: Fix container device registration life cycle")
> > > 
> > > from the vfio-fixes tree and commit:
> > > 
> > >   55e16a188913 ("vfio: Move vfio_device driver open/close code to a function")
> > > 
> > > from the iommufd tree.
> > > 
> > > I fixed it up (I just used the latter version since it seems to
> > > incorporate the former change) and can carry the fix as necessary.   
> > 
> > Yes, that is right, it is as Alex and I discussed
> 
> My plan is to merge back my fixes branch after it gets pulled into
> v6.1-rc so the vfio-iommufd support can be re-based to avoid this for
> v6.2.  Thanks,

It is fine, I will just merge v6.1 release into iommufd as-is, at the
end of the cycle, as I often do to fixup these rc conflicts.

At this point, due to all the testing, I don't really want to rebase
iommufd any further if I can avoid it.

Jason

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-11-14 15:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-11  4:37 linux-next: manual merge of the iommufd tree with the vfio-fixes tree Stephen Rothwell
2022-11-14 13:35 ` Jason Gunthorpe
2022-11-14 15:32   ` Alex Williamson
2022-11-14 15:34     ` Jason Gunthorpe

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).