From: Scott Wood <scottwood@freescale.com>
To: Avi Kivity <avi@redhat.com>
Cc: <agraf@suse.de>, <kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, Liu Yu <yu.liu@freescale.com>,
Varun Sethi <varun.sethi@freescale.com>
Subject: Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
Date: Tue, 10 Jan 2012 16:20:39 -0600 [thread overview]
Message-ID: <4F0CB9B7.9020607@freescale.com> (raw)
In-Reply-To: <4F0BF8BB.4080309@redhat.com>
On 01/10/2012 02:37 AM, Avi Kivity wrote:
> On 01/09/2012 09:29 PM, Scott Wood wrote:
>>>
>>> Best to include their signoffs, if possible.
>>
>> These patches are based in part on a bunch of different patches from
>> these people (for which I did receive signoffs). I was reluctant to put
>> their signoff directly on the new patches, since I didn't want to make
>> it look like they had submitted the patch in anything resembling its
>> current form. I wanted to give them credit for what they did, but not
>> blame for what I did with their code.
>>
>
> Signoffs are for assigning neither credit nor blame, but for
> attributing authorship and affirming that a contributor has
> the right to contribute code or pass it along.
That's its formal purpose, but some people draw other conclusions from
it regardless. From Documentation/SubmittingPatches: "Rule (b) allows
you to adjust the code, but then it is very impolite to change one
submitter's code and make him endorse your bugs."
Please read the DCO at
> https://lwn.net/Articles/437739/.
I've read it. My signoff here qualifies based on (a) and (b).
> (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license
> indicated in the file; or
Note "or in part". The contributions in this patch were all produced by
Freescale employees on a work for hire basis (other than the extent to
which the code is derived from code already in the Linux kernel, which
is covered by (b)), and I am authorized to submit this work on
Freescale's behalf for inclusion into the Linux kernel under GPLv2.
I'm not trying to be difficult, just to avoid looking like it was a
patch passed more-or-less as-is from person to person. When I resubmit,
I can put the sign-offs in with [scottwood@freescale.com: significant
rework] after them, or list them separately as part of the "based on..."
paragraph.
-Scott
prev parent reply other threads:[~2012-01-10 22:20 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 1:33 [RFC PATCH 00/16] KVM: PPC: e500mc support Scott Wood
2011-12-21 1:34 ` [RFC PATCH 01/16] powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on 32-bit Scott Wood
2012-01-09 15:21 ` Alexander Graf
2012-01-09 19:14 ` Scott Wood
2011-12-21 1:34 ` [RFC PATCH 02/16] powerpc/e500: split CPU_FTRS_ALWAYS/CPU_FTRS_POSSIBLE Scott Wood
2011-12-21 1:34 ` [RFC PATCH 03/16] KVM: PPC: Use pt_regs in vcpu->arch Scott Wood
2011-12-21 1:34 ` [RFC PATCH 04/16] KVM: PPC: factor out lpid allocator from book3s_64_mmu_hv Scott Wood
2012-01-09 15:35 ` Alexander Graf
2012-01-12 4:16 ` Paul Mackerras
2011-12-21 1:34 ` [RFC PATCH 05/16] KVM: PPC: booke: add booke-level vcpu load/put Scott Wood
2011-12-21 1:34 ` [RFC PATCH 06/16] KVM: PPC: booke: Move vm core init/destroy out of booke.c Scott Wood
2011-12-21 1:34 ` [RFC PATCH 07/16] KVM: PPC: e500: rename e500_tlb.h to e500.h Scott Wood
2011-12-21 1:34 ` [RFC PATCH 08/16] KVM: PPC: e500: merge <asm/kvm_e500.h> into arch/powerpc/kvm/e500.h Scott Wood
2011-12-21 1:34 ` [RFC PATCH 09/16] KVM: PPC: e500: clean up arch/powerpc/kvm/e500.h Scott Wood
2011-12-21 1:34 ` [RFC PATCH 10/16] KVM: PPC: e500: refactor core-specific TLB code Scott Wood
2011-12-21 1:34 ` [RFC PATCH 11/16] KVM: PPC: e500: Track TLB1 entries with a bitmap Scott Wood
2011-12-21 1:34 ` [RFC PATCH 12/16] KVM: PPC: e500: emulate tlbilx Scott Wood
2012-01-09 16:23 ` Alexander Graf
2011-12-21 1:34 ` [RFC PATCH 13/16] powerpc/booke: Provide exception macros with interrupt name Scott Wood
2012-02-17 8:50 ` Benjamin Herrenschmidt
2011-12-21 1:34 ` [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support Scott Wood
2012-01-09 17:46 ` Alexander Graf
2012-01-10 0:51 ` Scott Wood
2012-01-10 3:11 ` Alexander Graf
2012-01-10 22:03 ` Scott Wood
2012-01-10 23:06 ` Alexander Graf
2012-01-12 6:44 ` Benjamin Herrenschmidt
2012-01-12 7:11 ` Alexander Graf
2012-01-12 16:26 ` Scott Wood
2012-02-15 19:36 ` Alexander Graf
2012-02-15 19:40 ` Scott Wood
2012-02-15 23:18 ` Alexander Graf
2011-12-21 1:34 ` [RFC PATCH 15/16] KVM: PPC: booke: standard PPC floating point support Scott Wood
2012-01-09 17:48 ` Alexander Graf
2012-01-09 21:48 ` Scott Wood
2012-01-09 22:17 ` Alexander Graf
2012-01-09 22:39 ` Scott Wood
2012-01-09 22:47 ` Alexander Graf
2012-01-09 22:54 ` Scott Wood
2012-01-09 22:56 ` Alexander Graf
2011-12-21 1:34 ` [RFC PATCH 16/16] KVM: PPC: e500mc support Scott Wood
2012-01-09 16:33 ` Avi Kivity
2012-01-09 19:29 ` Scott Wood
2012-01-10 8:37 ` Avi Kivity
2012-01-10 22:20 ` Scott Wood [this message]
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=4F0CB9B7.9020607@freescale.com \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=varun.sethi@freescale.com \
--cc=yu.liu@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox