usb_autopm_get_interface_async(9) [centos man page]

USB_AUTOPM_GET_INTER(9) 					   USB Core APIs					   USB_AUTOPM_GET_INTER(9)

NAME

       usb_autopm_get_interface_async - increment a USB interface's PM-usage counter

SYNOPSIS

       int usb_autopm_get_interface_async(struct usb_interface * intf);

ARGUMENTS

       intf
	   the usb_interface whose counter should be incremented

DESCRIPTION

       This routine does much the same thing as usb_autopm_get_interface: It increments intf's usage counter and queues an autoresume request if
       the device is suspended. The differences are that it does not perform any synchronization (callers should hold a private lock and handle
       all synchronization issues themselves), and it does not autoresume the device directly (it only queues a request). After a successful call,
       the device may not yet be resumed.

       This routine can run in atomic context.

RETURN

       0 on success. A negative error code otherwise.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   USB_AUTOPM_GET_INTER(9)

USB_QUEUE_RESET_DEVI(9) 					   USB Core APIs					   USB_QUEUE_RESET_DEVI(9)

NAME

       usb_queue_reset_device - Reset a USB device from an atomic context

SYNOPSIS

       void usb_queue_reset_device(struct usb_interface * iface);

ARGUMENTS

       iface
	   USB interface belonging to the device to reset

DESCRIPTION

       This function can be used to reset a USB device from an atomic context, where usb_reset_device won't work (as it blocks).

       Doing a reset via this method is functionally equivalent to calling usb_reset_device, 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.

CORNER CASES

       - 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 ->pre_reset, the second reset might happen or not.

       - If a driver is unbound and it had a pending reset, the reset will be cancelled.

       - This function can be called during .probe or .disconnect times. On return from .disconnect, any pending resets will be cancelled.

       There is no no need to lock/unlock the reset_ws as schedule_work does its own.

NOTE

       We don't do any reference count tracking because it is not needed. The lifecycle of the work_struct is tied to the usb_interface. Before
       destroying the interface we cancel the work_struct, so the fact that work_struct is queued and or running means the interface (and thus,
       the device) exist and are referenced.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   USB_QUEUE_RESET_DEVI(9)