[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121115064359.GA17551@core.coreip.homeip.net>
Date: Wed, 14 Nov 2012 22:43:59 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Alexandra Chin <alexandra.chin@...synaptics.com>
Cc: Henrik Rydberg <rydberg@...omail.se>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Linux Input <linux-input@...r.kernel.org>,
Linus Walleij <linus.walleij@...ricsson.com>,
Naveen Kumar Gaddipati <naveen.gaddipati@...ricsson.com>,
Mahesh Srinivasan <msrinivasan@...aptics.com>,
Alex Chang <alex.chang@...synaptics.com>,
Scott Lin <scott.lin@...synaptics.com>,
Christopher Heiny <Cheiny@...aptics.com>
Subject: Re: [RFC] staging: ste_rmi4: merge into the main kernel tree
On Thu, Nov 15, 2012 at 02:56:45AM +0000, Alexandra Chin wrote:
> Hi Dmitry,
>
> > > As I know, currently there is no synaptics RMI4 touchscreen driver in the
> > > main tree. In order to support our customers effectively, is it able to merge
> > > staging ste_rmi4 driver into the main kernel.org tree? If it is accepted, should
> > > I send a patch for this change?
> >
> > I believe that we should keep ste_rmi4 in staging, not as reflection of
> > its code quality, but rather because it is a temporary solution until
> > full-fledged RMI4 driver is merged.
> >
> > Please have Greg commit the patch that Henrik reviewed to staging and
> > then work with Christopher Heiny group on getting the full featured
> > driver into mainline.
>
> Thank you for the prompt reply. The ste_rmi4 driver is actually not intended to be
> a temporary solution for the full-fledged driver. We have requests from a number
> of our customers and partners (Qualcomm, Samsung, Intel etc.) urging us to have
> a driver available in the kernel mainline that is specific to touchscreen with simple
> architecture and supporting our S3200 family of Touch Controllers and above. We
> are committing resources to continue to maintain this driver and provide updates
> to support future touch controller revisions from Synaptics.
> It would be greatly appreciated if this driver can be considered for inclusion in the
> kernel mainline.
In this case you need to enumerate the benefits of this driver over
unified driver and show why the unified driver can't be fixed.
Currently the driver is in mainline (even though the directory is
staging) and nobody will remove it until another driver is fully
functional and ready for prime time. But once this happens I do not see
the benefits of maintaining 2 drivers for the same hardware.
Thank you.
--
Dmitry
--
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/
Powered by blists - more mailing lists