From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Kevin McNeely" <Kevin.McNeely@cypress.com>
Subject: RE: [PATCH] i2c: cyttsp i2c and spi touchscreen driver init submit
Date: Mon, 9 Aug 2010 17:51:18 -0700
Message-ID: <FB9C2CB29A07AB45B575A4E8D2AABC09C4882D@labamba.mis.cypress.com>
References: <Kevin McNeely <kev@cypress.com> <1281031924-3032-1-git-send-email-kev@cypress.com> <4C5B4404.6010602@euromail.se> <FB9C2CB29A07AB45B575A4E8D2AABC09C4860A@labamba.mis.cypress.com> <4C5CAD84.2040804@euromail.se>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Return-path: <linux-input-owner@vger.kernel.org>
Received: from ns1.cypress.com ([157.95.67.4]:37678 "EHLO ns1.cypress.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751845Ab0HJAz1 convert rfc822-to-8bit (ORCPT
	<rfc822;linux-input@vger.kernel.org>); Mon, 9 Aug 2010 20:55:27 -0400
Content-class: urn:content-classes:message
Sender: linux-input-owner@vger.kernel.org
List-Id: linux-input@vger.kernel.org
To: Henrik Rydberg <rydberg@euromail.se>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>, David Brown <davidb@codeaurora.org>, Trilok Soni <tsoni@codeaurora.org>, Fred <fwk@ubuntu.linuxcertified.com>, Samuel Ortiz <sameo@linux.intel.com>, Eric Miao <eric.y.miao@gmail.com>, Ben Dooks <ben-linux@fluff.org>, Simtec Linux Team <linux@simtec.co.uk>, Todd Fischer <todd.fischer@ridgerun.com>, Arnaud Patard <arnaud.patard@rtp-net.org>, Sascha Hauer <s.hauer@pengutronix.de>, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org

Hi Henrik,

> -----Original Message-----
> From: Henrik Rydberg [mailto:rydberg@euromail.se]
> Sent: Friday, August 06, 2010 5:49 PM
> To: Kevin McNeely
> Cc: Dmitry Torokhov; David Brown; Trilok Soni; Fred; Samuel Ortiz;
Eric
> Miao; Ben Dooks; Simtec Linux Team; Todd Fischer; Arnaud Patard;
Sascha
> Hauer; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] i2c: cyttsp i2c and spi touchscreen driver init
> submit
> 
> On 08/07/2010 02:32 AM, Kevin McNeely wrote:
> 
> [...]
> 
> > However, I would like to keep the MT Protocol A.  Our solution
allows
> 
> > The platform builder to select to use MT protocol B or not as part
of
> > platform_data in the board configuration. If it makes more sense,
> > I can reverse the code to default to protocol B and allow the
> platform
> > builder developer to select protocol A.
> 
> 
> There is nothing preventing you from keeping say a dkms package
> somewhere with
> all options intact. However, for the kernel, it is a question of
> maintainability. If the driver can produce prefectly valid data using
> protocol
> B, and by doing so several hundred lines of code can be removed, that
> is very
> much preferred. Since both protocols can be translated to protocol B
> via mtdev,
> which is already very much in use, there is little reason to support
> protocol A
> when the device can do tracking.

I will remove the Protocol A.

Thank you again for your review.
-kevin

> 
> Thanks,
> Henrik

---------------------------------------------------------------
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---------------------------------------------------------------