If the device is plugged/unplugged without giving time for mcp_init_work() to complete, we might kick in the devm free code path and thus have unavailable struct mcp_2221 while in delayed work. Canceling the delayed_work item is enough to solve the issue, because cancel_delayed_work_sync will prevent the work item to requeue itself. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> --- Similar to Pietro's series, we can see the pattern in hid-mcp2221, except that this time the ledclass is not involved. Link: https://lore.kernel.org/linux-input/20230125-hid-unregister-leds-v4-5-7860c5763c38@xxxxxxxxxxxxxxxx/ --- Changes in v2: - drop the spinlock/boolean - Link to v1: https://lore.kernel.org/r/20230215-wip-mcp2221-v1-1-d7d1da261a5c@xxxxxxxxxx --- drivers/hid/hid-mcp2221.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c index e61dd039354b..f74a977cf8f8 100644 --- a/drivers/hid/hid-mcp2221.c +++ b/drivers/hid/hid-mcp2221.c @@ -922,6 +922,9 @@ static void mcp2221_hid_unregister(void *ptr) /* This is needed to be sure hid_hw_stop() isn't called twice by the subsystem */ static void mcp2221_remove(struct hid_device *hdev) { + struct mcp2221 *mcp = hid_get_drvdata(hdev); + + cancel_delayed_work_sync(&mcp->init_work); } #if IS_REACHABLE(CONFIG_IIO) --- base-commit: d883fd110dc17308a1506c5bf17e00ce9fe7b2a2 change-id: 20230215-wip-mcp2221-979d4115efb5 Best regards, -- Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
