Question regarding error handling in usbhid

Question regarding error handling in usbhid

[Oliver Neukum]

Hi,

hid_io_error(), in case it decides that a reset is necessary,
schedules reset_work(). reset_work() in turn calls usb_queue_reset_device().
Why? Is there a reason usb_queue_reset_device() is not used directly
in hid_io_error()?

	Regards
		Oliver

Re: Question regarding error handling in usbhid

[Alan Stern]

On Tue, Mar 24, 2026 at 10:57:16AM +0100, Oliver Neukum wrote:
> Hi,
> 
> hid_io_error(), in case it decides that a reset is necessary,
> schedules reset_work(). reset_work() in turn calls usb_queue_reset_device().
> Why? Is there a reason usb_queue_reset_device() is not used directly
> in hid_io_error()?

This is partly explained in the changelog for commit 8f507ef522d5 ("HID: 
usbhid: improve handling of Clear-Halt and reset"):

    The way resets are carried out is also changed.  Now the driver will
    call usb_queue_reset_device() instead of calling usb_reset_device()
    directly.  This avoids a deadlock that would arise when a device is
    unplugged: The hid_reset() routine runs as a workqueue item, a reset
    attempt after the device has been unplugged will fail, failure will
    cause usbhid to be unbound, and the disconnect routine will try to do
    cancel_work_sync().  The usb_queue_reset_device() implementation is
    carefully written to handle scenarios like this one properly.

The other part of the explanation is that the reset code was added to 
hid_io_error() before usb_queue_reset_device() existed (2006 vs 2008).

Alan Stern