Re: [PATCH 1/3] platform/x86: thinkpad_acpi: convert mutex_lock() to guard(mutex)

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Ilpo,

On Tue, Sep 15, 2026 at 02:33:27PM +0300, Ilpo Järvinen wrote:
> On Wed, 5 Aug 2026, Dmitry Torokhov wrote:
> 
> > Convert straightforward mutex_lock() and mutex_unlock() usages for
> > hotkey_mutex, tpacpi_inputdev_send_mutex, kbdlight_mutex, lcdshadow_dev
> > lock, and dytc_mutex to guard(mutex) and scoped_guard(mutex) helpers
> > from linux/cleanup.h.
> > 
> > This improves code readability and ensures that mutexes are
> > automatically released when exiting their respective scopes.
> > 
> > Assisted-by: Antigravity:gemini-3.6-flash
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> Hi,
> 
> I've now applied this patch 1 into the review-ilpo-next branch. I 
> converted the newly added mutex_lock/unlock() pair in hotkey_poll_setup() 
> while at it but it would have been nice if you'd have made them a series 
> instead and done that for me as there was unclear dependency between the 
> input_device_enabled() change and this one because of the newly added 
> mutex_lock/unlock() pair. Hopefully the next time. :-)
> 
> Patch 2 seems contested and changes behavior without telling upfront. And 
> a return value change shouldn't be hidden into otherwise mechanical 
> conversion patch like that anyway. The change is generally good otherwise
> so please resend it once the return value thing is addressed.

Sorry about this, that was my oversight and not an intentional change. I
reverted to reporting '0' even if something fails inside of
brightness_get().

> 
> Sashiko complains about the strscpy() placement in patch 3 and that looks 
> valid concern to me.

Fixed up as well. I just sent out updated series.

Thanks.

-- 
Dmitry