Re: HID: logitech-hidpp: G920 FF init fails with -110 since "move FF initialization to .input_configured()"

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

Hi Gideon,

On Fri, Nov 06, 2026 at 07:24:03AM +0100, Gideon Heinz wrote:
> Short version: your patch
> fixes the 7.3.1 init failure, and the runtime errors I saw afterwards are
> unrelated to it.
>
> To your question: the constant effect did produce force, a slow pull to
> the left for several seconds, then it stopped.
[...]
> So this is your first case (commands queued after the input device was
> closed), not the init order. Everything while fftest held the device open
> was answered normally. The init order is inverted as you expected (the
> ping comes after FF init), but it caused no problem here.
>
> I then repeated the same fftest run (play constant, exit) on stock Arch
> 7.2.11-arch1-1 with the unpatched driver, with usbmon this time (capture
> attached, wheel is dev 7 on bus 3). The same thing happens.
[...]
> So the exit-time behaviour predates
> 7.3 and isn't caused by your patch. The init order on 7.2.11 is the old
> one (ping before FF init), so the capture pair also shows the inversion.
>
> Tested-by: Gideon Heinz <gideonheinz02@gmail.com>

Thank you very much for collecting both captures and comparing against
7.2.11! That confirms both that querying G920 FF ahead of the protocol
ping during probe works cleanly on the wheel, and that the exit-time
errors are the pre-existing race where closing the evdev descriptor
stops the USB interrupt IN URB while the async FF workqueue is still
draining stop/erase commands (with each command retrying 3 x 5 seconds
while nobody is listening for replies).

While looking through hid-logitech-hidpp I ran into a handful of other
bugs and lifetime issues around G920 force feedback and device teardown,
so I am about to send out an 18-patch series with you on the To: list.
It starts with fixes marked for 7.3 and stable (including the minimal
init fix carrying your Tested-by, draining the FF workqueue before
closing the HID transport on normal input close, switching FF work item
allocation to GFP_ATOMIC, and fixing an off-by-one on hardware slot 64),
followed by the probe-time G920 FF initialization rework,
disconnect/unbind teardown fixes, and general driver cleanups.

Not everything is fixed in this first batch yet - normal fftest exit
should drain cleanly now before the IN URB is stopped, but stalls on
close or teardown can still happen when device I/O is already inactive
(for instance on driver unbind with loaded effects, or writing the range
sysfs attribute while the input device is closed) because the 3 x 5s
retry loop on timeouts and synchronous FF upload/erase handling still
need follow-up work.

When you have a chance, could you please give the series a spin on your
G920, and if anything misbehaves or regresses, ideally bisect within the
series to pinpoint which patch broke it?

Thanks.

-- 
Dmitry