linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Dyer <nick.dyer@itdev.co.uk>
To: Stephen Warren <swarren@wwwdotorg.org>,
	Benson Leung <bleung@chromium.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Yufeng Shen <miletus@chromium.org>,
	Daniel Kurtz <djkurtz@chromium.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	Stephen Warren <swarren@nvidia.com>,
	"Bowens, Alan" <Alan.Bowens@atmel.com>
Subject: Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
Date: Thu, 08 May 2014 17:01:30 +0100	[thread overview]
Message-ID: <536BAA5A.1010809@itdev.co.uk> (raw)
In-Reply-To: <536963A0.4060506@wwwdotorg.org>

Stephen Warren wrote:
> On 05/06/2014 04:16 PM, Benson Leung wrote:
>> Please coordinate with Nick Dyer, who has a long patch series that's
>> been approved but not yet merged into the input tree. The few patches
>> you've picked from the Chrome OS kernel overlap with his patch series.
> 
> Ah I remember you mentioning that before. Is Nick's work still active?
> The link you sent me to the "latest status" was nearly a year ago:
> 
> https://lkml.org/lkml/2013/6/27/311

My latest set of patches for upstream was sent just over a month ago:
https://lkml.org/lkml/2014/3/17/403

Dmitry Torokov has signed-off on them but not merged them into his tree
yet. It would be good to hear something from him!

> ... and while the github link you sent:
> 
> https://github.com/ndyer/linux/commits/for-next-20140316-v8
> 
> ... has much more recent activity, it hasn't been touched /that/
> recently either.
> 
> To be honest, it'd be a bit off-putting to hold up a trivial patch
> series like this and make it wait for a huge refactoring series that's
> obviously been dragging on for a long time...

>From my point of view, it would be better if everyone with a stake in this
driver worked together to test and review a single set of improvements that
fixed bugs, added new features, and supported new chips, rather than
everyone implementing trivial fixes in various different ways that cause
merge conflicts and strange bugs.

  reply	other threads:[~2014-05-08 16:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-06 22:13 [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra Stephen Warren
2014-05-06 22:13 ` [PATCH 1/4] Input: atmel_mxt_ts - Set pointer emulation if is_tp Stephen Warren
2014-05-06 22:13 ` [PATCH 2/4] Input: atmel_mxt_ts - Read resolution from device memory Stephen Warren
2014-05-06 22:13 ` [PATCH 3/4] Input: atmel_mxt_ts: define a device tree binding Stephen Warren
2014-05-06 22:13 ` [PATCH 4/4] Input: atmel_mxt_ts: implement device tree parsing Stephen Warren
2014-05-06 22:16 ` [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra Benson Leung
2014-05-06 22:35   ` Stephen Warren
2014-05-08 16:01     ` Nick Dyer [this message]
2014-05-08 16:41       ` Stephen Warren
2014-05-08 17:26         ` Dmitry Torokhov
2014-05-08 19:56           ` Nick Dyer
2014-05-09 18:49             ` Mark Brown
2014-05-13  1:17               ` Dmitry Torokhov
2014-05-08 19:50         ` Nick Dyer
2014-05-12 20:02           ` Stephen Warren
2014-05-13  1:16             ` Dmitry Torokhov
2014-05-13  2:31               ` Stephen Warren
2014-05-16 16:21             ` Nick Dyer
2014-05-16 16:40               ` Stephen Warren
2014-05-20 16:19                 ` Nick Dyer
2014-06-11 18:17                   ` Stephen Warren
2014-06-12 11:25                     ` Nick Dyer
2014-06-12 17:12                       ` Stephen Warren
2014-06-12 17:37                         ` Stephen Warren
2014-06-30 16:11                   ` Stephen Warren
2014-06-02  9:50               ` Sekhar Nori

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=536BAA5A.1010809@itdev.co.uk \
    --to=nick.dyer@itdev.co.uk \
    --cc=Alan.Bowens@atmel.com \
    --cc=bleung@chromium.org \
    --cc=djkurtz@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=miletus@chromium.org \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    /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;
as well as URLs for NNTP newsgroup(s).