Re: [PATCH 02/21] HID: add documentation and Coccinelle script for FF registration race

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

On Sun, Aug 16, 2026 at 08:52:51PM +0200, Julia Lawall wrote:
> > diff --git a/scripts/coccinelle/hid/ff_race.cocci b/scripts/coccinelle/hid/ff_race.cocci
> > new file mode 100644
> > index 000000000000..479f5d1e3184
> > --- /dev/null
> > +++ b/scripts/coccinelle/hid/ff_race.cocci
> > @@ -0,0 +1,34 @@
> > +/// Detect HID drivers that initialize force-feedback after hid_hw_start()
> > +/// when HID_CONNECT_HIDINPUT is used. This is a lifecycle violation as
> > +/// the input device is already registered.
> > +//
> > +// Confidence: High
> > +// Copyright: (C) 2026 Gemini. GPLv2.
> > +
> > +virtual report
> > +
> > +@r@
> > +identifier probe_fn;
> > +expression hdev, flags;
> > +position p1, p2;
> > +@@
> > +
> > +probe_fn(struct hid_device *hdev, ...) {
> > +  <...
> > +  hid_hw_start@p1(hdev, flags)
> > +  ...
> > +  \(input_ff_create\|input_ff_create_memless\)@p2(...)
> > +  ...>
> > +}
> 
> 
> This seems unnecessarily costly.  The pattern can be just:
> 
> hid_hw_start@p1(hdev, flags)
> ...
> \(input_ff_create\|input_ff_create_memless\)@p2(...)
> 
> Or does it matter that struct hid_device *hdev is the first parameter
> of the enclosing function?
> 

I guess not. I was trying to limit the check to what looks like HID
driver probe function, but that would miss similar issues in helpers
that use different order or set of arguments.

Thanks.

-- 
Dmitry