- Jan 11, 2020
-
-
Miles Chen authored
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 <miles.chen@mediatek.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- Dec 14, 2019
-
-
Anson Huang authored
When reading key state from SCU, the response data from SCU firmware is 4 bytes due to MU message protocol, but ONLY the first byte is the key state, other 3 bytes could be some dirty data, so we should ONLY take the first byte as key state to avoid reporting incorrect state. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Fixes: 688f1dfb ("Input: keyboard - imx_sc: Add i.MX system controller key support") Link: https://lore.kernel.org/r/1576202909-1661-1-git-send-email-Anson.Huang@nxp.com Signed-off-by:
-
Dmitry Torokhov authored
If we happen to have a garbage in input device's keycode table with values too big we'll end up doing clear_bit() with offset way outside of our bitmaps, damaging other objects within an input device or even outside of it. Let's add sanity checks to the returned old keycodes. Reported-by:
<syzbot+c769968809f9359b07aa@syzkaller.appspotmail.com> Reported-by:
<syzbot+76f3a30e88d256644c78@syzkaller.appspotmail.com> Link: https://lore.kernel.org/r/20191207212757.GA245964@dtor-ws Signed-off-by:
-
Arnd Bergmann authored
Going through all uses of timeval, I noticed that we screwed up input_event in the previous attempts to fix it: The time fields now match between kernel and user space, but all following fields are in the wrong place. Add the required padding that is implied by the glibc timeval definition to fix the layout, and use a struct initializer to avoid leaking kernel stack data. Fixes: 141e5dca ("Input: input_event - fix the CONFIG_SPARC64 mixup") Fixes: 2e746942 ("Input: input_event - provide override for sparc64") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20191213204936.3643476-2-arnd@arndb.de Cc: stable@vger.kernel.org Signed-off-by:
-
Dmitry Torokhov authored
uinput device is always available for writing so we should always report EPOLLOUT and EPOLLWRNORM bits, not only when there is nothing to read from the device. Fixes: d4b675e1 ("Input: uinput - fix returning EPOLLOUT from uinput_poll") Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20191209202254.GA107567@dtor-ws Signed-off-by:
-
- Dec 07, 2019
-
-
Dmitry Torokhov authored
Prepare second round of updates for 5.5 merge window.
-
- Dec 05, 2019
-
-
Hans Verkuil authored
This increment of rmi_smbus in rmi_smb_read/write_block() causes garbage to be read/written. The first read of SMB_MAX_COUNT bytes is fine, but after that it is nonsense. Trial-and-error showed that by dropping the increment of rmiaddr everything is fine and the F54 function properly works. I tried a hack with rmi_smb_write_block() as well (writing to the same F54 touchpad data area, then reading it back), and that suggests that there too the rmiaddr increment has to be dropped. It makes sense that if it has to be dropped for read, then it has to be dropped for write as well. It looks like the initial work with F54 was done using i2c, not smbus, and it seems nobody ever tested F54 with smbus. The other functions all read/write less than SMB_MAX_COUNT as far as I can tell, so this issue was never noticed with non-F54 functions. With this change I can read out the touchpad data correctly on my Lenovo X1 Carbon 6th Gen laptop. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl Cc: stable@vger.kernel.org Signed-off-by:
-
Lucas Stach authored
F34 is a bit special as it reinitializes the device and related driver structs during the firmware update. This clears the fn_irq_mask which will then prevent F34 from receiving further interrupts, leading to timeouts during the firmware update. Make sure to reinitialize the IRQ enables at the appropriate times. The issue is in F34 code, but the commit in the fixes tag exposed the issue, as before this commit things would work by accident. Fixes: 363c5387 (Input: synaptics-rmi4 - avoid processing unknown IRQs) Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by:
-
Hans de Goede authored
The touchscreen on the Teclast X89 is mounted upside down in relation to the display orientation (the touchscreen itself is mounted upright, but the display is mounted upside-down). Add a quirk for this so that we send coordinates which match the display orientation. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20191202085636.6650-1-hdegoede@redhat.com Cc: stable@vger.kernel.org Signed-off-by:
-
Mathew King authored
Add keycode for toggling electronic privacy screen to the keycodes definition. Some new laptops have a privacy screen which can be toggled with a key on the keyboard. Signed-off-by:
Mathew King <mathewk@chromium.org> Link: https://lore.kernel.org/r/20191017163208.235518-1-mathewk@chromium.org Signed-off-by:
-
Marcel Holtmann authored
Always return EPOLLOUT from uinput_poll to allow polling /dev/uinput for writable state. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Link: https://lore.kernel.org/r/20191204025014.5189-1-marcel@holtmann.org Signed-off-by:
-
Dmitry Torokhov authored
Gratuitous NULL initializers rarely help and often prevent compiler from warning about using uninitialized variable. Let's remove them. Reviewed-by:
-
- Nov 26, 2019
-
-
Robin van der Gracht authored
The first generation i.MX6 processors does not send an interrupt when the power key is pressed. It sends a power down request interrupt if the key is released before a hard shutdown (5 second press). This should allow software to bring down the SoC safely. For this driver to work as a regular power key with the older SoCs, we need to send a keypress AND release when we get the power down request irq. Signed-off-by:
Robin van der Gracht <robin@protonic.nl> Link: https://lore.kernel.org/r/20191125161210.8275-1-robin@protonic.nl Signed-off-by:
-
Dmitry Torokhov authored
Prepare input updates for 5.5 merge window.
-
- Nov 23, 2019
-
-
Hans Verkuil authored
The v4l2-compliance utility reported several V4L2 API compliance issues: - the sequence counter wasn't filled in - the sequence counter wasn't reset to 0 at the start of streaming - the returned field value wasn't set to V4L2_FIELD_NONE - the timestamp wasn't set - the payload size was undefined if an error was returned - min_buffers_needed doesn't need to be initialized Fix these issues. Signed-off-by:
-
Hans Verkuil authored
Some Lenovo X1 Carbon Gen 6 laptops report LEN0091. Add this to the smbus_pnp_ids list. Signed-off-by:
-
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/1574306373-29581-1-git-send-email-krzk@kernel.org Signed-off-by:
-
Lyude Paul authored
This reverts commit 68b9c5066e39af41d3448abfc887c77ce22dd64d. Ugh, I really dropped the ball on this one :\. So as it turns out RMI4 works perfectly fine on the X1 Extreme Gen 2 except for one thing I didn't notice because I usually use the trackpoint: clicking with the touchpad. Somehow this is broken, in fact we don't even seem to indicate BTN_LEFT as a valid event type for the RMI4 touchpad. And, I don't even see any RMI4 events coming from the touchpad when I press down on it. This only seems to work for PS/2 mode. Since that means we have a regression, and PS/2 mode seems to work fine for the time being - revert this for now. We'll have to do a more thorough investigation on this. Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20191119234534.10725-1-lyude@redhat.com Signed-off-by:
-
- Nov 16, 2019
-
-
Lyude Paul authored
Just got one of these for debugging some unrelated issues, and noticed that Lenovo seems to have gone back to using RMI4 over smbus with Synaptics touchpads on some of their new systems, particularly this one. So, let's enable RMI mode for the X1 Extreme 2nd Generation. Signed-off-by:
-
Anson Huang authored
The SCU message's data field used for receiving response data from SCU should be 32-bit width, as SCU will send back 32-bit width data. This solves kernel panic when CONFIG_CC_HAVE_STACKPROTECTOR_SYSREG is enabled. [ 1.950768] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted [ 1.980607] Workqueue: events imx_sc_check_for_events [ 1.985657] Call trace: [ 1.988104] dump_backtrace+0x0/0x140 [ 1.991768] show_stack+0x14/0x20 [ 1.995090] dump_stack+0xb4/0xf8 [ 1.998407] panic+0x158/0x324 [ 2.001463] print_tainted+0x0/0xa8 [ 2.004950] imx_sc_check_for_events+0x18c/0x190 [ 2.009569] process_one_work+0x198/0x320 [ 2.013579] worker_thread+0x48/0x420 [ 2.017252] kthread+0xf0/0x120 [ 2.020394] ret_from_fork+0x10/0x18 [ 2.023977] SMP: stopping secondary CPUs [ 2.027901] Kernel Offset: disabled [ 2.031391] CPU features: 0x0002,2100600c [ 2.035401] Memory Limit: none Signed-off-by:
-
Chuhong Yuan authored
The driver forgets to destroy workqueue in remove() similarly to what is done when probe() fails. Add a call to destroy_workqueue() to fix it. Since unregistration will wait for the work to finish, we do not need to cancel/flush the work instance in remove(). Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191114023405.31477-1-hslester96@gmail.com Signed-off-by:
-
Oliver Neukum authored
No timer must be left running when the device goes away. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-and-tested-by:
<syzbot+b6c55daa701fc389e286@syzkaller.appspotmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1573726121.17351.3.camel@suse.com Signed-off-by:
-
- Nov 13, 2019
-
-
Pan Bian authored
The device md->input is used after it is released. Setting the device data to NULL is unnecessary as the device is never used again. Instead, md->input should be assigned NULL to avoid accessing the freed memory accidently. Besides, checking md->si against NULL is superfluous as it points to a variable address, which cannot be NULL. Signed-off-by:
Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/1572936379-6423-1-git-send-email-bianpan2016@163.com Signed-off-by:
-
Lucas Stach authored
The driver for F54 just polls the status and doesn't even have a IRQ handler registered. Make sure to disable all F54 IRQs, so we don't crash the kernel on a nonexistent handler. Signed-off-by:
-
Sven Van Asbroeck authored
Only show the 'calibrate' sysfs attribute on chip flavours which support calibration by writing to a calibration register. Do this by adding a flag to the chip operations structure. Signed-off-by:
Sven Van Asbroeck <TheSven73@gmail.com> Link: https://lore.kernel.org/r/20191112210148.3535-2-TheSven73@gmail.com Signed-off-by:
-
Sven Van Asbroeck authored
Optionally allow the touch screen resolution to be set by adding it to the chip operations structure. If it is omitted (left zero), the resolution defaults to 64K. Which is the previously hard-coded value. Set the ili2117 resolution to 2048, as indicated in its datasheet. Signed-off-by:
-
Sven Van Asbroeck authored
The driver's method to retrieve the firmware version on ili2117/ ili2118 chip flavours is incorrect. The firmware version register address and layout are wrong. The firmware version is not actually used anywhere inside or outside this driver. There is a dev_dbg() print, but that is only visible when the developer explicitly compiles in debug support. Don't make the code more complicated to preserve a feature that no-one is using. Remove all code associated with chip firmware version. Signed-off-by:
-
- Nov 12, 2019
-
-
Stephan Gerhold authored
device_get_match_data is available now, so we can replace the call to of_device_get_match_data and remove the FIXME comment. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Andi Shyti <andi@etezian.org> Link: https://lore.kernel.org/r/20191007203343.101466-2-stephan@gerhold.net Signed-off-by:
-
Dmitry Torokhov authored
Bring in improvements to ili2xxx driver, including support for 2117A/2118A controllers.
-
Dmitry Torokhov authored
When I2C client is instantiated with I2C_CLIENT_WAKE flag (either via "wakeup-source" device property, or via board info flag), it will mark the main IRQ line as wakeup IRQ, which will ensure that it will be enabled for wakeup when system transitions to suspend state. Since our suspend/resume handlers were only managing IRQ wakeup state, they are no longer needed, and can be removed. Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant Signed-off-by: -
Dmitry Torokhov authored
I2C devices that are supposed to be wakeup sources should be instantiated with I2C_CLIENT_WAKE flag (which can be either set by in board info, or retrieved from "wakeup-source" property); individual drivers should not be marking devices as wakeup sources unconditionally. Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant Signed-off-by: -
Dmitry Torokhov authored
Instead of doing if/else if/else on the chip's model number let's define chip operations structure and use it to perform indirect calls. With number of protocols supported by the driver growing, this makes it better maintainable. This change includes fixes to checks whether the driver should continue polling the controller by Sven Van Asbroeck <thesven73@gmail.com>. Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant Signed-off-by: -
Dmitry Torokhov authored
We are using devm_input_allocate_device() that set's up the parent for us, no need to do it ourselves. Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant Signed-off-by: -
Dmitry Torokhov authored
input_mt_init_slots() may fail and we need to handle such failures. Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant Signed-off-by: -
Dmitry Torokhov authored
Let's switch the driver to using threaded IRQ so that we do not need to manage the interrupt and work separately, and we do not acknowledge interrupt until we finished handling it completely. Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant Tested-by: Marek Vasut <marex@denx.de> # ILI2117 Signed-off-by: -
Marek Vasut authored
Add support for ILI2117 touch controller. This controller is similar to the ILI210x and ILI251x, except for the following differences: - Reading out of touch data must happen at most 300 mS after the interrupt line was asserted. No command must be sent, the data are returned upon pure I2C read of 43 bytes long. - Supports 10 simultaneous touch inputs. - Touch data format is slightly different. Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by: Rob Herring <robh@kernel.org> # for DT binding Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant Signed-off-by:
-
Marcel Ziswiler authored
Update example in ad7879 device tree documentation to use generic touch controller node names. Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191026090403.3057-3-marcel@ziswiler.com Signed-off-by:
-
Flavio Suligoi authored
Fix spelling mistake. Signed-off-by:
Flavio Suligoi <f.suligoi@asem.it> Link: https://lore.kernel.org/r/1573211947-660-1-git-send-email-f.suligoi@asem.it Signed-off-by:
-
- Nov 05, 2019
-
-
Lucas Stach authored
The body of the for loop is only ever run once as the second standard_report element is never changed from its initial zero init, so the loop condition is never satisfies after the first run. Equally the start member of the first element is never changed from 0, so the index offset is always a constant 0. Remove this needless obfuscation of the code and write it in a straight forward manner. Signed-off-by:
-
Andrew Duggan authored
The result_bits mask is no longer used by the driver and should be removed. Signed-off-by:
Andrew Duggan <aduggan@synaptics.com> Link: https://lore.kernel.org/r/20191025002527.3189-4-aduggan@synaptics.com Signed-off-by:
-
