From dff674168878fe7b6d8b9ad60d62295ec517de79 Mon Sep 17 00:00:00 2001 From: Benjamin Tissoires Date: Mon, 1 Dec 2014 11:52:40 -0500 Subject: [PATCH] HID: wacom: fix freeze on open when autosuspend is on Since the conversion from USB to HID (in v3.17), some people reported a freeze on boot with the wacom driver. Hans managed to get a stacktrace: [ 240.272331] Call Trace: [ 240.272338] [] ? usb_hcd_submit_urb+0xa9/0xb10 [ 240.272347] [] schedule+0x29/0x70 [ 240.272355] [] schedule_preempt_disabled+0x16/0x20 [ 240.272363] [] __mutex_lock_slowpath+0xe5/0x230 [ 240.272372] [] mutex_lock+0x17/0x30 [ 240.272380] [] wacom_resume+0x22/0x50 [wacom] [ 240.272396] [] hid_resume_common+0xba/0x110 [usbhid] [ 240.272404] [] ? usb_runtime_suspend+0x80/0x80 [ 240.272417] [] hid_resume+0x3d/0x70 [usbhid] [ 240.272425] [] usb_resume_interface.isra.6+0xb6/0x120 [ 240.272432] [] usb_resume_both+0x74/0x140 [ 240.272439] [] usb_runtime_resume+0x1a/0x20 [ 240.272446] [] __rpm_callback+0x32/0x70 [ 240.272453] [] rpm_callback+0x26/0xa0 [ 240.272460] [] rpm_resume+0x4b1/0x690 [ 240.272468] [] ? radix_tree_lookup_slot+0x22/0x50 [ 240.272475] [] rpm_resume+0x35a/0x690 [ 240.272482] [] ? zone_statistics+0x89/0xa0 [ 240.272489] [] __pm_runtime_resume+0x40/0x60 [ 240.272497] [] usb_autopm_get_interface+0x22/0x60 [ 240.272509] [] usbhid_open+0x59/0xe0 [usbhid] [ 240.272517] [] wacom_open+0x35/0x50 [wacom] [ 240.272525] [] input_open_device+0x79/0xa0 [ 240.272534] [] evdev_open+0x1b1/0x200 [evdev] [ 240.272543] [] chrdev_open+0xae/0x1f0 [ 240.272549] [] ? cdev_put+0x30/0x30 [ 240.272556] [] do_dentry_open+0x1d2/0x320 [ 240.272562] [] finish_open+0x31/0x50 [ 240.272571] [] do_last.isra.36+0x652/0xe50 [ 240.272579] [] path_openat+0xc7/0x6f0 [ 240.272586] [] ? final_putname+0x22/0x50 [ 240.272594] [] ? user_path_at_empty+0x72/0xd0 [ 240.272602] [] do_filp_open+0x4d/0xc0 [...] So here, wacom_open is called, and then wacom_resume is called by the PM system. However, wacom_open already took the lock when wacom_resume tries to get it. Freeze. A little bit of history shows that this already happened in the past - commit f6cd378372bf ("Input: wacom - fix runtime PM related deadlock"), and the solution was to call first the PM function before taking the lock. The lock was introduced in commit commit e722409445fb ("Input: wacom - implement suspend and autosuspend") when the autosuspend feature has been added. Given that usbhid already takes care of this very same locking between suspend/resume, I think we can simply kill the lock in open/close. The lock is now used also with LEDs, so we can not remove it completely. Reported-by: Hans Spath Tested-by: Hans Spath CC: stable@vger.kernel.org # v3.17+ Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina --- drivers/hid/wacom_sys.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index 8593047bb726..b6bcd251c4a8 100644 --- a/drivers/hid/wacom_sys.c +++ b/drivers/hid/wacom_sys.c @@ -70,22 +70,15 @@ static int wacom_raw_event(struct hid_device *hdev, struct hid_report *report, static int wacom_open(struct input_dev *dev) { struct wacom *wacom = input_get_drvdata(dev); - int retval; - - mutex_lock(&wacom->lock); - retval = hid_hw_open(wacom->hdev); - mutex_unlock(&wacom->lock); - return retval; + return hid_hw_open(wacom->hdev); } static void wacom_close(struct input_dev *dev) { struct wacom *wacom = input_get_drvdata(dev); - mutex_lock(&wacom->lock); hid_hw_close(wacom->hdev); - mutex_unlock(&wacom->lock); } /* -- 2.20.1