linux/drivers/input/mouse, branch v3.11.1

Input: elantech - fix packet check for v3 and v4 hardware

2013-08-25T00:52:35Z

The signatures of v3 and v4 packets change depending on the value of a hardware flag called 'crc_enabled'. The packet type detection must change accordingly. This patch also restores a consistency check for v4 packets inadvertently removed by commit: 9eebed7de660c0b5ab129a9de4f89d20b60de68c Input: elantech - fix for newer hardware versions (v7) A note about the naming convention: v3 hardware is associated with IC body v5 while v4 hardware is associated with IC body v6 and v7. The above commit refers to IC body v7, not to v7 hardware. Tested on Samsung NP730U3E (fw = 0x675f05, ICv7, crc_enabled = 1) Tested-by: Giovanni Frigione Signed-off-by: Matteo Delfino Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2013-07-13T06:34:25Z

Bring in second round of updates for 3.11.

Input: elantech - fix for newer hardware versions (v7)

2013-07-07T04:57:27Z

* Fix version recognition in elantech_set_properties The new hardware reports itself as v7 but the packets' structure is unaltered. * Fix packet type recognition in elantech_packet_check_v4 The bitmask used for v6 is too wide, only the last three bits of the third byte in a packet (packet[3] & 0x03) are actually used to distinguish between packet types. Starting from v7, additional information (to be interpreted) is stored in the remaining bits (packets[3] & 0x1c). In addition, the value stored in (packet[0] & 0x0c) is no longer a constant but contains additional information yet to be deciphered. This change should be backwards compatible with v6 hardware. Additional-author: Giovanni Frigione Signed-off-by: Matteo Delfino Signed-off-by: Dmitry Torokhov

Input: bcm5974 - add support for the 2013 MacBook Air

2013-07-03T03:39:33Z

The June 2013 Macbook Air (13'') has a new trackpad protocol; four new values are inserted in the header, and the mode switch is no longer needed. This patch adds support for the new devices. Cc: stable@vger.kernel.org Reported-and-tested-by: Brad Ford Signed-off-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov

Merge branch 'for-next' of git://github.com/rydberg/linux into next

2013-06-28T06:00:25Z

Pull in changes from Henrik: "a trivial MT documentation fix".

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2013-06-05T00:11:06Z

Pull input fixes from Dmitry Torokhov: "Just a 2 small driver fixups here" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: wacom - fix a typo for Cintiq 22HDT Input: synaptics - fix sync lost after resume on some laptops

Input: synaptics - fix sync lost after resume on some laptops

2013-06-04T16:33:16Z

In summary, the symptom is intermittent key events lost after resume on some machines with synaptics touchpad (seems this is synaptics _only_), and key events loss is due to serio port reconnect after psmouse sync lost. Removing psmouse and inserting it back during the suspend/resume process is able to work around the issue, so the difference between psmouse_connect() and psmouse_reconnect() is the key to the root cause of this problem. After comparing the two different paths, synaptics driver has its own implementation of synaptics_reconnect(), and the missing psmouse_probe() seems significant, the patch below added psmouse_probe() to the reconnect process, and has been verified many times that the issue could not be reliably reproduced. There are two PS/2 commands in psmouse_probe(): 1. PSMOUSE_CMD_GETID 2. PSMOUSE_CMD_RESET_DIS Only the PSMOUSE_CMD_GETID seems to be significant. The PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying several times. So we have only implemented this patch to issue the PSMOUSE_CMD_GETID so far. Tested-by: Daniel Manrique Signed-off-by: James M Leddy Signed-off-by: Dmitry Torokhov

Input: navpoint - pass correct pointer to free_irq()

2013-05-23T16:38:41Z

free_irq() expects the same pointer that was passed to request_irq(), otherwise the IRQ is not freed. The issue was found using the following coccinelle script: @r1@ type T; T devid; @@ request_irq(..., devid) @r2@ type r1.T; T devid; position p; @@ free_irq@p(..., devid) @@ position p != r2.p; @@ *free_irq@p(...) Signed-off-by: Lars-Peter Clausen Signed-off-by: Dmitry Torokhov

Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux

2013-05-09T16:59:16Z

Pull removal of GENERIC_GPIO from Grant Likely: "GENERIC_GPIO now synonymous with GPIOLIB. There are no longer any valid cases for enableing GENERIC_GPIO without GPIOLIB, even though it is possible to do so which has been causing confusion and breakage. This branch does the work to completely eliminate GENERIC_GPIO." * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux: gpio: update gpio Chinese documentation Remove GENERIC_GPIO config option Convert selectors of GENERIC_GPIO to GPIOLIB blackfin: force use of gpiolib m68k: coldfire: use gpiolib mips: pnx833x: remove requirement for GENERIC_GPIO openrisc: default GENERIC_GPIO to false avr32: default GENERIC_GPIO to false xtensa: remove explicit selection of GENERIC_GPIO sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB powerpc: remove redundant GENERIC_GPIO selection unicore32: default GENERIC_GPIO to false unicore32: remove unneeded select GENERIC_GPIO arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB arm: remove redundant GENERIC_GPIO selection mips: alchemy: require gpiolib mips: txx9: change GENERIC_GPIO to GPIOLIB mips: loongson: use GPIO driver on CONFIG_GPIOLIB mips: remove redundant GENERIC_GPIO select

Input: gpio_mouse - remove redundant platform_set_drvdata()

2013-05-06T03:15:18Z

Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat Acked-by: Hans-Christian Egtvedt Signed-off-by: Dmitry Torokhov