Re: [PATCH 1/4] input: Convert struct i2c_msg initialization to C99 format

2012-10-10 Thread Jean Delvare
On Tue, 9 Oct 2012 17:01:17 +0530, Shubhrajyoti D wrote: > Convert the struct i2c_msg initialization to C99 format. This makes > maintaining and editing the code simpler. Also helps once other fields > like transferred are added in future. > > Thanks to Julia Lawall for automating the conversion

Re: [PATCH 2/4] input: Convert struct i2c_msg initialization to C99 format

2012-10-10 Thread Jean Delvare
On Tue, 9 Oct 2012 17:01:18 +0530, Shubhrajyoti D wrote: > Convert the struct i2c_msg initialization to C99 format. This makes > maintaining and editing the code simpler. Also helps once other fields > like transferred are added in future. > > Thanks to Julia Lawall for automating the conversion

[PATCH v4 RESEND 0/3] Input: egalax_ts: parse devicetree to get gpio

2012-10-10 Thread Hui Wang
Hi Dmitry, The patchset was sent out for review during the time you were away from the maillist. Now you are back, i rebase the patchset to the latest upstream and i resend them to you to catch your notice. The patchset has been reviewed by JieJing and Shawn, if you are OK for the patchset, pleas

[PATCH v4 RESEND 1/3] Input: egalax_ts: get gpio from devicetree

2012-10-10 Thread Hui Wang
The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework and don't support this API anymore. The i.MX6q sabrelite platform equips an egalax touchscreen controller, and this platform already transfered to GENERIC_GPIO framework, to support this driver, we use a more generic way to get gp

[PATCH v4 RESEND 2/3] Input: add devicetree binding note for

2012-10-10 Thread Hui Wang
The egalax_ts driver needs to get the gpio number of the irq pin, and use this gpio to wake up the controller. So add a note for this change. Ackyed-by Zhang Jiejing Reviewed-by: Shawn Guo Signed-off-by: Hui Wang --- .../bindings/input/touchscreen/egalax-ts.txt | 19 +++

[PATCH v4 RESEND 3/3] ARM: dts: imx6q-sabrelite: add eeti egalax

2012-10-10 Thread Hui Wang
i.MX6Q sabrelite board uses i2c3 to connect an eeti egalax touchscreen controller, add it as an i2c slave device in the dts. Reviewed-by: Shawn Guo Signed-off-by: Hui Wang --- arch/arm/boot/dts/imx6q-sabrelite.dts | 16 arch/arm/boot/dts/imx6q.dtsi |9 +

[PATCH] touchscreen/ads7846: Move struct ads7846 to global include.

2012-10-10 Thread Matthias Brugger
To implement a custom filter in the board platform code, the struct ads7864 might be needed. This patch moves the struct to the global include file of the driver. Signed-off-by: Matthias Brugger --- drivers/input/touchscreen/ads7846.c | 55 --- include/linux/spi

Re: [PATCH 2/4] input: Convert struct i2c_msg initialization to C99 format

2012-10-10 Thread Shubhrajyoti Datta
On Wed, Oct 10, 2012 at 2:32 PM, Jean Delvare wrote: > On Tue, 9 Oct 2012 17:01:18 +0530, Shubhrajyoti D wrote: [...] > > Acked-by: Jean Delvare thanks updated patch below >From 6638ecfa7982f95815382922c50573712c9626d7 Mon Sep 17 00:00:00 2001 From: Shubhrajyoti D Date: Mon, 17 Sep 2012 19:37:

Re: [PATCH] touchscreen/ads7846: Move struct ads7846 to global include.

2012-10-10 Thread Igor Grinberg
On 10/10/12 12:37, Matthias Brugger wrote: > To implement a custom filter in the board platform code, > the struct ads7864 might be needed. This patch moves the struct > to the global include file of the driver. > > Signed-off-by: Matthias Brugger NAK. This is a private driver data. No one else

Re: [PATCH v4 RESEND 1/3] Input: egalax_ts: get gpio from devicetree

2012-10-10 Thread Dmitry Torokhov
Hi Hui, On Wed, Oct 10, 2012 at 05:12:01PM +0800, Hui Wang wrote: > The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework > and don't support this API anymore. > > The i.MX6q sabrelite platform equips an egalax touchscreen controller, > and this platform already transfered to GENERI

Re: [ebeam PATCH v2 1/2] hid: Blacklist eBeam devices

2012-10-10 Thread Dmitry Torokhov
Jiri, Are you OK with this change? Yann, Is the device usable at all with generic HID driver? If it isn't then maybe we should blacklist it unconditionally? Thanks. On Sat, Oct 06, 2012 at 03:14:46PM +0200, Yann Cantin wrote: > > Signed-off-by: Yann Cantin > --- > drivers/hid/hid-core.c |

Re: [PATCH 07/10] input: Enable STMPE keypad driver for Device Tree

2012-10-10 Thread Dmitry Torokhov
Hi Lee, On Fri, Oct 05, 2012 at 04:31:43PM +0100, Lee Jones wrote: > This patch allows the STMPE driver to be successfully probed and > initialised when Device Tree support is enabled. Besides the usual > platform data changes, we also separate the process of filling in > the 'in use' pin bitmap,

Re: [PATCH 4/4] Input: extend the number of event (and other) devices

