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

		Write a 1 to force the device to disconnect

		(equivalent to unplugging a wired USB device).

What:		/sys/bus/usb/drivers/.../remove_id

Date:		November 2009

Contact:	CHENG Renquan <rqcheng@smu.edu.sg>

Description:

		Writing a device ID to this file will remove an ID

		that was dynamically added via the new_id sysfs entry.

		The format for the device ID is:

		idVendor idProduct.	After successfully

		removing an ID, the driver will no longer support the

		device.  This is useful to ensure auto probing won't

		match the driver to the device.  For example:

		# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id

                Since this relates to security (specifically, the

                lifetime of PTKs and GTKs) it should not be changed

                from the default.

What:           /sys/class/uwb_rc/uwbN/wusbhc/wusb_phy_rate

Date:           August 2009

KernelVersion:  2.6.32

Contact:        David Vrabel <david.vrabel@csr.com>

Description:

                The maximum PHY rate to use for all connected devices.

                This is only of limited use for testing and

                development as the hardware's automatic rate

                adaptation is better then this simple control.

                Refer to [ECMA-368] section 10.3.1.1 for the value to

                use.

			to a common usb-storage quirk flag as follows:

				a = SANE_SENSE (collect more than 18 bytes

					of sense data);

				b = BAD_SENSE (don't collect more than 18

					bytes of sense data);

				c = FIX_CAPACITY (decrease the reported

					device capacity by one sector);

				h = CAPACITY_HEURISTICS (decrease the

       - reg-offset : A value of 3 is required

       - reg-shift : A value of 2 is required

      vii) Xilinx USB Host controller

      The Xilinx USB host controller is EHCI compatible but with a different

      base address for the EHCI registers, and it is always a big-endian

      USB Host controller. The hardware can be configured as high speed only,

      or high speed/full speed hybrid.

      Required properties:

      - xlnx,support-usb-fs: A value 0 means the core is built as high speed

                             only. A value 1 means the core also supports

                             full speed devices.

		 Alan Stern <stern@rowland.harvard.edu>

			    October 5, 2007

			    November 10, 2009

	power/level

		This file contains one of three words: "on", "auto",

		or "suspend".  You can write those words to the file

		to change the device's setting.

		This file contains one of two words: "on" or "auto".

		You can write those words to the file to change the

		device's setting.

		"on" means that the device should be resumed and

		autosuspend is not allowed.  (Of course, system

		"auto" is the normal state in which the kernel is

		allowed to autosuspend and autoresume the device.

		"suspend" means that the device should remain

		suspended, and autoresume is not allowed.  (But remote

		wakeup may still be allowed, since it is controlled

		separately by the power/wakeup attribute.)

		(In kernels up to 2.6.32, you could also specify

		"suspend", meaning that the device should remain

		suspended and autoresume was not allowed.  This

		setting is no longer supported.)

	power/autosuspend

that it supports autosuspend by setting the .supports_autosuspend flag

in its usb_driver structure.  It is then responsible for informing the

USB core whenever one of its interfaces becomes busy or idle.  The

driver does so by calling these five functions:

driver does so by calling these six functions:

	int  usb_autopm_get_interface(struct usb_interface *intf);

	void usb_autopm_put_interface(struct usb_interface *intf);

	int  usb_autopm_set_interface(struct usb_interface *intf);

	int  usb_autopm_get_interface_async(struct usb_interface *intf);

	void usb_autopm_put_interface_async(struct usb_interface *intf);

	void usb_autopm_get_interface_no_resume(struct usb_interface *intf);

	void usb_autopm_put_interface_no_suspend(struct usb_interface *intf);

The functions work by maintaining a counter in the usb_interface

structure.  When intf->pm_usage_count is > 0 then the interface is

associated with the device itself rather than any of its interfaces.

This field is used only by the USB core.)

The driver owns intf->pm_usage_count; it can modify the value however

and whenever it likes.  A nice aspect of the non-async usb_autopm_*

routines is that the changes they make are protected by the usb_device

structure's PM mutex (udev->pm_mutex); however drivers may change

pm_usage_count without holding the mutex.  Drivers using the async

Drivers must not modify intf->pm_usage_count directly; its value

should be changed only be using the functions listed above.  Drivers

are responsible for insuring that the overall change to pm_usage_count

during their lifetime balances out to 0 (it may be necessary for the

disconnect method to call usb_autopm_put_interface() one or more times

to fulfill this requirement).  The first two routines use the PM mutex

in struct usb_device for mutual exclusion; drivers using the async

routines are responsible for their own synchronization and mutual

exclusion.

	attempts an autosuspend if the new value is <= 0 and the

	device isn't suspended.

	usb_autopm_set_interface() leaves pm_usage_count alone.

	It attempts an autoresume if the value is > 0 and the device

	is suspended, and it attempts an autosuspend if the value is

	<= 0 and the device isn't suspended.

	usb_autopm_get_interface_async() and

	usb_autopm_put_interface_async() do almost the same things as

	their non-async counterparts.  The differences are: they do

	such as an URB's completion handler, but when they return the

	device will not generally not yet be in the desired state.

There also are a couple of utility routines drivers can use:

	usb_autopm_enable() sets pm_usage_cnt to 0 and then calls

	usb_autopm_set_interface(), which will attempt an autosuspend.

	usb_autopm_disable() sets pm_usage_cnt to 1 and then calls

	usb_autopm_set_interface(), which will attempt an autoresume.

	usb_autopm_get_interface_no_resume() and

	usb_autopm_put_interface_no_suspend() merely increment or

	decrement the pm_usage_count value; they do not attempt to

	carry out an autoresume or an autosuspend.  Hence they can be

	called in an atomic context.

The conventional usage pattern is that a driver calls

usb_autopm_get_interface() in its open routine and

Normally a driver would set this flag in its probe method, at which

time the device is guaranteed not to be autosuspended.)

The usb_autopm_* routines have to run in a sleepable process context;

they must not be called from an interrupt handler or while holding a

spinlock.  In fact, the entire autosuspend mechanism is not well geared

toward interrupt-driven operation.  However there is one thing a

driver can do in an interrupt handler:

The synchronous usb_autopm_* routines have to run in a sleepable

process context; they must not be called from an interrupt handler or

while holding a spinlock.  In fact, the entire autosuspend mechanism

is not well geared toward interrupt-driven operation.  However there

is one thing a driver can do in an interrupt handler:

	usb_mark_last_busy(struct usb_device *udev);

External suspend calls should never be allowed to fail in this way,

only autosuspend calls.  The driver can tell them apart by checking

udev->auto_pm; this flag will be set to 1 for internal PM events

(autosuspend or autoresume) and 0 for external PM events.

the PM_EVENT_AUTO bit in the message.event argument to the suspend

method; this bit will be set for internal PM events (autosuspend) and

clear for external PM events.

Many of the ingredients in the autosuspend framework are oriented

towards interfaces: The usb_interface structure contains the

pm_usage_cnt field, and the usb_autopm_* routines take an interface

pointer as their argument.  But somewhat confusingly, a few of the

pieces (usb_mark_last_busy() and udev->auto_pm) use the usb_device

structure instead.  Drivers need to keep this straight; they can call

pieces (i.e., usb_mark_last_busy()) use the usb_device structure

instead.  Drivers need to keep this straight; they can call

interface_to_usbdev() to find the device structure for a given

interface.