BMC/Intel-BMC/linux.git/drivers/input, branch v5.4.20

Input: max77650-onkey - add of_match table

2020-02-05T21:22:49+00:00

[ Upstream commit ce535a2efb48d8d4c4e4b97e2764d7cee73d9b55 ] We need the of_match table if we want to use the compatible string in the pmic's child node and get the onkey driver loaded automatically. Signed-off-by: Bartosz Golaszewski Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: evdev - convert kzalloc()/vzalloc() to kvzalloc()

2020-02-05T21:22:48+00:00

[ Upstream commit 7f439bc2d7e8c8cc4e1bab08ab7fe1bb73c9b268 ] We observed a large(order-3) allocation in evdev_open() and it may cause an OOM kernel panic in kzalloc(), before we getting to the vzalloc() fallback. Fix it by converting kzalloc()/vzalloc() to kvzalloc() to avoid the OOM killer logic as we have a vmalloc fallback. InputReader invoked oom-killer: gfp_mask=0x240c2c0 (GFP_KERNEL|__GFP_NOWARN|__GFP_COMP|__GFP_ZERO), nodemask=0, order=3, oom_score_adj=-900 ... (dump_backtrace) from (show_stack+0x18/0x1c) (show_stack) from (dump_stack+0x94/0xa8) (dump_stack) from (dump_header+0x7c/0xe4) (dump_header) from (out_of_memory+0x334/0x348) (out_of_memory) from (__alloc_pages_nodemask+0xe9c/0xeb8) (__alloc_pages_nodemask) from (kmalloc_order_trace+0x34/0x128) (kmalloc_order_trace) from (__kmalloc+0x258/0x36c) (__kmalloc) from (evdev_open+0x5c/0x17c) (evdev_open) from (chrdev_open+0x100/0x204) (chrdev_open) from (do_dentry_open+0x21c/0x354) (do_dentry_open) from (vfs_open+0x58/0x84) (vfs_open) from (path_openat+0x640/0xc98) (path_openat) from (do_filp_open+0x78/0x11c) (do_filp_open) from (do_sys_open+0x130/0x244) (do_sys_open) from (SyS_openat+0x14/0x18) (SyS_openat) from (__sys_trace_return+0x0/0x10) ... Normal: 12488*4kB (UMEH) 6984*8kB (UMEH) 2101*16kB (UMEH) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 139440kB HighMem: 206*4kB (H) 131*8kB (H) 42*16kB (H) 2*32kB (H) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2608kB ... Kernel panic - not syncing: Out of memory and no killable processes... Signed-off-by: Miles Chen Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: sun4i-ts - add a check for devm_thermal_zone_of_sensor_register

2020-01-29T15:45:29+00:00

commit 97e24b095348a15ec08c476423c3b3b939186ad7 upstream. The driver misses a check for devm_thermal_zone_of_sensor_register(). Add a check to fix it. Fixes: e28d0c9cd381 ("input: convert sun4i-ts to use devm_thermal_zone_of_sensor_register") Signed-off-by: Chuhong Yuan Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: pegasus_notetaker - fix endpoint sanity check

2020-01-29T15:45:29+00:00

commit bcfcb7f9b480dd0be8f0df2df17340ca92a03b98 upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could be used by a malicious device (or USB descriptor fuzzer) to trigger a NULL-pointer dereference. Fixes: 1afca2b66aac ("Input: add Pegasus Notetaker tablet driver") Signed-off-by: Johan Hovold Acked-by: Martin Kepplinger Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-2-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: aiptek - fix endpoint sanity check

2020-01-29T15:45:29+00:00

commit 3111491fca4f01764e0c158c5e0f7ced808eef51 upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could lead to the driver binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 8e20cf2bce12 ("Input: aiptek - fix crash on detecting device without endpoints") Signed-off-by: Johan Hovold Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-3-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: gtco - fix endpoint sanity check

2020-01-29T15:45:28+00:00

commit a8eeb74df5a6bdb214b2b581b14782c5f5a0cf83 upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could lead to the driver binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 162f98dea487 ("Input: gtco - fix crash on detecting device without endpoints") Signed-off-by: Johan Hovold Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-5-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: sur40 - fix interface sanity checks

2020-01-29T15:45:28+00:00

commit 6b32391ed675827f8425a414abbc6fbd54ea54fe upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: bdb5c57f209c ("Input: add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)") Signed-off-by: Johan Hovold Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-8-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: pm8xxx-vib - fix handling of separate enable register

2020-01-29T15:45:28+00:00

commit 996d5d5f89a558a3608a46e73ccd1b99f1b1d058 upstream. Setting the vibrator enable_mask is not implemented correctly: For regmap_update_bits(map, reg, mask, val) we give in either regs->enable_mask or 0 (= no-op) as mask and "val" as value. But "val" actually refers to the vibrator voltage control register, which has nothing to do with the enable_mask. So we usually end up doing nothing when we really wanted to enable the vibrator. We want to set or clear the enable_mask (to enable/disable the vibrator). Therefore, change the call to always modify the enable_mask and set the bits only if we want to enable the vibrator. Fixes: d4c7c5c96c92 ("Input: pm8xxx-vib - handle separate enable register") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200114183442.45720-1-stephan@gerhold.net Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Revert "Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers"

2020-01-29T15:45:27+00:00

commit 8ff771f8c8d55d95f102cf88a970e541a8bd6bcf upstream. This reverts commit a284e11c371e446371675668d8c8120a27227339. This causes problems (drifting cursor) with at least the F11 function that reads more than 32 bytes. The real issue is in the F54 driver, and so this should be fixed there, and not in rmi_smbus.c. So first revert this bad commit, then fix the real problem in F54 in another patch. Signed-off-by: Hans Verkuil Reported-by: Timo Kaufmann Fixes: a284e11c371e ("Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200115124819.3191024-2-hverkuil-cisco@xs4all.nl Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: keyspan-remote - fix control-message timeouts

2020-01-29T15:45:27+00:00

commit ba9a103f40fc4a3ec7558ec9b0b97d4f92034249 upstream. The driver was issuing synchronous uninterruptible control requests without using a timeout. This could lead to the driver hanging on probe due to a malfunctioning (or malicious) device until the device is physically disconnected. While sleeping in probe the driver prevents other devices connected to the same hub from being added to (or removed from) the bus. The USB upper limit of five seconds per request should be more than enough. Fixes: 99f83c9c9ac9 ("[PATCH] USB: add driver for Keyspan Digital Remote") Signed-off-by: Johan Hovold Reviewed-by: Greg Kroah-Hartman Cc: stable # 2.6.13 Link: https://lore.kernel.org/r/20200113171715.30621-1-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman