Thread (9 messages) 9 messages, 3 authors, 2016-05-20

Re: [PATCH 1/2 V3] dt: add Atmel Captouch bindings

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2016-05-20 22:21:28
Also in: linux-devicetree, lkml

On Fri, May 20, 2016 at 05:12:55PM -0500, Rob Herring wrote:
On Fri, May 20, 2016 at 11:16 AM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Fri, May 20, 2016 at 07:56:51AM -0500, Rob Herring wrote:
quoted
On Wed, May 18, 2016 at 4:59 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
On Wed, May 18, 2016 at 11:44:04AM -0500, Rob Herring wrote:
quoted
On Mon, May 16, 2016 at 01:54:53PM -0700, Grant Grundler wrote:
quoted
From: Daniel Hung-yu Wu <redacted>

Add binding for Atmel Capacitive Touch Button device.

Signed-off-by: Daniel Hung-yu Wu <redacted>
Signed-off-by: Grant Grundler <redacted>
---
 .../devicetree/bindings/input/atmel,captouch.txt   | 36 ++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/atmel,captouch.txt
Acked-by: Rob Herring <robh@kernel.org>
Folded into the driver patch and applied.
Folded why? Please don't do that. You should be committing what is
posted as is for the most part. We specifically ask that binding
changes are kept separate commits. It also messes up the ability to
I know that you ask for binding docs to be posted separately (I guess
so that devicetree list is not overrun with driver code mails),
And because we're really only reviewing the binding, so putting my ack
on the driver is not really correct.
If you'd like I can annotate your Acks to state that they are for
bindings only when I fold everything together.
quoted
but
logically driver patch and binding doc patch are a single change and
should be committed together, so that when I am researching the history
I can easily see what was introduced and when. You do not require header
changes to be submitted separately form .c files, do you?
Yes, for include/dt-bindings we ask that they are part of the binding
doc, not the driver even though both use it. You can also certainly
have bindings without drivers though generally we require them. I
would not if they had a driver in BSD or u-boot for example.
Would they be in linux kernel sources then? I can see rules changed if
ever DTS/bindings are split from kernel, but while they are kept
together I do not see why we'd want to keep commits separate.
You can already easily see when things are introduced because they
will be next to each other in the git history.
quoted
quoted
correlate git commits to patchworks or mail searches.
The fact that it was applied can be found in mail archives.
Yes, with extra effort reading the history you can, but not with a
script. There's a patchwork script to add commit hashes to patchwork
which works all based on the subject.
If you'd like I can teach my scripts to update patches in your patchwork
instance when I do folds.
Regardless of one commit or two, you simply shouldn't be changing what
you commit. Either commit what was posted or require the author to
combine things and repost. That's our job as patch monkeys.
Or I do a bit of work on my end (i.e. add a few "depends on" that were
missed in case I notice them) and not ask for yet another respin.

Thanks.

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help