Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 (7a9b1492) · Commits · 戴 / test

Documentation/ABI/obsolete/sysfs-bus-usb

0 → 100644

+31 −0

Original line number	Diff line number	Diff line
		What: /sys/bus/usb/devices/.../power/level
		Date: March 2007
		KernelVersion: 2.6.21
		Contact: Alan Stern <stern@rowland.harvard.edu>
		Description:
		Each USB device directory will contain a file named
		power/level. This file holds a power-level setting for
		the device, either "on" or "auto".

		"on" means that the device is not allowed to autosuspend,
		although normal suspends for system sleep will still
		be honored. "auto" means the device will autosuspend
		and autoresume in the usual manner, according to the
		capabilities of its driver.

		During normal use, devices should be left in the "auto"
		level. The "on" level is meant for administrative uses.
		If you want to suspend a device immediately but leave it
		free to wake up in response to I/O requests, you should
		write "0" to power/autosuspend.

		Device not capable of proper suspend and resume should be
		left in the "on" level. Although the USB spec requires
		devices to support suspend/resume, many of them do not.
		In fact so many don't that by default, the USB core
		initializes all non-hub devices in the "on" level. Some
		drivers may change this setting when they are bound.

		This file is deprecated and will be removed after 2010.
		Use the power/control file instead; it does exactly the
		same thing.

Documentation/ABI/testing/sysfs-bus-usb

+0 −28

Original line number	Diff line number	Diff line
		@@ -14,34 +14,6 @@ Description:
		The autosuspend delay for newly-created devices is set to
		the value of the usbcore.autosuspend module parameter.

		What: /sys/bus/usb/devices/.../power/level
		Date: March 2007
		KernelVersion: 2.6.21
		Contact: Alan Stern <stern@rowland.harvard.edu>
		Description:
		Each USB device directory will contain a file named
		power/level. This file holds a power-level setting for
		the device, either "on" or "auto".

		"on" means that the device is not allowed to autosuspend,
		although normal suspends for system sleep will still
		be honored. "auto" means the device will autosuspend
		and autoresume in the usual manner, according to the
		capabilities of its driver.

		During normal use, devices should be left in the "auto"
		level. The "on" level is meant for administrative uses.
		If you want to suspend a device immediately but leave it
		free to wake up in response to I/O requests, you should
		write "0" to power/autosuspend.

		Device not capable of proper suspend and resume should be
		left in the "on" level. Although the USB spec requires
		devices to support suspend/resume, many of them do not.
		In fact so many don't that by default, the USB core
		initializes all non-hub devices in the "on" level. Some
		drivers may change this setting when they are bound.

		What: /sys/bus/usb/devices/.../power/persist
		Date: May 2007
		KernelVersion: 2.6.23

Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget

0 → 100644

+9 −0

Original line number	Diff line number	Diff line
		What: /sys/devices/platform/_UDC_/gadget/suspended
		Date: April 2010
		Contact: Fabien Chouteau <fabien.chouteau@barco.com>
		Description:
		Show the suspend state of an USB composite gadget.
		1 -> suspended
		0 -> resumed

		(_UDC_ is the name of the USB Device Controller driver)

Documentation/DocBook/writing_usb_driver.tmpl

+1 −1

Original line number	Diff line number	Diff line
		@@ -342,7 +342,7 @@ static inline void skel_delete (struct usb_skel *dev)
		{
		kfree (dev->bulk_in_buffer);
		if (dev->bulk_out_buffer != NULL)
		usb_buffer_free (dev->udev, dev->bulk_out_size,
		usb_free_coherent (dev->udev, dev->bulk_out_size,
		dev->bulk_out_buffer,
		dev->write_urb->transfer_dma);
		usb_free_urb (dev->write_urb);

Documentation/usb/bulk-streams.txt

0 → 100644

+78 −0

Original line number	Diff line number	Diff line
		Background
		==========

		Bulk endpoint streams were added in the USB 3.0 specification. Streams allow a
		device driver to overload a bulk endpoint so that multiple transfers can be
		queued at once.

		Streams are defined in sections 4.4.6.4 and 8.12.1.4 of the Universal Serial Bus
		3.0 specification at http://www.usb.org/developers/docs/ The USB Attached SCSI
		Protocol, which uses streams to queue multiple SCSI commands, can be found on
		the T10 website (http://t10.org/).


		Device-side implications
		========================

		Once a buffer has been queued to a stream ring, the device is notified (through
		an out-of-band mechanism on another endpoint) that data is ready for that stream
		ID. The device then tells the host which "stream" it wants to start. The host
		can also initiate a transfer on a stream without the device asking, but the
		device can refuse that transfer. Devices can switch between streams at any
		time.


		Driver implications
		===================

		int usb_alloc_streams(struct usb_interface *interface,
		struct usb_host_endpoint **eps, unsigned int num_eps,
		unsigned int num_streams, gfp_t mem_flags);

		Device drivers will call this API to request that the host controller driver
		allocate memory so the driver can use up to num_streams stream IDs. They must
		pass an array of usb_host_endpoints that need to be setup with similar stream
		IDs. This is to ensure that a UASP driver will be able to use the same stream
		ID for the bulk IN and OUT endpoints used in a Bi-directional command sequence.

		The return value is an error condition (if one of the endpoints doesn't support
		streams, or the xHCI driver ran out of memory), or the number of streams the
		host controller allocated for this endpoint. The xHCI host controller hardware
		declares how many stream IDs it can support, and each bulk endpoint on a
		SuperSpeed device will say how many stream IDs it can handle. Therefore,
		drivers should be able to deal with being allocated less stream IDs than they
		requested.

		Do NOT call this function if you have URBs enqueued for any of the endpoints
		passed in as arguments. Do not call this function to request less than two
		streams.

		Drivers will only be allowed to call this API once for the same endpoint
		without calling usb_free_streams(). This is a simplification for the xHCI host
		controller driver, and may change in the future.


		Picking new Stream IDs to use
		============================

		Stream ID 0 is reserved, and should not be used to communicate with devices. If
		usb_alloc_streams() returns with a value of N, you may use streams 1 though N.
		To queue an URB for a specific stream, set the urb->stream_id value. If the
		endpoint does not support streams, an error will be returned.

		Note that new API to choose the next stream ID will have to be added if the xHCI
		driver supports secondary stream IDs.


		Clean up
		========

		If a driver wishes to stop using streams to communicate with the device, it
		should call

		void usb_free_streams(struct usb_interface *interface,
		struct usb_host_endpoint **eps, unsigned int num_eps,
		gfp_t mem_flags);

		All stream IDs will be deallocated when the driver releases the interface, to
		ensure that drivers that don't support streams will be able to use the endpoint.

Admin message