Re: [PATCH soc] ARM: use ARM_SINGLE_ARMV7M for ARMv7-M platforms
From: Stefan Agner
Date: Fri May 22 2015 - 03:29:31 EST
On 2015-05-21 21:04, Uwe Kleine-KÃnig wrote:
> On Thu, May 21, 2015 at 07:00:02PM +0200, Joachim Eastwood wrote:
>> Hi Stefan,
>>
>> On 21 May 2015 at 00:35, Stefan Agner <stefan@xxxxxxxx> wrote:
>> > Use the new config symbol ARM_SINGLE_ARMV7M which groups config
>> > symbols used by modern ARMv7-M platforms. This allows supporting
>> > multiple ARMv7-M platforms in one kernel image. However, a common
>> > kernel image requires the combined platforms to share the same
>> > main memory layout to be bootable.
>> >
>> > Acked-by: Uwe Kleine-KÃnig <u.kleine-koenig@xxxxxxxxxxxxxx>
>> > Signed-off-by: Stefan Agner <stefan@xxxxxxxx>
>>
>> You should have your sign-off on the top and not Uwe's ack.
> I don't agree. IMHO the most sensible thing is to sign off (i.e. put
> your sob line below) all the things that come from you. So it's
>
> Signed-off-by: author
> Acked-by: someone
> Signed-off-by: forwarder
> Signed-off-by: maintainer
>
> if someone already acked before forwarder sent out the mail. If the ack
> is between forwarder and maintainer it was the latter who added the Ack.
> I'm not sure it's formalized this way, but like that it makes most sense
> to me and I seem to recall having read somewhere that the footers are
> supposed to tell something about the order of people involved.
>
> So Stefan did it exactly as i would have done it.
Hm, never give much thoughts about that order, its quite development
process driven here: I use git format-patch with --signoff. When I send
out v1, and get a Ack or Review, I add that to my commit. Hence, when I
send v2 of the patch, my sob line ends up below the Ack (that is what
happened in that case). If its the last revision, and the patch gets
picked up, the forwarder/maintainer will add the Ack and then it would
land after my sob...
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/