kernel/linux.git/drivers/input, branch v4.6.3

Input: xpad - prevent spurious input from wired Xbox 360 controllers

2016-06-08T01:23:35+00:00

commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 upstream. After initially connecting a wired Xbox 360 controller or sending it a command to change LEDs, a status/response packet is interpreted as controller input. This causes the state of buttons represented in byte 2 of the controller data packet to be incorrect until the next valid input packet. Wireless Xbox 360 controllers are not affected. Writing a new value to the LED device while holding the Start button and running jstest is sufficient to reproduce this bug. An event will come through with the Start button released. Xboxdrv also won't attempt to read controller input from a packet where byte 0 is non-zero. It also checks that byte 1 is 0x14, but that value differs between wired and wireless controllers and this code is shared by both. I think just checking byte 0 is enough to eliminate unwanted packets. The following are some examples of 3-byte status packets I saw: 01 03 02 02 03 00 03 03 03 08 03 00 Signed-off-by: Cameron Gutman Signed-off-by: Pavel Rojtberg Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: xpad - move pending clear to the correct location

2016-06-08T01:23:35+00:00

commit 4efc6939a83c54fb3417541be48991afd0290ba3 upstream. otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27 Signed-off-by: Pavel Rojtberg Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: uinput - handle compat ioctl for UI_SET_PHYS

2016-06-08T01:23:35+00:00

commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream. When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS ioctl needs to be treated with special care, as it has the pointer size encoded in the command. Signed-off-by: Ricky Liang Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: pwm-beeper - fix - scheduling while atomic

2016-06-01T19:17:59+00:00

commit f49cf3b8b4c841457244c461c66186a719e13bcc upstream. Pwm config may sleep so defer it using a worker. On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0. Signed-off-by: Manfred Schlaegl Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

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

2016-05-12T19:47:49+00:00

Pull input subsystem fixes from Dmitry Torokhov. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: twl6040-vibra - fix DT node memory management Input: max8997-haptic - fix NULL pointer dereference Input: byd - update copyright header

Input: twl6040-vibra - fix DT node memory management

2016-05-10T00:07:04+00:00

commit e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support") made the separate vibra DT node to a subnode of the twl6040. It now calls of_find_node_by_name() to locate the "vibra" subnode. This function has a side effect to call of_node_put on() for the twl6040 parent node passed in as a parameter. This causes trouble later on. Solution: we must call of_node_get() before of_find_node_by_name() Signed-off-by: H. Nikolaus Schaller Signed-off-by: Dmitry Torokhov

Input: max8997-haptic - fix NULL pointer dereference

2016-05-09T16:33:33+00:00

NULL pointer derefence happens when booting with DTB because the platform data for haptic device is not set in supplied data from parent MFD device. The MFD device creates only platform data (from Device Tree) for itself, not for haptic child. Unable to handle kernel NULL pointer dereference at virtual address 0000009c pgd = c0004000 [0000009c] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM (max8997_haptic_probe) from [] (platform_drv_probe+0x4c/0xb0) (platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0) (driver_probe_device) from [] (__driver_attach+0xac/0xb0) (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c) (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218) (bus_add_driver) from [] (driver_register+0x78/0xf8) (driver_register) from [] (do_one_initcall+0x90/0x1d8) (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc) (kernel_init_freeable) from [] (kernel_init+0x8/0x114) (kernel_init) from [] (ret_from_fork+0x14/0x3c) Signed-off-by: Marek Szyprowski Cc: Fixes: 104594b01ce7 ("Input: add driver support for MAX8997-haptic") [k.kozlowski: Write commit message, add CC-stable] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dmitry Torokhov

Input: byd - update copyright header

2016-05-09T16:33:31+00:00

As pointed out by Richard, the changes to the comment got missed off the absolute mode patch somehow. Signed-off-by: Chris Diamand Signed-off-by: Dmitry Torokhov

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

2016-05-04T23:07:50+00:00

Pull input fixes from Dmitry Torokhov. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: atmel_mxt_ts - use mxt_acquire_irq in mxt_soft_reset Input: zforce_ts - fix dual touch recognition Input: twl6040-vibra - fix atomic schedule panic

Input: atmel_mxt_ts - use mxt_acquire_irq in mxt_soft_reset

2016-04-25T21:27:57+00:00

If using IRQF_TRIGGER_FALLING, then there is a race here: if the reset completes before we enable the IRQ, then CHG is already low and touch will be broken. This has been seen on Chromebook Pixel 2. A workaround is to reconfig T18 COMMSCONFIG to enable the RETRIGEN bit using mxt-app: mxt-app -W -T18 44 mxt-app --backup Tested-by: Tom Rini Signed-off-by: Nick Dyer Signed-off-by: Dmitry Torokhov