From: sashiko-bot@kernel.org
To: "Lee Jones" <lee@kernel.org>, linux-input@vger.kernel.org
Cc: dmitry.torokhov@gmail.com
Subject: Re: [STABLE v6.1 2/6] HID: hid-steam: Make client_opened a counter
Date: Tue, 13 Oct 2026 09:43:37 +0000 [thread overview]
Message-ID: <sashiko-outbox-169373@kernel.org> (raw)
In-Reply-To: <20261013091204.529049-2-lee@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] hid: redundant client_opened counter due to core refcounting
--
commit 60750525b808a9b3b327f3fb2200f042e05ff888
Author: Vicki Pfau <vi@endrift.com>
HID: hid-steam: Make client_opened a counter
This commit replaces the client_opened boolean flag with a counter to track
the number of open clients. It increments and decrements the counter in the
low-level open and close callbacks to ensure the driver does not incorrectly
assume there are no remaining clients when one of multiple clients closes.
> diff --git a/drivers/hid/hid-steam.c b/drivers/hid/hid-steam.c
> index 2f5e9d3e64991..4a0a13b0ae62f 100644
> --- a/drivers/hid/hid-steam.c
> +++ b/drivers/hid/hid-steam.c
[ ... ]
> @@ -634,7 +634,7 @@ static int steam_client_ll_open(struct hid_device *hdev)
> struct steam_device *steam = hdev->driver_data;
>
> mutex_lock(&steam->mutex);
> - steam->client_opened = true;
> + steam->client_opened++;
[Severity: Low]
This introduces a manual counter increment here, assuming the callback can
be invoked concurrently or multiple times for the same device.
However, the HID core strictly serializes low-level operations using
hdev->ll_open_lock and internally refcounts them via hdev->ll_open_count.
Looking at hid_hw_open() in hid-core.c:
if (!hdev->ll_open_count++) {
ret = hdev->ll_driver->open(hdev);
This guarantees that the driver's .open callback is invoked exactly once on
the 0->1 transition.
Is it possible for steam_client_ll_open() to be called multiple times in an
unbalanced manner, or does the core refcounting make this counter redundant?
> mutex_unlock(&steam->mutex);
>
> steam_input_unregister(steam);
> @@ -654,12 +654,12 @@ static void steam_client_ll_close(struct hid_device *hdev)
> spin_unlock_irqrestore(&steam->lock, flags);
>
> mutex_lock(&steam->mutex);
> - steam->client_opened = false;
> - if (connected)
> + steam->client_opened--;
[Severity: Low]
Similarly, the HID core prevents unbalanced low-level closes.
Looking at hid_hw_close() in hid-core.c:
if (!--hdev->ll_open_count)
hdev->ll_driver->close(hdev);
This ensures the .close callback is invoked exactly once on the 1->0
transition.
The manual decrement relies on the premise that client_opened could
legitimately be greater than 1. With the core refcounting in place, it appears
it cannot. Could this counter be adding unnecessary code complexity based on
the false premise of multiple concurrent opens?
> - if (connected)
> + if (connected && !steam->client_opened)
> steam_set_lizard_mode(steam, lizard_mode);
> mutex_unlock(&steam->mutex);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013091204.529049-1-lee@kernel.org?part=2
next prev parent reply other threads:[~2026-10-13 9:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 9:11 [STABLE v6.1 1/6] HID: hid-steam: Fix cleanup in probe() Lee Jones
2026-10-13 9:11 ` [STABLE v6.1 2/6] HID: hid-steam: Make client_opened a counter Lee Jones
2026-10-13 9:43 ` sashiko-bot [this message]
2026-10-13 9:11 ` [STABLE v6.1 3/6] HID: steam: Fully unregister controller when hidraw is opened Lee Jones
2026-10-13 9:12 ` [STABLE v6.1 4/6] HID: steam: Rearrange teardown sequence Lee Jones
2026-10-13 9:12 ` [STABLE v6.1 5/6] HID: steam: Refactor registration Lee Jones
2026-10-13 9:12 ` [STABLE v6.1 6/6] HID: steam: Clean up locking Lee Jones
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-169373@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=lee@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox