Re: [PATCH] platform/x86: thinkpad_acpi: Use input_device_enabled()

On Wed, Aug 5, 2026, at 11:52 AM, Dmitry Torokhov wrote:
> Hi Mark,
>
> On Wed, Aug 05, 2026 at 10:51:53AM -0400, Mark Pearson wrote:
>> 
>> 
>> On Wed, Aug 5, 2026, at 12:03 AM, Dmitry Torokhov wrote:
>> > From: Andrzej Pietrasiewicz <[email protected]>
>> >
>> > Use the new helper. Inspecting input device's 'users' member needs to be
>> > done under device's mutex, so add appropriate invocations.
>> >
>> > Signed-off-by: Andrzej Pietrasiewicz <[email protected]>
>> > Acked-by: Henrique de Moraes Holschuh <[email protected]>
>> > Link: https://lore.kernel.org/r/[email protected]
>> > Signed-off-by: Dmitry Torokhov <[email protected]>
>> > ---
>> >
>> > Not sure how this got stuck in my patch queue but it is still valid...
>> >
>> >  drivers/platform/x86/lenovo/thinkpad_acpi.c | 4 +++-
>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c 
>> > b/drivers/platform/x86/lenovo/thinkpad_acpi.c
>> > index 445e1403308e..f8e116e8a65d 100644
>> > --- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
>> > +++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
>> > @@ -2547,9 +2547,10 @@ static void hotkey_poll_setup(const bool 
>> > may_warn)
>> > 
>> >  	lockdep_assert_held(&hotkey_mutex);
>> > 
>> > +	mutex_lock(&tpacpi_inputdev->mutex);
>> >  	if (hotkey_poll_freq > 0 &&
>> >  	    (poll_driver_mask ||
>> > -	     (poll_user_mask && tpacpi_inputdev->users > 0))) {
>> > +	     (poll_user_mask && input_device_enabled(tpacpi_inputdev)))) {
>> >  		if (!tpacpi_hotkey_task) {
>> >  			tpacpi_hotkey_task = kthread_run(hotkey_kthread,
>> >  					NULL, TPACPI_NVRAM_KTHREAD_NAME);
>> > @@ -2566,6 +2567,7 @@ static void hotkey_poll_setup(const bool may_warn)
>> >  				  poll_user_mask, poll_driver_mask);
>> >  		}
>> >  	}
>> > +	mutex_unlock(&tpacpi_inputdev->mutex);
>> >  }
>> > 
>> >  static void hotkey_poll_setup_safe(const bool may_warn)
>> > -- 
>> 
>> Looks good to me.
>> 
>> Only note is that can you use guard(mutex)(&tpacpi_inputdev->mutex) instead of the lock/unlock? I think that's preferred these days.
>
> If that is desired the whole driver needs converting. I can do it in a
> separate patch(es) if you want.
>
Ah - good point. Not worth it for this IMO, unless the more experienced maintainers have a strong opinion :)

Mark