All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Sam Bobroff <sam.bobroff@au1.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Cc: kvm@vger.kernel.org, aik@ozlabs.ru, agraf@suse.de,
	kvm-ppc@vger.kernel.org, qemu-devel@nongnu.org, paulus@samba.org,
	david@gibson.dropbear.id.au, "Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM
Date: Wed, 20 Jul 2016 08:30:09 +0200	[thread overview]
Message-ID: <ee83aaeb-40cf-4b46-4ae0-bb4265a0e610@redhat.com> (raw)
In-Reply-To: <20534.8713825972$1468993677@news.gmane.org>



On 20/07/2016 07:46, Michael Ellerman wrote:
> Thanks.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> 
> Or do you want me to merge this before Paul gets back?

No, this should be merged through the KVM tree.  Please Cc the KVM
maintainers before offering to apply a patch that formally belongs to
another tree.

I don't care if Paul merges the patch or Radim and I do, but we're
getting lots of unnecessary conflicts from patches that go through the
main architecture tree and that shouldn't really happen.  Please let's
keep some discipline, as I want to minimize the number of conflicts that
reach Linus (and 4.8 is going to be *bad* in this respect, with both PPC
and s390 having conflicts between the KVM and arch tree).

In particular this patch would indeed have a conflict, because you have

+#define KVM_CAP_PPC_HTM 129

but cap numbers 129 and 130 are already taken.  So whoever applies it
should bump the number to 131.

Paolo

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Sam Bobroff <sam.bobroff@au1.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Cc: kvm@vger.kernel.org, aik@ozlabs.ru, agraf@suse.de,
	kvm-ppc@vger.kernel.org, qemu-devel@nongnu.org, paulus@samba.org,
	david@gibson.dropbear.id.au, "Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM
Date: Wed, 20 Jul 2016 08:30:09 +0200	[thread overview]
Message-ID: <ee83aaeb-40cf-4b46-4ae0-bb4265a0e610@redhat.com> (raw)
In-Reply-To: <20534.8713825972$1468993677@news.gmane.org>



On 20/07/2016 07:46, Michael Ellerman wrote:
> Thanks.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> 
> Or do you want me to merge this before Paul gets back?

No, this should be merged through the KVM tree.  Please Cc the KVM
maintainers before offering to apply a patch that formally belongs to
another tree.

I don't care if Paul merges the patch or Radim and I do, but we're
getting lots of unnecessary conflicts from patches that go through the
main architecture tree and that shouldn't really happen.  Please let's
keep some discipline, as I want to minimize the number of conflicts that
reach Linus (and 4.8 is going to be *bad* in this respect, with both PPC
and s390 having conflicts between the KVM and arch tree).

In particular this patch would indeed have a conflict, because you have

+#define KVM_CAP_PPC_HTM 129

but cap numbers 129 and 130 are already taken.  So whoever applies it
should bump the number to 131.

Paolo

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Sam Bobroff <sam.bobroff@au1.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Cc: kvm@vger.kernel.org, aik@ozlabs.ru, agraf@suse.de,
	kvm-ppc@vger.kernel.org, qemu-devel@nongnu.org, paulus@samba.org,
	david@gibson.dropbear.id.au, "Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM
Date: Wed, 20 Jul 2016 06:30:09 +0000	[thread overview]
Message-ID: <ee83aaeb-40cf-4b46-4ae0-bb4265a0e610@redhat.com> (raw)
In-Reply-To: <20534.8713825972$1468993677@news.gmane.org>



On 20/07/2016 07:46, Michael Ellerman wrote:
> Thanks.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> 
> Or do you want me to merge this before Paul gets back?

No, this should be merged through the KVM tree.  Please Cc the KVM
maintainers before offering to apply a patch that formally belongs to
another tree.

I don't care if Paul merges the patch or Radim and I do, but we're
getting lots of unnecessary conflicts from patches that go through the
main architecture tree and that shouldn't really happen.  Please let's
keep some discipline, as I want to minimize the number of conflicts that
reach Linus (and 4.8 is going to be *bad* in this respect, with both PPC
and s390 having conflicts between the KVM and arch tree).

In particular this patch would indeed have a conflict, because you have

+#define KVM_CAP_PPC_HTM 129

but cap numbers 129 and 130 are already taken.  So whoever applies it
should bump the number to 131.

Paolo

  reply	other threads:[~2016-07-20  6:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-20  3:41 [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM Sam Bobroff
2016-07-20  3:41 ` Sam Bobroff
2016-07-20  3:41 ` [Qemu-devel] " Sam Bobroff
2016-07-20  4:20 ` Balbir Singh
2016-07-20  4:20   ` Balbir Singh
2016-07-20  4:20   ` [Qemu-devel] " Balbir Singh
2016-07-20  5:46 ` Michael Ellerman
2016-07-20  6:30   ` Paolo Bonzini [this message]
2016-07-20  6:30     ` Paolo Bonzini
2016-07-20  6:30     ` [Qemu-devel] " Paolo Bonzini
2016-07-20 10:20     ` Michael Ellerman
2016-07-20 10:20       ` [Qemu-devel] " Michael Ellerman
2016-07-20 10:20     ` Michael Ellerman
2016-07-20 10:20     ` Michael Ellerman
2016-07-20 10:20     ` Michael Ellerman
2016-08-01 18:52     ` Paolo Bonzini
2016-08-01 18:52       ` Paolo Bonzini
2016-08-01 18:52       ` [Qemu-devel] " Paolo Bonzini
2016-08-01 18:52       ` Paolo Bonzini
2016-07-20  5:46 ` Michael Ellerman
2016-07-20  5:46 ` Michael Ellerman
2016-07-20  5:46 ` Michael Ellerman
2016-07-20  5:46   ` [Qemu-devel] " Michael Ellerman
2016-07-20  9:16 ` David Gibson
2016-07-20  9:16   ` David Gibson
2016-07-20  9:16   ` [Qemu-devel] " David Gibson

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=ee83aaeb-40cf-4b46-4ae0-bb4265a0e610@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@redhat.com \
    --cc=sam.bobroff@au1.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.