kernel/git/next/linux-next.git/drivers/input/touchscreen, branch master

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

2026-07-07T12:09:35+00:00

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

Input: sur40 - fix MAX_CONTACTS value based on PixelSense specification

2026-06-27T05:25:02+00:00

The Samsung SUR40 with Microsoft PixelSense is offically specified to support 52 simultaneuous touch contacts, not 64. The value of 64 was an unverified guess as noted by the FIXME comment. Update MAX_CONTACTS to match the documented hardware specification and remove the FIXME. Signed-off-by: Oliver Link: https://patch.msgid.link/20260614230847.4938-1-oliverburns.kernel@gmail.com Signed-off-by: Dmitry Torokhov

Input: mms114 - refactor chip variant handling using descriptors

2026-06-23T06:19:22+00:00

Instead of using an enum and conditional switch/if statements throughout the driver to handle differences between chip variants (MMS114, MMS134S, MMS136, MMS152, MMS345L), introduce a variant-specific descriptor structure that encapsulates variant-specific properties (name, event size, presence of configuration registers) and callbacks (such as get_version). Define descriptors for each supported chip and associate them with the matching entries in the OF and I2C device ID tables. This eliminates the need for variant checks in the driver logic, making it easier to support new chip variants in the future. Note that there is slight change in device names: MMS134S: "MELFAS MMS134 Touchscreen" -> "MELFAS MMS134S Touchscreen" MMS345L: "MELFAS MMS345 Touchscreen" -> "MELFAS MMS345L Touchscreen" Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616050912.1531241-6-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: mms114 - replace BUG() and fix alignment

2026-06-23T06:19:21+00:00

Avoid taking the machine down with BUG() if a caller ever requests a read spanning the write-only MODE_CONTROL register; warn and return -EINVAL so the driver can recover. Additionally, fix parameter alignment to match the open parenthesis in several functions to conform to the kernel coding style. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616050912.1531241-5-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: mms114 - replace udelay with usleep_range

2026-06-23T06:19:21+00:00

The driver currently uses udelay(MMS114_I2C_DELAY) (50us) to ensure a mandatory delay between I2C transfers in __mms114_read_reg() and mms114_write_reg(). Both functions invoke underlying I2C core operations (i2c_transfer, i2c_master_send) which acquire mutexes and sleep. Furthermore, the interrupt handler mms114_interrupt() is registered as a threaded IRQ handler. Since the entire execution path is fully sleepable, busy-waiting with udelay() for 50us unnecessarily wastes CPU cycles. Replace udelay() with usleep_range() to allow the CPU to enter low-power states or execute other tasks during the delay. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616050912.1531241-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: mms114 - use appropriate register argument types

2026-06-23T06:19:20+00:00

The MMS114 I2C touch controller uses 8-bit register addresses (0x01 to 0xF2) and 8-bit single-register data values. The helper functions previously declared reg and val as 32-bit unsigned int, requiring explicit bitwise masking (& 0xff) to narrow the values down to u8 before populating the I2C transfer buffers. Update reg and val parameters to u8 across mms114_read_reg(), mms114_write_reg(), and __mms114_read_reg() to accurately reflect the hardware specification and eliminate the redundant & 0xff masking. Additionally, update the val buffer pointer in __mms114_read_reg() from u8 * to void * to allow callers to pass data structures directly without requiring explicit casting. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260616050912.1531241-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: mms114 - prefer GPL over GPL v2 for module license

2026-06-23T06:19:20+00:00

As explained in commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity"), "GPL" and "GPL v2" have identical semantics in the module loader, but "GPL" is preferred to avoid unnecessary confusion and maintain consistency across the kernel. Change MODULE_LICENSE("GPL v2") to MODULE_LICENSE("GPL"). Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260616050912.1531241-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: mms114 - fix touch indexing for MMS134S and MMS136

2026-06-23T06:04:19+00:00

The MMS134S and MMS136 touch controllers have an event size of 6 bytes rather than 8 bytes. When __mms114_read_reg() reads the touch data packet from the device into the touch buffer, the events are packed tightly at 6-byte intervals. However, the driver iterates through the events using standard C array indexing (touch[index]), where each element is sizeof(struct mms114_touch) (8 bytes) apart. As a result, any touch events beyond the first one are read from incorrect offsets and parsed improperly. Fix this by explicitly calculating the byte offset for each touch event based on the device's specific event size. Fixes: 53fefdd1d3a3 ("Input: mms114 - support MMS136") Fixes: ab108678195f ("Input: mms114 - support MMS134S") Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: Bryam Vargas Link: https://patch.msgid.link/20260616050912.1531241-1-dmitry.torokhov@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

Input: goodix - clamp the device-reported contact count

2026-06-23T03:44:12+00:00

goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration. Fixes: a7ac7c95d468 ("Input: goodix - use max touch number from device config") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260612-b4-disp-6844625d-v1-1-df0aed080c9d@proton.me Signed-off-by: Dmitry Torokhov