lkml.org 
[lkml]   [2010]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv1] staging: Synaptics RMI4 touchpad driver support
On 11/02/2010 07:03 AM, Greg KH wrote:
> On Tue, Nov 02, 2010 at 05:38:45PM +0530, Naveen Kumar G wrote:
>> --- /dev/null
>> +++ b/drivers/staging/ste_rmi4/TODO
>> @@ -0,0 +1,7 @@
>> +TODO
>> +----
>> +
>> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
>> +Merge any device support needed from this driver into it
>> +Delete this driver
>
> Huh?
>
> Why not just add this driver to the kernel tree instead? When the
> "promised" driver then eventually shows up (who is promising it?) then
> delete the thing.

I (as technical lead for the kernel driver team at Synaptics) am
promising it.

>
> But until then, why is this needed to go into the staging tree? Is
> there any other main reason it should be here and not in the "real" part
> of the kernel?

Well, it's based off a patch that we submitted in August (or possibly
before), that Dmitry did not find acceptable for the "real" part of the
kernel. He requested us to use kernel primitives for binding instead of
rolling our own, which has led to an extensive refactoring of the code.
We're in internal code review of that factoring right now, and if we
pass out of that, we'll submit a patch this week.

Dmitry did create a branch (synaptics-rmi4) in his git tree at
kernel.org for this work, and applied our most recent patch to that
branch (with some changes).

I must confess that I am seriously confused as to why this patch should
be considered for fast tracking into the "real" kernel. It's based on
an implementation that wasn't considered suitable for the "real" kernel,
and doesn't address the concerns relating to that. If "merge it now,
fix it later" wasn't an acceptable approach previously, is there some
compelling reason it is now acceptable?

On the other hand, I totally understand frustration with our slow rate
of output. We're trying to produce the best possible code, but this is
not happening as quickly as any of us would like.

Chris

>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/



\
 
 \ /
  Last update: 2010-11-02 17:13    [W:0.114 / U:1.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site