Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 7a9b1492 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (229 commits)
  USB: remove unused usb_buffer_alloc and usb_buffer_free macros
  usb: musb: update gfp/slab.h includes
  USB: ftdi_sio: fix legacy SIO-device header
  USB: kl5usb105: reimplement using generic framework
  USB: kl5usb105: minor clean ups
  USB: kl5usb105: fix memory leak
  USB: io_ti: use kfifo to implement write buffering
  USB: io_ti: remove unsused private counter
  USB: ti_usb: use kfifo to implement write buffering
  USB: ir-usb: fix incorrect write-buffer length
  USB: aircable: fix incorrect write-buffer length
  USB: safe_serial: straighten out read processing
  USB: safe_serial: reimplement read using generic framework
  USB: safe_serial: reimplement write using generic framework
  usb-storage: always print quirks
  USB: usb-storage: trivial debug improvements
  USB: oti6858: use port write fifo
  USB: oti6858: use kfifo to implement write buffering
  USB: cypress_m8: use kfifo to implement write buffering
  USB: cypress_m8: remove unused drain define
  ...

Fix up conflicts (due to usb_buffer_alloc/free renaming) in
	drivers/input/tablet/acecad.c
	drivers/input/tablet/kbtab.c
	drivers/input/tablet/wacom_sys.c
	drivers/media/video/gspca/gspca.c
	sound/usb/usbaudio.c
parents 3d62e3fd e26bcf37

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.