From: Stephen Warren <swarren@wwwdotorg.org>
To: Lubomir Rintel <lkundrak@v3.sk>
Cc: linux-kernel@vger.kernel.org, Dom Cobley <popcornmix@gmail.com>,
Wim Van Sebroeck <wim@iguana.be>,
Guenter Roeck <linux@roeck-us.net>,
linux-rpi-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v4] watchdog: Add Broadcom BCM2835 watchdog timer driver
Date: Wed, 27 Mar 2013 21:00:29 -0600 [thread overview]
Message-ID: <5153B24D.1010408@wwwdotorg.org> (raw)
In-Reply-To: <1364402424-19503-1-git-send-email-lkundrak@v3.sk>
On 03/27/2013 10:40 AM, Lubomir Rintel wrote:
> This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC,
> used in Raspberry Pi and Roku 2 devices.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Those two s-o-b lines should be swapped, since if Dom did sign off on
any part of this patch, he did it before you did.
That said...
I wonder if it's actually appropriate to include Dom's s-o-b here, since
I don't think he really wrote this patch itself. I think you mentioned
that you hadn't use much of the downstream driver except for some defines?
To be clear, I mentioned the existence of the S-o-b line downstream
simply to demonstrate that the commits you were getting information from
had correctly followed the process described in
Documentation/SubmittingPatches, and so it was OK to use that
information while creating a GPL'd driver.
So there are a couple of ways that this patch could have been created:
1) You took the downstream commit itself, cherry-picked it into the
upstream kernel, modified it to suit upstream, and then submitted that.
The modifications might be extensive, such as renaming the file,
removing parts of the code that the upstream watchdog core now handles,
adding some new features, fixing bugs, cleanup, etc.; whatever is needed
to upstream the patch.
In this case, I believe it would be appropriate to maintain any S-o-b
lines from the original downstream commit, and add yours. But, I believe
you should also (a) maintain the git author field from the original
downstream commit (b) include a list of the changes you made to the
patch in the commit description, so you can be blamed for them rather
than the original author:-)
2) You read the downstream commit for information, but created a
completely new driver for the upstream kernel, using the downstream
driver just as a reference. In this case, I believe it's fine for the
git author field to be you, and for the only s-o-b line present to be
yours, since you really did write the patch from scratch. However, you
should credit the downstream work in the (c) header and/or commit
description.
This current patch sees to be a slight hybrid of both approaches (you're
listed as the git author, but have included Dom's s-o-b line on a patch
I don't think he created, and wasn't directly derived from one he created).
I'm not sure if I'm being too picky. I guess I'll leave it up to Wim Van
Sebroeck, since he's the watchdog maintainer and would be the person who
applies this patch.
next prev parent reply other threads:[~2013-03-28 3:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-22 12:55 [PATCH] watchdog: Add Broadcom BCM2708 watchdog timer driver Lubomir Rintel
2013-03-22 13:56 ` Guenter Roeck
2013-03-24 14:06 ` Lubomir Rintel
2013-03-24 15:36 ` Guenter Roeck
2013-03-22 18:46 ` [PATCH] " Arend van Spriel
2013-03-24 14:08 ` Lubomir Rintel
2013-03-23 2:24 ` Stephen Warren
2013-03-24 14:12 ` Lubomir Rintel
2013-03-27 3:26 ` Stephen Warren
2013-03-27 3:33 ` Stephen Warren
2013-03-24 14:22 ` [PATCH v2] watchdog: Add Broadcom BCM2835 " Lubomir Rintel
2013-03-24 14:25 ` [PATCH v2] arm: Add Broadcom BCM2835 watchdog timer driver to bcm2835_defconfig Lubomir Rintel
2013-03-26 17:48 ` [PATCH v2] bcm2835: Add Broadcom BCM2835 RNG to the device tree Lubomir Rintel
2013-03-26 17:50 ` Lubomir Rintel
2013-03-26 17:50 ` [PATCH v3] watchdog: Add Broadcom BCM2835 watchdog timer driver Lubomir Rintel
2013-03-26 21:03 ` Guenter Roeck
2013-03-27 16:39 ` Lubomir Rintel
2013-03-27 3:40 ` Stephen Warren
2013-03-27 16:36 ` Lubomir Rintel
2013-03-27 3:49 ` Stephen Warren
2013-03-27 16:40 ` [PATCH v4] " Lubomir Rintel
2013-03-27 19:52 ` Guenter Roeck
2013-03-28 3:00 ` Stephen Warren [this message]
2013-03-28 3:50 ` Guenter Roeck
2013-05-26 14:22 ` Wim Van Sebroeck
2013-06-18 16:50 ` Lubomir Rintel
2013-06-18 17:10 ` Stephen Warren
2013-06-18 17:44 ` [PATCH v5] " Lubomir Rintel
2013-06-18 18:24 ` Guenter Roeck
2013-06-27 20:25 ` Wim Van Sebroeck
2013-05-17 2:59 ` [PATCH v4] " Stephen Warren
2013-03-24 16:12 ` [PATCH v2] " Guenter Roeck
2013-03-26 17:47 ` Lubomir Rintel
2013-03-26 19:47 ` Guenter Roeck
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=5153B24D.1010408@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkundrak@v3.sk \
--cc=popcornmix@gmail.com \
--cc=wim@iguana.be \
/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