2012-10-10 Thread Dmitry Torokhov
Hi David, On Sun, Oct 07, 2012 at 04:52:28PM +0200, David Herrmann wrote: > Hi Dmitry > > On Wed, Oct 3, 2012 at 11:03 PM, Dmitry Torokhov > wrote: > > [snip] > > > @@ -991,43 +950,47 @@ static void evdev_cleanup(struct evdev *evdev) > > > > /* > > * Create new evdev device. Note that input

Re: [PATCH] staging: ste_rmi4: use module_i2c_driver to simplify the code

2012-10-10 Thread Henrik Rydberg
On Tue, Oct 09, 2012 at 02:07:59PM +0200, Linus Walleij wrote: > On Mon, Oct 8, 2012 at 4:15 PM, Wei Yongjun wrote: > > > From: Wei Yongjun > > > > Use the module_i2c_driver() macro to make the code smaller > > and a bit simpler. > > > > dpatch engine is used to auto generate this patch. > > (ht

Re: [RFC PATCH 06/06] input/rmi4: F11 - 2D touch interface

2012-10-10 Thread Henrik Rydberg
Hi Christopher, > rmi_f11.c is a driver for 2D touch sensors. It has been updated to support > the MT-B specification, partition control attributes between debugfs and > sysfs, > and to use the standard bus model for loading/unloading. Please find comments inline. Generally, if you want this m

Re: [ebeam PATCH v2 1/2] hid: Blacklist eBeam devices

2012-10-10 Thread Yann Cantin
Hi, Le 10/10/2012 18:37, Dmitry Torokhov a écrit : > Is the device usable at all with generic HID driver? If it isn't then > maybe we should blacklist it unconditionally? Without the libusb based proprietary stack, the device is unusable under linux. If i correctly understand, libusb need a driv

RE: [RFC PATCH 02/06] input/rmi4: Core files

2012-10-10 Thread Christopher Heiny
Joe Perches wrote: > On Fri, 2012-10-05 at 21:09 -0700, Christopher Heiny wrote: > [] > > Just some trivial comments: Thanks - see below for responses. > > diff --git a/drivers/input/rmi4/rmi_driver.c > > b/drivers/input/rmi4/rmi_driver.c > [] > > > @@ -0,0 +1,1529 @@ > > [] > > > +static ssi

Re: [RFC PATCH 02/06] input/rmi4: Core files

2012-10-10 Thread Joe Perches
On Thu, 2012-10-11 at 02:49 +, Christopher Heiny wrote: > Joe Perches wrote: [] > > > + list_for_each_entry(entry, &data->rmi_functions.list, list) > > > + if (entry->irq_mask) > > > + process_one_interrupt(entry, irq_status, > > > +

RE: [RFC PATCH 01/06] input/rmi4: Public header and documentation

2012-10-10 Thread Christopher Heiny
Linus Walleij wrote: > On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny > wrote: > > As requested in the feedback from the previous patch, we've documented the > > debugfs and sysfs attributes in files in > > Documentation/ABI/testing. There's two files, one for debugfs and one > > for sysfs. >

RE: [RFC PATCH 01/06] input/rmi4: Public header and documentation

2012-10-10 Thread Christopher Heiny
Mark Brown wrote: > On Tue, Oct 09, 2012 at 09:43:13AM +0200, Linus Walleij wrote: > > On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny > > wrote: > > > + * @cs_assert - For systems where the SPI subsystem does not control > > > the CS/SSB + * line, or where such control is broken, you can provi

RE: [RFC PATCH 02/06] input/rmi4: Core files

2012-10-10 Thread Christopher Heiny
On Thursday, October 11, 2012 02:21:53 AM you wrote: > On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny > wrote: > > rmi_bus.c implements the basic functionality of the RMI bus. This file is > > greatly simplified compared to the previous patch - we've switched from > > "do it yourself" device/

RE: [RFC PATCH 03/06] input/rmi4: I2C physical interface

2012-10-10 Thread Christopher Heiny
Linus Walleij wrote: > On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny > wrote: > > The I2C physical driver is not extensively changed in terms of > > functionality since the previous patch. Management of the attention GPIO > > has been moved to rmi_driver.c (see previous email), and most of t

RE: [RFC PATCH 04/06] input/rmi4: Config files and makefiles

2012-10-10 Thread Christopher Heiny
Linus Walleij wrote: > On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny > wrote: > > (...) > > > diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig > > (...) > > > +config RMI4_DEBUG > > + bool "RMI4 Debugging" > > + depends on RMI4_BUS > > select DEBUG_FS > >

RE: [RFC PATCH 05/06] input/rmi4: F01 - device control

2012-10-10 Thread Christopher Heiny
Linus Walleij wrote: > On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny > wrote: > > RMI Function 01 implements basic device control and power management > > behaviors for the RMI4 sensor. Since the last patch, we've decoupled > > rmi_f01.c implementation from rmi_driver.c, so rmi_f01.c acts as

RE: [RFC PATCH 06/06] input/rmi4: F11 - 2D touch interface

2012-10-10 Thread Christopher Heiny
Linus Walleij wrote: > On Sat, Oct 6, 2012 at 6:10 AM, Christopher Heiny > wrote: > > So looking closer at this one since we will use it. Maybe it's in such a > good shape now that I should be able to actually test it with the hardware? Well, it's been possible to test at least since the patch s