Re: [PATCH v14 2/4] HID: nintendo: Add rumble support for Switch 2 controllers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hid: timer catch-up storm in switch2_rumble_work() floods USB bus
--

commit d6948b1b7d2b1cb761599f94b49e78c667724675
Author: Vicki Pfau <vi@endrift.com>

HID: nintendo: Add rumble support for Switch 2 controllers

This commit adds rumble support for Switch 2 controllers, handling both the
HD Rumble linear resonant actuator type and the GameCube eccentric rotating
mass type. It implements a basic simulation of these rumble effects using
delayed work.

> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
> index 3a7c35375be60..e965076b10345 100644
> --- a/drivers/hid/hid-nintendo.c
> +++ b/drivers/hid/hid-nintendo.c
[ ... ]
> @@ -3251,6 +3305,128 @@ static void switch2_kref_put(struct kref *refcount)
[ ... ]
> +static void switch2_rumble_work(struct work_struct *work)
> +{
[ ... ]
> +	if (active) {
> +		unsigned long interval = msecs_to_jiffies(4);
> +		uint64_t current_jiffies = get_jiffies_64();
> +
> +		if (!ns2->last_rumble_work)
> +			ns2->last_rumble_work = current_jiffies;
> +		else
> +			ns2->last_rumble_work += interval;
> +
> +		/* Reschedule a little early to make sure the buffer never underruns */
> +		interval -= msecs_to_jiffies(2);
> +		if (ns2->last_rumble_work + interval >= current_jiffies)
> +			schedule_delayed_work(&ns2->rumble_work,
> +				ns2->last_rumble_work + interval - current_jiffies);
> +		else
> +			schedule_delayed_work(&ns2->rumble_work, 0);

[Severity: Medium]
Could this logic lead to a timer catch-up storm?

If the worker execution is delayed (for example, due to CPU load, workqueue
starvation, or a suspend/resume cycle), the target time is only advanced by
4ms on each execution, while the system time may be much further ahead.

When this happens, the work immediately reschedules itself with a 0 delay.
Because it might take many executions to catch up to the current time 4ms
at a time, this could loop rapidly. Is there a risk that this will hog the
workqueue and flood the USB subsystem with back-to-back synchronous
hid_hw_output_report calls, which might also distort the intended 4ms haptic
cadence?

> +	} else {
> +		ns2->last_rumble_work = 0;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929045607.2106149-1-vi@endrift.com?part=2