Re: [PATCH] HID: hid-oxp: use cancel_delayed_work_sync() in remove

[Derek J. Clark]

On September 4, 2026 2:17:02 PM PDT, Tristan Madani <tristmd@xxxxxxxxx> wrote:
>Hi Derek,
>
>Thanks for the review.
>
>One thing the Sashiko bot flagged, and I think it's valid: if
>oxp_hid_probe() returns early on an unknown usage page (the
>default: return 0 path), the delayed work items are never
>initialized via INIT_DELAYED_WORK().  In that case,
>cancel_delayed_work_sync() in remove() would call __flush_work()
>on a zero-filled work struct, which hits WARN_ON(!work->func).
>
>The non-sync cancel_delayed_work() didn't trigger this because it
>never calls __flush_work().
>
>Do you think this path is actually reachable in practice, or are
>the usage page IDs exhaustive for all matched devices?  If it can
>happen, I can send a v2 that guards the cancels.
>
If the usage page rejects init then I think we can safely assume that it will be an effective gate.

There's a series in the works ATM that will make drvdata unique per hid dev after the usage page checka, so we could also wait for that and if it's not fixed by that series then gate on drvdata not being NULL.

Cheers,
Derek

>Thanks,
>Tristan