Re: [PATCH] HID: lenovo: Restore Fn-lock LED state on resume for tp10ubkbd devices

[Kean <rh_king@163.com>]

Hi,

Thank you for the review.

Regarding the potential issue you raised:

> [High] Unprotected state modifications / TOCTOU Race leading to Deadlock
>
> Could this new call to lenovo_led_set_tp10ubkbd() cause a deadlock during
> runtime resume?

In my initial testing, I performed system suspend/resume (S3) cycles and the
behavior was normal — the Fn-lock LED state was correctly restored after
resume with no hangs or lockups observed. I tested two scenarios:

1. Normal suspend/resume: suspend the system with the keyboard attached,
   then resume normally.
2. Detach-reconnect: suspend the system, physically detach the keyboard
   during suspend, resume the system, then re-attach the keyboard.

Both scenarios appeared to work correctly without issues.

However, I realize my testing only covered system suspend/resume (S3), not
runtime PM resume (which may hold different locks in the HID core). Your
analysis about a potential deadlock is reasonable and worth investigating
thoroughly. I need to:

- Test runtime resume scenarios specifically (e.g., autosuspend of the USB
  HID device).
- Verify there is no lock ordering conflict between led_report_mutex (held
  inside lenovo_led_set_tp10ubkbd) and any HID core locks that may already
  be held when reset_resume is called.

I will run additional tests covering these cases. If I can reproduce any
issue, I will submit a V2 with the appropriate fix. If not, I will follow
up with a detailed description of my testing methodology and conclusions.

Thanks again for your guidance.

Regards,
Kean