Re: hid-thingm: kernel panic on remove

[Dylan Alex Simon <dylan-kernel@dylex.net>]

> Hrm, what we really want is to first destroy the LED interface, otherwise 
> someone might have re-queued the workqueue through thingm_led_set() after 
> it has been flushed / cancelled already.
> 
> Could you please give it one more shot with the patch below? Thanks for 
> your prompt testing.
> 
> 
> diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
> index 134be89..3d8cf5e 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);
> +	cancel_work_sync(&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[] = {
> 

I think that did the trick.  I've run through the whole cycle about 20 times
in various conditions, and it seems solid so far.  Thanks!