thingm_remove_rgb() needs to flush the workqueue after all the LED classes
have been unregistered, otherwise the removal might race with another LED
event coming, causing thingm_led_set() to schedule additional work after
thingm_remove_rgb() has flushed it. This obviously causes oops later, as
the scheduled work has been freed in the meantime.
In addition to that, move the hid_hw_stop() to an earlier place, so that
dmesg is not polluted by failure messages about not being able to write
the LED while the device is being shut down.
Reported-and-tested-by: Dylan Alex Simon <dylan-ker...@dylex.net>
Signed-off-by: Jiri Kosina <jkos...@suse.cz>
---
Queued in hid.git#for-3.18/upstream
drivers/hid/hid-thingm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
index 134be89..f206398 100644
--- a/drivers/hid/hid-thingm.c
+++ b/drivers/hid/hid-thingm.c
@@ -208,10 +208,10 @@ unregister_red:
static void thingm_remove_rgb(struct thingm_rgb *rgb)
{
- flush_work(&rgb->work);
led_classdev_unregister(&rgb->red.ldev);
led_classdev_unregister(&rgb->green.ldev);
led_classdev_unregister(&rgb->blue.ldev);
+ flush_work(&rgb->work);
}
static int thingm_probe(struct hid_device *hdev, const struct hid_device_id
*id)
@@ -286,10 +286,10 @@ static void thingm_remove(struct hid_device *hdev)
struct thingm_device *tdev = hid_get_drvdata(hdev);
int i;
+ hid_hw_stop(hdev);
+
for (i = 0; i < tdev->fwinfo->numrgb; ++i)
thingm_remove_rgb(tdev->rgb + i);
-
- hid_hw_stop(hdev);
}
static const struct hid_device_id thingm_table[] = {
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
