The USB 3.0 bus specification added an "Endpoint Companion" descriptor that is
supposed to follow all SuperSpeed Endpoint descriptors.  This descriptor is used
to extend the bus protocol to allow more packets to be sent to an endpoint per
"microframe".  The word microframe was removed from the USB 3.0 specification
because the host controller does not send Start Of Frame (SOF) symbols down the
USB 3.0 wires.

The descriptor defines a bMaxBurst field, which indicates the number of packets
of wMaxPacketSize that a SuperSpeed device can send or recieve in a service
interval.  All non-control endpoints may set this value as high as 16 packets
(bMaxBurst = 15).

The descriptor also allows isochronous endpoints to further specify that they
can send and receive multiple bursts per service interval.  The bmAttributes
allows them to specify a "Mult" of up to 3 (bmAttributes = 2).

Bulk endpoints use bmAttributes to report the number of "Streams" they support.
This was an extension of the endpoint pipe concept to allow multiple mass
storage device commands to be outstanding for one bulk endpoint at a time.  This
should allow USB 3.0 mass storage devices to support SCSI command queueing.
Bulk endpoints can say they support up to 2^16 (65,536) streams.

The information in the endpoint companion descriptor must be stored with the
other device, config, interface, and endpoint descriptors because the host
controller needs to access them quickly, and we need to install some default
values if a SuperSpeed device doesn't provide an endpoint companion descriptor.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Allow device drivers to enqueue URBs to control endpoints on devices under
an xHCI host controller.  Each control transfer is represented by a
series of Transfer Descriptors (TDs) written to an endpoint ring.  There
is one TD for the Setup phase, (optionally) one TD for the Data phase, and
one TD for the Status phase.

Enqueue these TDs onto the endpoint ring that represents the control
endpoint.  The host controller hardware will return an event on the event
ring that points to the (DMA) address of one of the TDs on the endpoint
ring.  If the transfer was successful, the transfer event TRB will have a
completion code of success, and it will point to the Status phase TD.
Anything else is considered an error.

This should work for control endpoints besides the default endpoint, but
that hasn't been tested.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Warn users of URB_NO_SETUP_DMA_MAP about xHCI behavior.

Device drivers can choose to DMA map the setup packet of a control transfer
before submitting the URB to the USB core.  Drivers then set the
URB_NO_SETUP_DMA_MAP and pass in the DMA memory address in setup_dma, instead of
providing a kernel address for setup_packet.  However, xHCI requires that the
setup packet be copied into an internal data structure, and we need a kernel
memory address pointer for that.  Warn users of URB_NO_SETUP_DMA_MAP that they
should provide a valid pointer for setup_packet, along with the DMA address.

FIXME:  I'm not entirely sure how to work around this in the xHCI driver
or USB core.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xHCI needs to get a "Slot ID" from the host controller and allocate other
data structures for every USB device.  Make usb_alloc_dev() and
usb_release_dev() allocate and free these device structures.  After
setting up the xHC device structures, usb_alloc_dev() must wait for the
hardware to respond to an Enable Slot command.  usb_alloc_dev() fires off
a Disable Slot command and does not wait for it to complete.

When the USB core wants to choose an address for the device, the xHCI
driver must issue a Set Address command and wait for an event for that
command.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add host controller driver API and a slot_id variable to struct
usb_device.  This allows the xHCI host controller driver to ask the
hardware to allocate a slot for the device when a struct usb_device is
allocated.  The slot needs to be allocated at that point because the
hardware can run out of internal resources, and we want to know that very
early in the device connection process.  Don't call this new API for root
hubs, since they aren't real devices.

Add HCD API to let the host controller choose the device address.  This is
especially important for xHCI hardware running in a virtualized
environment.  The guests running under the VM don't need to know which
addresses on the bus are taken, because the hardware picks the address for
them.  Announce SuperSpeed USB devices after the address has been assigned
by the hardware.

Don't use the new get descriptor/set address scheme with xHCI.  Unless
special handling is done in the host controller driver, the xHC can't
issue control transfers before you set the device address.  Support for
the older addressing scheme will be added when the xHCI driver supports
the Block Set Address Request (BSR) flag in the Address Device command.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add functionality for getting port status and hub descriptor for xHCI root
hubs.  This is WIP because the USB 3.0 hub descriptor is different from
the USB 2.0 hub descriptor.  For now, we lie about the root hub descriptor
because the changes won't effect how the core talks to the root hub.
Later we will need to add the USB 3.0 hub descriptor for real hubs, and
this code might change.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds a hex route string to each USB device.  The route string is used
by the USB 3.0 host controller to send packets through the device tree.  USB 3.0
hubs use this string to route packets to the correct port.  This is fundamental
bus change from USB 2.0, where all packets were broadcast across the bus.

Devices (including hubs) under a root port receive the route string 0x0.  Every
four bits in the route string represent a port on a hub.  This length works
because USB 3.0 hubs are limited to 15 ports, and USB 2.0 hubs (with potentially
more ports) will never see packets with a route string.  A port number of 0
means the packet is destined for that hub.

For example, a peripheral device might have a route string of 0x00097.
This means the device is connected to port 9 of the hub at depth 1.
The hub at depth 1 is connected to port 7 of a hub at depth 0.
The hub at depth 0 is connected to a root port.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The USB 3.0 bus specification defines a new connection sequence for USB 3.0
hubs and roothubs.  USB 3.0 devices are reset and link trained by the hub
before the port status change notification is sent to the host OS.  This means
that an entire tree of devices can be trained in parallel on power up, and the
OS no longer needs to reset USB 3.0 devices.  Change the USB core's hub port
init sequence so that it does not reset USB 3.0 devices.

The port status change from the roothub and from the USB 3.0 hub will report
the SuperSpeed connect correctly.  This patch currently only handles the
roothub case.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add USB 3.0 root hub descriptors.  This is a kludge because I reused the old
USB 2.0 descriptors, instead of using the new USB 3.0 hub descriptors with
endpoint companion descriptors and other descriptors.  I did this because I
wasn't ready to add USB 3.0 hub changes to khubd.  For now, a USB 3.0 roothub
looks like a USB 2.0 roothub, with a higher speed.

USB 3.0 hubs have no transaction translator (TT).

Make USB core debugging handle super speed ports.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Modify the USB core to handle the new USB 3.0 speed, "SuperSpeed".  This
is 5.0 Gbps (wire speed).  There are probably more places that check for
speed that I've missed.

SuperSpeed devices have a 512 byte endpoint 0 max packet size.  This shows
up as a bMaxPacketSize0 set to 0x09 (see table 9-8 of the USB 3.0 bus
spec).

xHCI spec says that the xHC can handle intervals up to 2^15 microframes.  That
might change when real silicon becomes available.

Add FIXME note for SuperSpeed isochronous endpoints.  They can transmit up
to 16 packets in one "burst" before they wait for an acknowledgment of the
packets.  They can do up to 3 bursts per microframe (determined by the
mult value in the endpoint companion descriptor).  The xHCI driver doesn't
have support for isoc yet, so fix this later.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xHCI host controllers can optionally implement a no-op test.  This
simple test ensures the OS has correctly setup all basic data structures
and can correctly respond to interrupts from the host controller
hardware.

There are two rings exercised by the no-op test:  the command ring, and
the event ring.

The host controller driver writes a no-op command TRB to the command
ring, and rings the doorbell for the command ring (the first entry in
the doorbell array).  The hardware receives this event, places a command
completion event on the event ring, and fires an interrupt.

The host controller driver sees the interrupt, and checks the event ring
for TRBs it can process, and sees the command completion event.  (See
the rules in xhci-ring.c for who "owns" a TRB.  This is a simplified set
of rules, and may not contain all the details that are in the xHCI 0.95
spec.)

A timer fires every 60 seconds to debug the state of the hardware and
command and event rings.  This timer only runs if
CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Instead of keeping a "frame list" like older host controllers, the xHCI
host controller keeps internal representations of the USB devices, with a
transfer ring per endpoint.  The host controller queues Transfer Request
Blocks (TRBs) to the endpoint ring, and then "rings the doorbell" for that
device.  The host controller processes the transfer, places a transfer
completion event on the event ring, and interrupts the system.

The device context base address array must be allocated by the xHCI host
controller driver, along with the device contexts it points to.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Allocate basic xHCI host controller data structures.  For every xHC, there
is a command ring, an event ring, and a doorbell array.

The doorbell array is used to notify the host controller that work has
been enqueued onto one of the rings.  The host controller driver enqueues
commands on the command ring.  The HW enqueues command completion events
on the event ring and interrupts the system (currently using PCI
interrupts, although the xHCI HW will use MSI interrupts eventually).

All rings and the doorbell array must be allocated by the xHCI host
controller driver.

Each ring is comprised of one or more segments, which consists of 16-byte
Transfer Request Blocks (TRBs) that can be chained to form a Transfer
Descriptor (TD) that represents a multiple-buffer request.  Segments are
linked into a ring using Link TRBs, which means they are dynamically
growable.

The producer of the ring enqueues a TD by writing one or more TRBs in the
ring and toggling the TRB cycle bit for each TRB.  The consumer knows it
can process the TRB when the cycle bit matches its internal consumer cycle
state for the ring.  The consumer cycle state is toggled an odd amount of
times in the ring.

An example ring (a ring must have a minimum of 16 TRBs on it, but that's
too big to draw in ASCII art):

              chain  cycle
               bit    bit
 ------------------------
| TD A TRB 1 |  1  |  1  |<-------------  <-- consumer dequeue ptr
 ------------------------               |     consumer cycle state = 1
| TD A TRB 2 |  1  |  1  |              |
 ------------------------               |
| TD A TRB 3 |  0  |  1  |  segment 1   |
 ------------------------               |
| TD B TRB 1 |  1  |  1  |              |
 ------------------------               |
| TD B TRB 2 |  0  |  1  |              |
 ------------------------               |
| Link TRB   |  0  |  1  |-----         |
 ------------------------     |         |
                              |         |
              chain  cycle    |         |
               bit    bit     |         |
 ------------------------     |         |
| TD C TRB 1 |  0  |  1  |<----         |
 ------------------------               |
| TD D TRB 1 |  1  |  1  |              |
 ------------------------               |
| TD D TRB 2 |  1  |  1  |   segment 2  |
 ------------------------               |
| TD D TRB 3 |  1  |  1  |              |
 ------------------------               |
| TD D TRB 4 |  1  |  1  |              |
 ------------------------               |
| Link TRB   |  1  |  1  |-----         |
 ------------------------     |         |
                              |         |
              chain  cycle    |         |
               bit    bit     |         |
 ------------------------     |         |
| TD D TRB 5 |  1  |  1  |<----         |
 ------------------------               |
| TD D TRB 6 |  0  |  1  |              |
 ------------------------               |
| TD E TRB 1 |  0  |  1  |   segment 3  |
 ------------------------               |
|            |  0  |  0  |              | <-- producer enqueue ptr
 ------------------------               |
|            |  0  |  0  |              |
 ------------------------               |
| Link TRB   |  0  |  0  |---------------
 ------------------------
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add PCI initialization code to take control of the xHCI host controller
away from the BIOS, halt, and reset the host controller.  The xHCI spec
says that BIOSes must give up the host controller within 5 seconds.

Add some host controller glue functions to handle hardware initialization
and memory allocation for the host controller.  The current xHCI
prototypes use PCI interrupts, but the xHCI spec requires MSI-X
interrupts.  Add code to support MSI-X interrupts, but use the PCI
interrupts for now.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is the first of many patches to add support for USB 3.0 devices and
the hardware that implements the eXtensible Host Controller Interface
(xHCI) 0.95 specification.  This specification is not yet publicly
available, but companies can receive a copy by becoming an xHCI
Contributor (see http://www.intel.com/technology/usb/xhcispec.htm).

No xHCI hardware has made it onto the market yet, but these patches have
been tested under the Fresco Logic host controller prototype.

This patch adds the xHCI register sets, which are grouped into five sets:
 - Generic PCI registers
 - Host controller "capabilities" registers (cap_regs) short
 - Host controller "operational" registers (op_regs)
 - Host controller "runtime" registers (run_regs)
 - Host controller "doorbell" registers

These some of these registers may be virtualized if the Linux driver is
running under a VM.  Virtualization has not been tested for this patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Steve Holland pointed out that we forgot to call break; in the switch
statment.  This probably resolves a lot of the bug reports I've gotten
for the driver lately.

Stupid me...
Reported-by: NSteve Holland <sdh4@iastate.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In tests 11 and 12 if the URB completes with an error status (eg babble)
the asynchrous unlink entered an endless loop trying to unlink
a non resubmitted URB.
Signed-off-by: NMartin Fuzzey <mfuzzey@gmail.com>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The toggle_bias() function was specified differently for avr32 and at91
architectures. Now, new at91 have the same behavior as avr32.
Consequently, we change to a particular chip function definition: only for
at91sam9rl.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently if a laptop is suspended e.g. while docked and then resumed after
undocking it, the following errors get generated because the USB hub in the
docking station and the devices connected to it are no longer available:
pm_op(): usb_dev_resume+0x0/0x10 returns -19
PM: Device 1-2 failed to resume: error -19
pm_op(): usb_dev_resume+0x0/0x10 returns -19
PM: Device 1-2.2 failed to resume: error -19
pm_op(): usb_dev_resume+0x0/0x10 returns -19
PM: Device 1-2.3 failed to resume: error -19

As the removal of USB devices while a system is suspended is a relatively
common use case and in most cases not an error, just return success on
-ENODEV. The user gets informed anyway as the USB subsystem generates
regular disconnect messages for the devices shortly afterwards:
usb 1-2: USB disconnect, address 3
usb 1-2.2: USB disconnect, address 4
usblp0: removed
usb 1-2.3: USB disconnect, address 5
Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Description:
This driver is used for Intel Langwell* USB OTG controller in Intel
Moorestown* platform. It tries to implement host/device role switch
according to OTG spec.  The actual hsot and device functions are
accomplished in modified EHCI driver and Intel Langwell USB OTG client
controller driver.

* Langwell and Moorestown are names used in development. They are not
  approved official name.

Note:
This patch is the first version Intel Langwell USB OTG Transceiver
driver. The development is not finished, and the bug fixing is on going
for some hardware and software issues. The main purpose of this
submission is for code view.

Supported features:
- Data-line Pulsing SRP
- Support HNP to switch roles
- PCI D0/D3 power management support

Known issues:
- HNP is only tested with another Moorestown platform.
- PCI D0/D3 power management support is not fully tested.
- VBus Pulsing SRP is not support in current version.
Signed-off-by: NHao Wu <hao.wu@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Intel Langwell USB Device Controller is a High-Speed USB OTG device
controller in Intel Moorestown platform. It can work in OTG device mode
with Intel Langwell USB OTG transceiver driver as well as device-only
mode. The number of programmable endpoints is different through
controller revision.

NOTE:
This patch is the first version Intel Langwell USB OTG device controller
driver. The bug fixing is on going for some hardware and software
issues.  Intel Langwell USB OTG transceiver driver and EHCI driver
patches will be submitted later.

Supported features:
 - USB OTG protocol support with Intel Langwell USB OTG transceiver
   driver (turn on CONFIG_USB_LANGWELL_OTG)
 - Support control, bulk, interrupt and isochronous endpoints
   (isochronous not tested)
 - PCI D0/D3 power management support
 - Link Power Management (LPM) support

Tested gadget drivers:
 - g_file_storage
 - g_ether
 - g_zero

The passed tests:
 - g_file_storage: USBCV Chapter 9 tests
 - g_file_storage: USBCV MSC tests
 - g_file_storage: from/to host files copying
 - g_ether: ping, ftp and scp files from/to host
 - Hotplug, with and without hubs

Known issues:
 - g_ether: failed part of USBCV chap9 tests
 - LPM support not fully tested

TODO:
 - g_ether: pass all USBCV chap9 tests
 - g_zero: pass usbtest tests
 - Stress tests on different gadget drivers
 - On-chip private SRAM caching support
Signed-off-by: NXiaochen Shen <xiaochen.shen@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1254) splits up the shutdown method of usb_serial_driver
into a disconnect and a release method.

The problem is that the usb-serial core was calling shutdown during
disconnect handling, but drivers didn't expect it to be called until
after all the open file references had been closed.  The result was an
oops when the close method tried to use memory that had been
deallocated by shutdown.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1253) prevents the usb-serial core from calling a
driver's port_probe and port_remove methods more than once per port.
It also removes some unnecessary try_module_get() calls and adds a
missing port_remove method call in a failure path.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Funtions added:
 - setup all the USB audio class device descriptors
 - handle class specific setup request
 - receive data from USB host by ISO transfer
 - play audio data by ALSA sound card
 - open and setup playback PCM interface
 - set default playback PCM parameters
 - provide playback functions for USB audio driver
 - provide PCM parameters set/get functions

Test on:
 - Host: Ubuntu 8.10, kernel 2.6.27
 - Gadget: EZKIT-BF548 with ASoC AD1980 codec

Todo:
 - add real Mute control code
 - add real Volume control code
 - maybe find another way to replace dynamic buffer handling
   with static buffer allocation
 - test on Windows system
 - provide control interface to handle mute/volume control
 - provide capture interface in the future
 - test on BF527, other USB device controler and other audio codec
Signed-off-by: NBryan Wu <cooloney@kernel.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NBryan Wu <cooloney@kernel.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Driver support for the new high-speed/OtG block that is
in the newer line of Samsung SoC devices such as the
S3C64XX series.

This driver does not currntly have DMA support enabled due
to issues with buffer alignment which need to be sorted out.
Signed-off-by: NBen Dooks <ben@simtec.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds support for i.MX3x (only tested with i.MX31 so far) ARM
SoCs to the fsl_usb2_udc driver. It also moves PHY configuration before
controller reset, because otherwise an ULPI PHY doesn't get a reset and
doesn't function after a reboot. The problem with longer control transfers
is still not fixed. The patch renames the fsl_usb2_udc.c file to
fsl_udc_core.c to preserve the same module name for user-space
backwards compatibility.
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The only time a sysrq should get processed is if the attached device
is a console.  This is intended to protect sysrq execution on a host
connected with a terminal program.

Here is the problem scenario:

host A <-- rs232 link --> host B

Host A is using mincom and a usb pl2303 device to connect to host b
which is a linux system with a usb pl2303 device acting as the serial
console.  When host B is rebooted the pl2303 emits random junk
characters on reset.  These character sequences contain serial break
signals most of the time and when translated to a sysrq have caused
host A to get random processes killed, reboots or power down.

It is true that in this setup with this patch host B might still have
the same problem as host A if you reboot host A.  In most cases host A
is a development host which seldom gets rebooted, and you could turn
off sysrq temporarily on host B if you need to reboot host A.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add callbacks to process the sysrq when using a pl2303 usb device as a
console.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes a bug in the RNDIS code.

Due to this bug gether_connect() fails as the port remains un-initialized.

As a result following USB Compliance Tests were failing.
(1)EndpointDescriptorTest_DeviceConfigured
(2)Interface Descriptor Test.
(3)Halt Endpoint Test.
(4)SetConfigurationTest

The fix aligns rndis code with the CDC ECM for xxx_set_alt().

The above listed USB Compliance test passes with this fix.

Tested working fine on SDP with OMAP 3430.
Signed-off-by: NMaulik Mankad <x0082077@ti.com>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This mobile phone fails to work as a modem, failing with:
 cdc_acm: Zero length descriptor references
 cdc_acm: probe of 1-6.1.3:1.1 failed with error -22

Tested to work fine with this patch.
Signed-off-by: NKir Kolyshkin <kir@openvz.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a zero-length packet has been requested and another packet is
written into the fifo, the MX1 tends to send the first byte of the
previous packet instead of the first byte of the current packet.
The CRC is adjusted accordingly so that this packet is _not_
discarded by the host.

Waiting for the ZLPS bit to clear avoids these bad packets.
Signed-off-by: NDaniel Glöckner <dg@emlix.com>
Cc: Darius Augulis <augulis.darius@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some usb serial host drivers expect a short packet before they forward
the data to the application. This is caused by them trying to read more
than one packet at a time. So when the gadget sends an exact multiple
of the maximum packet size, it should append a zero-length packet.
Signed-off-by: NDaniel Glöckner <dg@emlix.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This replaces dma_sync_single() and dma_sync_sg() with
dma_sync_single_for_cpu() and dma_sync_sg_for_cpu() respectively
because they is an obsolete API; include/linux/dma-mapping.h says:

/* Backwards compat, remove in 2.7.x */
#define dma_sync_single		dma_sync_single_for_cpu
#define dma_sync_sg		dma_sync_sg_for_cpu
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1245) fixes a bug in ehci-hcd.  When an URB is queued
for an endpoint whose QH is already in the LINKED state, the QH
doesn't get refreshed.  As a result, if usb_clear_halt() was called
during the time that the QH was linked but idle, the data toggle value
in the QH doesn't get reset.

The symptom is that after a clear_halt, data gets lost and transfers
time out.  This problem is starting to show up now because the
"ehci-hcd unlink speedups" patch causes QHs with no queued URBs to
remain linked for a suitable time.

The patch utilizes the new endpoint_reset mechanism to fix the
problem.  When an endpoint is reset, the new method forcibly unlinks
the QH (if necessary) and safely updates the toggle value.  This
allows qh_update() to be simplified and avoids using usb_device's
toggle bits in a rather unintuitive way.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Tested-by: NDavid <david@unsolicited.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

CPU/board specific parameters (PLL clock, vif etc...) can be set
by platform_data instead of module_param.

v2: remove irq_sense member in platform_data because it can OR in
    IRQF_TRIGGER_LOW or IRQF_TRIGGER_FALLING against IORESOURCE_IRQ in
    the struct resource.
Signed-off-by: NYoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Reviewed-by: NPaul Mundt <lethal@linux-sh.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some unusual usb devices from the maker "Option" are switched from
storage to serial/modem mode by sending a SCSI REZERO command. In one
case a fairly common vendor/device ID is affected which led to problems
for users of other modems or phones which are not supposed to be
switched.

The patch adds a filter by reading the vendor name with the SCSI INQUIRY
command, and skips the switching code for all unrecognized entries.

Further changes are cleanups and corrections pointed out by Alan Stern.

Tested with two devices with the IDs 05c6:1000, one from "Option" and
switchable, and one from Samsung (cell phone).
Signed-off-by: NJosua Dietze <digidietze@draisberghof.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1243) tries to improve ehci-hcd's scheduling of
interrupt transfers.  Instead of trying to cram all transfers with the
same period into the same frame, the new code will spread the
transfers out among lots of different frames.  This should reduce the
periodic schedule load in any one frame -- some host controllers have
trouble when there's too much work to do.

A more thorough approach would stagger the uframe values as well.  But
this is enough to make a big improvement.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NDwayne Fontenot <dwayne.fontenot@att.net>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1242) fixes the return values from the special
init functions in usb-storage.  They are supposed to return 0 for
success, not USB_STOR_TRANSPORT_GOOD.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG
register prevents the device from going into retention.
This is a workaround (by Richard Woodruff/TI), as his comment :
> A new MUSB bug which is a match to data below was identified very
> recently (on hardware and in simulation).
> This bug is in 3430 and not 3630.
> As a priority test (and as new default) you should have engineers
> disable autoidle for MUSB block.
> This is the workaround which will show up in next errata.
Signed-off-by: NNiilo Minkkinen <ext-niilo.1.minkkinen@nokia.com>
Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>