From: sashiko-bot@kernel.org
To: "Derek J. Clark" <derekjohn.clark@gmail.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v2 06/11] HID: hid-lenovo-go-s: Add suspend function and gate access under bool.
Date: Sat, 17 Oct 2026 02:03:40 +0000 [thread overview]
Message-ID: <sashiko-outbox-175174@kernel.org> (raw)
In-Reply-To: <20261017013956.2440130-7-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] HID: hid-lenovo-go-s: missing resume callback after hid_gos_suspend()
--
commit 321a5a0af7e8cc8645f93abe71148630082f227b
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-lenovo-go-s: Add suspend function and gate access under bool.
This patch adds a suspend callback to cancel the initial configuration
delayed work if the device suspends before setup finishes, and gates
sysfs and LED brightness access behind registration flags set when
cfg_setup() completes.
> diff --git a/drivers/hid/hid-lenovo-go-s.c b/drivers/hid/hid-lenovo-go-s.c
> index ed08200e3571a..14aeddd65704b 100644
> --- a/drivers/hid/hid-lenovo-go-s.c
> +++ b/drivers/hid/hid-lenovo-go-s.c
[ ... ]
> @@ -1455,9 +1564,24 @@ static void hid_gos_cfg_remove(struct hid_device *hdev)
>
> static int hid_gos_cfg_reset_resume(struct hid_device *hdev)
> {
> + bool gp_registered, rgb_registered;
> u8 os_mode = drvdata.os_mode;
> int ret;
>
> + /* Pairs with smp_store_release from gos_cfg_setup */
> + gp_registered = smp_load_acquire(&drvdata.gp_registered);
> + /* Pairs with smp_store_release from gos_cfg_setup */
> + rgb_registered = smp_load_acquire(&drvdata.rgb_registered);
> + if (!gp_registered || !rgb_registered) {
> + ret = schedule_delayed_work(&drvdata.gos_cfg_setup, msecs_to_jiffies(2));
> + if (!ret) {
> + dev_err(&hdev->dev, "Failed to schedule startup delayed work\n");
> + return -ENODEV;
> + }
> +
> + return 0;
> + }
> +
> ret = mcu_property_out(drvdata.hdev, SET_GAMEPAD_CFG,
> FEATURE_OS_MODE, &os_mode, 1);
> if (ret < 0)
> @@ -1546,6 +1670,30 @@ static int hid_gos_reset_resume(struct hid_device *hdev)
> return 0;
> }
>
> +static int hid_gos_cfg_suspend(void)
> +{
> + cancel_delayed_work_sync(&drvdata.gos_cfg_setup);
> +
> + return 0;
> +}
> +
> +static int hid_gos_suspend(struct hid_device *hdev, pm_message_t msg)
> +{
> + int ret;
> + u8 ep;
> +
> + /* Safe assumption. SET_INTERFACE ioctl can't be used while driver is bound */
> + ret = get_endpoint_address(hdev);
> + if (ret <= 0)
> + return 0;
> +
> + ep = ret;
> + if (ep == GO_S_CFG_INTF_IN)
> + return hid_gos_cfg_suspend();
> +
> + return 0;
> +}
> +
> static const struct hid_device_id hid_gos_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_QHE,
> USB_DEVICE_ID_LENOVO_LEGION_GO_S_XINPUT) },
> @@ -1562,6 +1710,7 @@ static struct hid_driver hid_lenovo_go_s = {
> .remove = hid_gos_remove,
> .raw_event = hid_gos_raw_event,
> .reset_resume = pm_ptr(hid_gos_reset_resume),
> + .suspend = pm_ptr(hid_gos_suspend),
> };
> module_hid_driver(hid_lenovo_go_s);
[Severity: Medium]
What happens if the device suspends before cfg_setup() finishes and then
resumes via a normal non-reset resume?
In hid_gos_cfg_probe(), drvdata.gos_cfg_setup is scheduled with a 2ms
delay. If a system suspend where USB bus power is maintained, runtime
autosuspend, or an aborted suspend rollback in usbhid occurs before
cfg_setup() sets drvdata.gp_registered and drvdata.rgb_registered,
hid_suspend() calls:
hid_driver_suspend()
-> hid_gos_suspend()
-> hid_gos_cfg_suspend()
-> cancel_delayed_work_sync(&drvdata.gos_cfg_setup)
When the device subsequently resumes without a USB port reset (or rolls
back from a failed suspend), usbhid calls:
hid_resume()
-> hid_resume_common()
-> hid_driver_resume()
which invokes hdev->driver->resume rather than hdev->driver->reset_resume.
Because hid_lenovo_go_s only sets .reset_resume and leaves .resume NULL,
drvdata.gos_cfg_setup is never rescheduled on that path. Would that leave
drvdata.gp_registered and drvdata.rgb_registered permanently false (and in
the later patch "HID: hid-lenovo-go-s: Move sysfs group creation into
delayed work", prevent the sysfs groups and LED device from ever being
registered)?
Should hid_lenovo_go_s also wire up a .resume callback to reschedule
drvdata.gos_cfg_setup when gp_registered or rgb_registered is false?
титься
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261017013956.2440130-1-derekjohn.clark@gmail.com?part=6
next prev parent reply other threads:[~2026-10-17 2:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 1:39 [PATCH v2 00/11] HID: hid-lenovo-go-s: Fix various bugs Derek J. Clark
2026-10-17 1:39 ` [PATCH v2 01/11] HID: hid-lenovo-go-s: Return ret instead of 0 in mcu_property_out() Derek J. Clark
2026-10-17 1:39 ` [PATCH v2 02/11] HID: hid-lenovo-go-s: Bound stale reply window before reusing send_cmd_complete Derek J. Clark
2026-10-17 1:39 ` [PATCH v2 03/11] HID: hid-lenovo-go-s: Prevent deadlock if device removed during setup Derek J. Clark
2026-10-17 1:39 ` [PATCH v2 04/11] HID: hid-lenovo-go-s: Use pm_ptr for reset_resume callback Derek J. Clark
2026-10-17 1:39 ` [PATCH v2 05/11] HID: hid-lenovo-go-s: Add kobject_uevent notify during reset-resume Derek J. Clark
2026-10-17 1:39 ` [PATCH v2 06/11] HID: hid-lenovo-go-s: Add suspend function and gate access under bool Derek J. Clark
2026-10-17 2:03 ` sashiko-bot [this message]
2026-10-17 1:39 ` [PATCH v2 07/11] HID: hid-lenovo-go-s: Move attribute init to after device query Derek J. Clark
2026-10-17 2:07 ` sashiko-bot
2026-10-17 1:39 ` [PATCH v2 08/11] HID: hid-lenovo-go-s: Reorganize and rename hid_gos_cfg Derek J. Clark
2026-10-17 1:39 ` [PATCH v2 09/11] HID: hid-lenovo-go-s: Move static led_classdev_mc to drvdata struct Derek J. Clark
2026-10-17 2:14 ` sashiko-bot
2026-10-17 1:39 ` [PATCH v2 10/11] HID: hid-lenovo-go-s: Use devm_kzalloc for drvdata Derek J. Clark
2026-10-17 2:23 ` sashiko-bot
2026-10-17 1:39 ` [PATCH v2 11/11] HID: hid-lenovo-go-s: Stop and close device on probe failure Derek J. Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-175174@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=derekjohn.clark@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.