linux-kernel - Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CD03886.5030502@synaptics.com>
Date:	Tue, 2 Nov 2010 09:12:54 -0700
From:	Christopher Heiny <cheiny@...aptics.com>
To:	Greg KH <greg@...ah.com>
CC:	Naveen Kumar G <naveen.gaddipati@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"STEricsson_nomadik_linux@...t.st.com" 
	<STEricsson_nomadik_linux@...t.st.com>
Subject: Re: [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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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