kernel/linux.git/drivers/input/input.c, branch v7.3-rc1

Input: reject inhibit and uninhibit requests on unregistering devices

2026-08-06T06:01:44+00:00

When an input device is being unregistered via input_unregister_device(), input_disconnect_device() sets dev->going_away = true under dev->mutex and releases the mutex. If a concurrent sysfs write to the inhibited attribute executes input_inhibit_device() or input_uninhibit_device(), it acquires dev->mutex. Because neither function checks dev->going_away (unlike input_open_device()), input_uninhibit_device() proceeds to call dev->open() and start polling on a device that is in the middle of being unregistered and torn down. Fix this by checking dev->going_away in input_inhibit_device() and input_uninhibit_device() under dev->mutex and returning -ENODEV if the device is going away. Fixes: a181616487db ("Input: Add "inhibited" property") Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.6-flash Link: https://patch.msgid.link/anEolqA35rGei9ql@google.com Signed-off-by: Dmitry Torokhov

Input: defer handler's start() until device is opened

2026-08-06T06:01:44+00:00

When registering an input handle, handler->start() is currently called immediately. However, the input device might not be fully opened or ready to process events at this stage, meaning any state synchronization events (like setting LED states) injected by the handler's start method might be dropped. Move the handler->start() invocation to input_open_device(). If it is the first handle opening the device, start() is called after the driver's open() method has successfully completed and the device is fully prepared. To facilitate this, factor out the device startup logic (calling driver's open and starting polling) into input_start_device(). For passive observer handlers, their start() method is also deferred until the handle is opened. Since opening a passive observer handle does not start the underlying hardware device, their start() method is called immediately upon opening, regardless of whether the device is active. Fixes: c7e8dc6ee6d5 ("Input: add start() method to input handlers") Link: https://patch.msgid.link/20260803005210.1251102-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: call handler->start() when uninhibiting device

2026-08-06T06:01:44+00:00

When an input device is inhibited via input_inhibit_device(), the driver is closed and physical feedback (like LEDs and sounds) is toggled off. However, from the input core's perspective, the handles remain open. When the device is later uninhibited, the driver is re-opened. While the core restores simple LED states via input_dev_toggle(), complex handlers (such as vt/keyboard) may need to re-synchronize their broader logical state with the hardware. Fixes: a181616487db ("Input: Add "inhibited" property") Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260803005210.1251102-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: clear inhibited flag before re-opening device on uninhibit

2026-08-06T06:01:44+00:00

When uninhibiting a device, we previously called dev->open() and started the poller before clearing dev->inhibited. Since drivers (like gpio_keys) often report initial state during open(), and pollers report events immediately upon starting, these initial events were dropped by input_get_disposition() because dev->inhibited was still true. Fix this by clearing dev->inhibited before calling dev->open(), ensuring initial events are delivered to handlers, and restoring dev->inhibited = true if dev->open() fails. Fixes: a181616487db ("Input: Add "inhibited" property") Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260803005210.1251102-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: ensure device is ready before delivering events

2026-08-06T06:01:44+00:00

When a device is opened via input_open_device(), the driver's open() callback is invoked. Some drivers, like cm109, submit URBs or perform other hardware initialization in their open() callbacks. However, the input core does not prevent dev->event() from being called concurrently during the driver's open() execution. For instance, if a console beep occurs, the kbd handler might inject an EV_SND event. This can lead to double list_add BUGs if the driver submits the same URB in both open() and event() paths without adequate synchronization. To fix this, introduce a ready flag in the input_dev structure. For complex devices (where dev->open is defined), this flag is set to true only after the driver's open() method successfully completes. The core now checks ready in input_event_dispose() and input_dev_toggle() to prevent events from reaching the hardware before it is fully prepared. For simple devices (no open callback), events are delivered immediately. We also replay the logical state in input_open_device() by calling input_dev_toggle() right after marking the device ready, ensuring no events are permanently lost. In the inhibit path, we ensure that physical feedback (LEDs/sounds) is turned off before the device is closed, and we synchronize the inhibited state transition under the event lock to prevent races with incoming events. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260803005210.1251102-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: stop force-feedback timer when unregistering input devices

2026-06-23T05:33:01+00:00

Memoryless force-feedback devices use a timer to manage playback of effects. When a driver for such a device is unbound (or the device is unregistered for other reasons), the driver typically frees its private data synchronously. However, the input_dev structure (and its associated force-feedback structures, including the timer) is only freed when the last user closes the corresponding device node. If userspace keeps the device node open while the device is unregistered (e.g., during driver unbind), the force-feedback timer can still fire after the driver's private data has been freed. Introduce a new 'stop' callback to struct ff_device, and call it from input_unregister_device() before the device is deleted. Implement this callback for memoryless devices and synchronously shut down the timer to ensure it is stopped and cannot be rearmed once unregistration happens. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov

Merge tag 'v7.0-rc3' into next

2026-03-12T17:44:42+00:00

Sync up with the mainline to brig up the latest changes, specifically changes to ALPS driver.

Input: export input_default_setkeycode

2026-02-23T21:43:16+00:00

Export input_default_setkeycode so that a driver can set a custom setkeycode handler to take some driver specific action but still call the default handler at some point. Signed-off-by: Fabio Baltieri Reviewed-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260222003717.471977-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook