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

		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.

What:		/sys/bus/usb/devices/.../power/persist

Date:		May 2007

KernelVersion:	2.6.23

Contact:	Alan Stern <stern@rowland.harvard.edu>

Description:

		If CONFIG_USB_PERSIST is set, then each USB device directory

		will contain a file named power/persist.  The file holds a

		boolean value (0 or 1) indicating whether or not the

		"USB-Persist" facility is enabled for the device.  Since the

		facility is inherently dangerous, it is disabled by default

		for all devices except hubs.  For more information, see

		Documentation/usb/persist.txt.

Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays)

before suspending; then remount them after resuming.

There is a work-around for this problem.  For more information, see

Documentation/usb/persist.txt.

Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were

compiled with the similar configuration files. Anyway I found that

suspend to disk (and resume) is much slower on 2.6.16 compared to

It's good to avoid making CPUs copy data needlessly.  The costs can add up,

and effects like cache-trashing can impose subtle penalties.

- When you're allocating a buffer for DMA purposes anyway, use the buffer

  primitives.  Think of them as kmalloc and kfree that give you the right

  kind of addresses to store in urb->transfer_buffer and urb->transfer_dma,

  while guaranteeing that no hidden copies through DMA "bounce" buffers will

  slow things down.  You'd also set URB_NO_TRANSFER_DMA_MAP in

  urb->transfer_flags:

- If you're doing lots of small data transfers from the same buffer all

  the time, that can really burn up resources on systems which use an

  IOMMU to manage the DMA mappings.  It can cost MUCH more to set up and

  tear down the IOMMU mappings with each request than perform the I/O!

  For those specific cases, USB has primitives to allocate less expensive

  memory.  They work like kmalloc and kfree versions that give you the right

  kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.

  You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags:

	void *usb_buffer_alloc (struct usb_device *dev, size_t size,

		int mem_flags, dma_addr_t *dma);

	void usb_buffer_free (struct usb_device *dev, size_t size,

		void *addr, dma_addr_t dma);

  Most drivers should *NOT* be using these primitives; they don't need

  to use this type of memory ("dma-coherent"), and memory returned from

  kmalloc() will work just fine.

  For control transfers you can use the buffer primitives or not for each

  of the transfer buffer and setup buffer independently.  Set the flag bits

  URB_NO_TRANSFER_DMA_MAP and URB_NO_SETUP_DMA_MAP to indicate which

  The memory buffer returned is "dma-coherent"; sometimes you might need to

  force a consistent memory access ordering by using memory barriers.  It's

  not using a streaming DMA mapping, so it's good for small transfers on

  systems where the I/O would otherwise tie up an IOMMU mapping.  (See

  systems where the I/O would otherwise thrash an IOMMU mapping.  (See

  Documentation/DMA-mapping.txt for definitions of "coherent" and "streaming"

  DMA mappings.)

  Asking for 1/Nth of a page (as well as asking for N pages) is reasonably

  space-efficient.

  On most systems the memory returned will be uncached, because the

  semantics of dma-coherent memory require either bypassing CPU caches

  or using cache hardware with bus-snooping support.  While x86 hardware

  has such bus-snooping, many other systems use software to flush cache

  lines to prevent DMA conflicts.

- Devices on some EHCI controllers could handle DMA to/from high memory.

  Driver probe() routines can notice this using a generic DMA call, then

  tell higher level code (network, scsi, etc) about it like this:

	if (dma_supported (&intf->dev, 0xffffffffffffffffULL))

		net->features |= NETIF_F_HIGHDMA;

  Unfortunately, the current Linux DMA infrastructure doesn't have a sane

  way to expose these capabilities ... and in any case, HIGHMEM is mostly a

  design wart specific to x86_32.  So your best bet is to ensure you never

  pass a highmem buffer into a USB driver.  That's easy; it's the default

  behavior.  Just don't override it; e.g. with NETIF_F_HIGHDMA.

  That can eliminate dma bounce buffering of requests that originate (or

  terminate) in high memory, in cases where the buffers aren't allocated

  with usb_buffer_alloc() but instead are dma-mapped.

  This may force your callers to do some bounce buffering, copying from

  high memory to "normal" DMA memory.  If you can come up with a good way

  to fix this issue (for x86_32 machines with over 1 GByte of memory),

  feel free to submit patches.

WORKING WITH EXISTING BUFFERS

Existing buffers aren't usable for DMA without first being mapped into the

DMA address space of the device.

DMA address space of the device.  However, most buffers passed to your

driver can safely be used with such DMA mapping.  (See the first section

of DMA-mapping.txt, titled "What memory is DMA-able?")

- When you're using scatterlists, you can map everything at once.  On some

  systems, this kicks in an IOMMU and turns the scatterlists into single

  The calls manage urb->transfer_dma for you, and set URB_NO_TRANSFER_DMA_MAP

  so that usbcore won't map or unmap the buffer.  The same goes for

  urb->setup_dma and URB_NO_SETUP_DMA_MAP for control requests.

Note that several of those interfaces are currently commented out, since

they don't have current users.  See the source code.  Other than the dmasync

calls (where the underlying DMA primitives have changed), most of them can

easily be commented back in if you want to use them.

		USB device persistence during system suspend

		   Alan Stern <stern@rowland.harvard.edu>

		 September 2, 2006 (Updated May 29, 2007)

	What is the problem?

According to the USB specification, when a USB bus is suspended the

bus must continue to supply suspend current (around 1-5 mA).  This

is so that devices can maintain their internal state and hubs can

detect connect-change events (devices being plugged in or unplugged).

The technical term is "power session".

If a USB device's power session is interrupted then the system is

required to behave as though the device has been unplugged.  It's a

conservative approach; in the absence of suspend current the computer

has no way to know what has actually happened.  Perhaps the same

device is still attached or perhaps it was removed and a different

device plugged into the port.  The system must assume the worst.

By default, Linux behaves according to the spec.  If a USB host

controller loses power during a system suspend, then when the system

wakes up all the devices attached to that controller are treated as

though they had disconnected.  This is always safe and it is the

"officially correct" thing to do.

For many sorts of devices this behavior doesn't matter in the least.

If the kernel wants to believe that your USB keyboard was unplugged

while the system was asleep and a new keyboard was plugged in when the

system woke up, who cares?  It'll still work the same when you type on

it.

Unfortunately problems _can_ arise, particularly with mass-storage

devices.  The effect is exactly the same as if the device really had

been unplugged while the system was suspended.  If you had a mounted

filesystem on the device, you're out of luck -- everything in that

filesystem is now inaccessible.  This is especially annoying if your

root filesystem was located on the device, since your system will

instantly crash.

Loss of power isn't the only mechanism to worry about.  Anything that

interrupts a power session will have the same effect.  For example,

even though suspend current may have been maintained while the system

was asleep, on many systems during the initial stages of wakeup the

firmware (i.e., the BIOS) resets the motherboard's USB host

controllers.  Result: all the power sessions are destroyed and again

it's as though you had unplugged all the USB devices.  Yes, it's

entirely the BIOS's fault, but that doesn't do _you_ any good unless

you can convince the BIOS supplier to fix the problem (lots of luck!).

On many systems the USB host controllers will get reset after a

suspend-to-RAM.  On almost all systems, no suspend current is

available during hibernation (also known as swsusp or suspend-to-disk).

You can check the kernel log after resuming to see if either of these

has happened; look for lines saying "root hub lost power or was reset".

In practice, people are forced to unmount any filesystems on a USB

device before suspending.  If the root filesystem is on a USB device,

the system can't be suspended at all.  (All right, it _can_ be

suspended -- but it will crash as soon as it wakes up, which isn't

much better.)

	What is the solution?

Setting CONFIG_USB_PERSIST will cause the kernel to work around these

issues.  It enables a mode in which the core USB device data

structures are allowed to persist across a power-session disruption.

It works like this.  If the kernel sees that a USB host controller is

not in the expected state during resume (i.e., if the controller was

reset or otherwise had lost power) then it applies a persistence check

to each of the USB devices below that controller for which the

"persist" attribute is set.  It doesn't try to resume the device; that

can't work once the power session is gone.  Instead it issues a USB

port reset and then re-enumerates the device.  (This is exactly the

same thing that happens whenever a USB device is reset.)  If the

re-enumeration shows that the device now attached to that port has the

same descriptors as before, including the Vendor and Product IDs, then

the kernel continues to use the same device structure.  In effect, the

kernel treats the device as though it had merely been reset instead of

unplugged.

If no device is now attached to the port, or if the descriptors are

different from what the kernel remembers, then the treatment is what

you would expect.  The kernel destroys the old device structure and

behaves as though the old device had been unplugged and a new device

plugged in, just as it would without the CONFIG_USB_PERSIST option.

The end result is that the USB device remains available and usable.

Filesystem mounts and memory mappings are unaffected, and the world is

now a good and happy place.

Note that even when CONFIG_USB_PERSIST is set, the "persist" feature

will be applied only to those devices for which it is enabled.  You

can enable the feature by doing (as root):

	echo 1 >/sys/bus/usb/devices/.../power/persist

where the "..." should be filled in the with the device's ID.  Disable

the feature by writing 0 instead of 1.  For hubs the feature is

automatically and permanently enabled, so you only have to worry about

setting it for devices where it really matters.

	Is this the best solution?

Perhaps not.  Arguably, keeping track of mounted filesystems and

memory mappings across device disconnects should be handled by a

centralized Logical Volume Manager.  Such a solution would allow you

to plug in a USB flash device, create a persistent volume associated

with it, unplug the flash device, plug it back in later, and still

have the same persistent volume associated with the device.  As such

it would be more far-reaching than CONFIG_USB_PERSIST.

On the other hand, writing a persistent volume manager would be a big

job and using it would require significant input from the user.  This

solution is much quicker and easier -- and it exists now, a giant

point in its favor!

Furthermore, the USB_PERSIST option applies to _all_ USB devices, not

just mass-storage devices.  It might turn out to be equally useful for

other device types, such as network interfaces.

	WARNING: Using CONFIG_USB_PERSIST can be dangerous!!

When recovering an interrupted power session the kernel does its best

to make sure the USB device hasn't been changed; that is, the same

device is still plugged into the port as before.  But the checks

aren't guaranteed to be 100% accurate.

If you replace one USB device with another of the same type (same

manufacturer, same IDs, and so on) there's an excellent chance the

kernel won't detect the change.  Serial numbers and other strings are

not compared.  In many cases it wouldn't help if they were, because

manufacturers frequently omit serial numbers entirely in their

devices.

Furthermore it's quite possible to leave a USB device exactly the same

while changing its media.  If you replace the flash memory card in a

USB card reader while the system is asleep, the kernel will have no

way to know you did it.  The kernel will assume that nothing has

happened and will continue to use the partition tables, inodes, and

memory mappings for the old card.

If the kernel gets fooled in this way, it's almost certain to cause

data corruption and to crash your system.  You'll have no one to blame

but yourself.

YOU HAVE BEEN WARNED!  USE AT YOUR OWN RISK!

That having been said, most of the time there shouldn't be any trouble

at all.  The "persist" feature can be extremely useful.  Make the most

of it.

W:	http://pegasus2.sourceforge.net/

S:	Maintained

USB PRINTER DRIVER

P:	Vojtech Pavlik

M:	vojtech@suse.cz

USB PRINTER DRIVER (usblp)

P:	Pete Zaitcev

M:	zaitcev@redhat.com

L:	linux-usb-users@lists.sourceforge.net

L:	linux-usb-devel@lists.sourceforge.net

S:	Maintained

S:	Supported

USB RTL8150 DRIVER

P:	Petko Manolov