'\" t
.\"     Title: usb_queue_reset_device
.\"    Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
.\"      Date: January 2017
.\"    Manual: USB Core APIs
.\"    Source: Kernel Hackers Manual 4.8.15
.\"  Language: English
.\"
.TH "USB_QUEUE_RESET_DEVI" "9" "January 2017" "Kernel Hackers Manual 4\&.8\&." "USB Core APIs"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
usb_queue_reset_device \- Reset a USB device from an atomic context
.SH "SYNOPSIS"
.HP \w'void\ usb_queue_reset_device('u
.BI "void usb_queue_reset_device(struct\ usb_interface\ *\ " "iface" ");"
.SH "ARGUMENTS"
.PP
\fIiface\fR
.RS 4
USB interface belonging to the device to reset
.RE
.SH "DESCRIPTION"
.PP
This function can be used to reset a USB device from an atomic context, where
\fBusb_reset_device\fR
won\*(Aqt work (as it blocks)\&.
.PP
Doing a reset via this method is functionally equivalent to calling
\fBusb_reset_device\fR, except for the fact that it is delayed to a workqueue\&. This means that any drivers bound to other interfaces might be unbound, as well as users from usbfs in user space\&.
.PP
Corner cases:
.PP
\- Scheduling two resets at the same time from two different drivers attached to two different interfaces of the same device is possible; depending on how the driver attached to each interface handles \->\fBpre_reset\fR, the second reset might happen or not\&.
.PP
\- If the reset is delayed so long that the interface is unbound from its driver, the reset will be skipped\&.
.PP
\- This function can be called during \&.\fBprobe\fR\&. It can also be called during \&.\fBdisconnect\fR, but doing so is pointless because the reset will not occur\&. If you really want to reset the device during \&.\fBdisconnect\fR, call
\fBusb_reset_device\fR
directly \-\- but watch out for nested unbinding issues!
.SH "COPYRIGHT"
.br