[lkml]   [2010]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 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.


    > thanks,
    > greg k-h
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > More majordomo info at
    > Please read the FAQ at

     \ /
      Last update: 2010-11-02 17:13    [W:0.022 / U:51.828 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site