The expression

	while (running_total < sg_dma_len(sg))

does not take into account that the remaining data length can be less
than sg_dma_len(sg). In that case, running_total can end up being
greater than the total data length, so an extra TRB is counted.
Changing the expression to

	while (running_total < sg_dma_len(sg) && running_total < temp)

fixes that.

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Calculations like

	running_total = TRB_MAX_BUFF_SIZE -
		(sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1));
	if (running_total != 0)
		num_trbs++;

are incorrect, because running_total can never be zero, so the if()
expression will never be true. I think the intention was that
running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1
to TRB_MAX_BUFF_SIZE. So adding a

	running_total &= TRB_MAX_BUFF_SIZE - 1;

fixes the problem.

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

This makes it easier to spot some problems, which will be fixed by the
next patch in the series. Also change dev_dbg to dev_err in
check_trb_math(), so any math errors will be visible even when running
with debug disabled.

Note: This patch changes the expressions containing
"((1 << TRB_MAX_BUFF_SHIFT) - 1)" to use the equivalent
"(TRB_MAX_BUFF_SIZE - 1)". No change in behavior is intended for
those expressions.

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Change the BUGs in xhci_find_new_dequeue_state() to WARN_ONs, to avoid
bringing down the box if one of them is hit

This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

This patch fixes the below compilation errors.

  CC      drivers/usb/gadget/ci13xxx_msm.o
  CC      net/mac80211/led.o
  drivers/usb/gadget/ci13xxx_msm.c: In function 'ci13xxx_msm_notify_event':
  drivers/usb/gadget/ci13xxx_msm.c:42: error: 'USB_AHBBURST' undeclared (first use in this function)
  drivers/usb/gadget/ci13xxx_msm.c:42: error: (Each undeclared identifier is reported only once
  drivers/usb/gadget/ci13xxx_msm.c:42: error: for each function it appears in.)
  drivers/usb/gadget/ci13xxx_msm.c:43: error: 'USB_AHBMODE' undeclared (first use in this function)
make[4]: *** [drivers/usb/gadget/ci13xxx_msm.o] Error 1
make[3]: *** [drivers/usb/gadget] Error 2

MSM USB driver is not supported on boards like trout (MSM7201) which
has an external PHY.
Signed-off-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a msleep with spin lock held during ehci pci suspend, which will
cause kernel BUG: scheduling while atomic. Fix that.

[  184.139620] BUG: scheduling while atomic: kworker/u:11/416/0x00000002
[  184.139632] 4 locks held by kworker/u:11/416:
[  184.139640]  #0:  (events_unbound){+.+.+.}, at: [<c104ddd4>] process_one_work+0x1b3/0x4cb
[  184.139669]  #1:  ((&entry->work)){+.+.+.}, at: [<c104ddd4>] process_one_work+0x1b3/0x4cb
[  184.139686]  #2:  (&__lockdep_no_validate__){+.+.+.}, at: [<c127cde3>] __device_suspend+0x2c/0x154
[  184.139706]  #3:  (&(&ehci->lock)->rlock){-.-...}, at: [<c132f3d8>] ehci_pci_suspend+0x35/0x7b
[  184.139725] Modules linked in: serio_raw pegasus joydev mrst_gfx(C) battery
[  184.139748] irq event stamp: 52
[  184.139753] hardirqs last  enabled at (51): [<c14fdaac>] mutex_lock_nested+0x258/0x293
[  184.139766] hardirqs last disabled at (52): [<c14fe7b4>] _raw_spin_lock_irqsave+0xf/0x3e
[  184.139777] softirqs last  enabled at (0): [<c10371c1>] copy_process+0x3d2/0x109d
[  184.139789] softirqs last disabled at (0): [<  (null)>]   (null)
[  184.139802] Pid: 416, comm: kworker/u:11 Tainted: G         C  2.6.37-6.3-adaptation-oaktrail #37
[  184.139809] Call Trace:
[  184.139820]  [<c102eeff>] __schedule_bug+0x5e/0x65
[  184.139829]  [<c14fbca5>] schedule+0xac/0xc4c
[  184.139840]  [<c11d4845>] ? string+0x37/0x8b
[  184.139853]  [<c1044f21>] ? lock_timer_base+0x1f/0x3e
[  184.139863]  [<c14fe7da>] ? _raw_spin_lock_irqsave+0x35/0x3e
[  184.139876]  [<c1061590>] ? trace_hardirqs_off+0xb/0xd
[  184.139885]  [<c14fccdc>] schedule_timeout+0x283/0x2d9
[  184.139896]  [<c104516f>] ? process_timeout+0x0/0xa
[  184.139906]  [<c14fcd47>] schedule_timeout_uninterruptible+0x15/0x17
[  184.139916]  [<c104566a>] msleep+0x10/0x16
[  184.139926]  [<c132f316>] ehci_adjust_port_wakeup_flags+0x69/0xf6
[  184.139937]  [<c132f3eb>] ehci_pci_suspend+0x48/0x7b
[  184.139946]  [<c1326587>] suspend_common+0x52/0xbb
[  184.139956]  [<c1326625>] hcd_pci_suspend+0x26/0x28
[  184.139967]  [<c11e7182>] pci_pm_suspend+0x5f/0xd0
[  184.139976]  [<c127ca3a>] pm_op+0x5d/0xf0
[  184.139986]  [<c127ceac>] __device_suspend+0xf5/0x154
[  184.139996]  [<c127d2c8>] async_suspend+0x16/0x3a
[  184.140006]  [<c1058f54>] async_run_entry_fn+0x89/0x111
[  184.140016]  [<c104deb6>] process_one_work+0x295/0x4cb
[  184.140026]  [<c1058ecb>] ? async_run_entry_fn+0x0/0x111
[  184.140036]  [<c104e3d0>] worker_thread+0x17f/0x298
[  184.140045]  [<c104e251>] ? worker_thread+0x0/0x298
[  184.140055]  [<c105277f>] kthread+0x64/0x69
[  184.140064]  [<c105271b>] ? kthread+0x0/0x69
[  184.140075]  [<c1002efa>] kernel_thread_helper+0x6/0x1a
Signed-off-by: NYin Kangkai <kangkai.yin@intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <dbrownell@users.sourceforge.net>
CC: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In drivers/usb/host/sl811-hcd.c::sl811h_urb_enqueue(), memory is allocated
with kzalloc() and assigned to 'ep'. If we leave via the 'fail' label due
to 'if (ep->maxpacket > H_MAXPACKET)', then 'ep' will go out of scope
without having been assigned to anything, so we'll leak the memory we
allocated.
This patch fixes the leak by simply calling kfree(ep); before jumping to
the 'fail' label.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There are a few error paths in ehci_hcd_omap_probe that can be triggered
because of memory allocation or hw failure. Change those dev_dbg error
prints to dev_err with an error code printed so that the end users are able
to notice the issue.
Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add support for setting CHRGVBUS to workaround a hardware bug on efika mx/sb
boards.
See http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/037341.htmlSigned-off-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

commit 711669e5 fixed port 0 support
for i.MX51 but broke it for (at least) i.MX27 which doesn't have
a usb_phy1 clock but has a pdev->id 0.
Signed-off-by: NEric Bénard <eric@eukrea.com>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Previously a check was done on an ID register at the base of a CPU's
internal USB registers to determine if system interface regsiters were
present.  The check looked for an ID register that had the format
ID[0:5] == ~ID[8:13] as described in the MPC5121 User's Manual to
determine if a MPC5121 or MPC83xx/85xx was being used.

There are two issues with this method:
- The ID register is not defined on the MPC83xx/85xx CPUs, so its
  unclear what is being checked on them.
- Newer CPUs such as the P4080 also don't document the ID register, but
  do share the same format as the MPC5121.  Thus the previous code did
  not set 'have_sysif_regs' properly which results in the P4080 not
  properly initializing its USB ports.

Using the device tree 'compatible' node is a cleaner way to determine if
'have_sysif_regs' should be set and resolves the USB initialization issue
seen on the P4080.

Tested on a P4080-based system and compile tested on mpc512x_defconfig
with Freescale EHCI driver enabled.

Cc: Anatolij Gustschin <agust@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1440) fixes a bug in ehci-hcd.  ehci->periodic_size is
used to compute the size in a dma_alloc_coherent() call, but then it
gets changed later on.  As a result, the corresponding call to
dma_free_coherent() passes a different size from the original
allocation.  Fix the problem by adjusting ehci->periodic_size before
carrying out any of the memory allocations.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
CC: David Brownell <david-b@pacbell.net>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

AMD Hudson also needs the same ASPM quirk as SB800
Signed-off-by: NAlex He <alex.he@amd.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The unused space in the doorbell is now marked as RsvdZ, not RsvdP, so
we can avoid reading the doorbell before writing it.

Update the doorbell-related defines to produce the entire doorbell value
from a single macro.  Document the doorbell format in a comment.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

printk_ratelimit() is misused in xhci-ring.c.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

dev_dbg() is used to print ordinary transfer messages in xhci-ring.c.
System log messages will be flushed if CONFIG_USB_DEBUG is set. Replace the
dev_dbg() with xhci_dbg().
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

giveback_first_trb() controls the cycle bit set of the start_trb, to ensure
that the start_trb is written last and the host controller will receive a
whole td at a time.

However, if the ring is wrapped and cycle bit is toggled to zero, then
giveback_first_trb() will be of no effect. In this case, set the cycle bit of
start_trb to 1 at the beginning and clear it in giveback_first_trb().
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Parameter *td is not used in giveback_first_trb(). Remove it.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Fix the more_trbs_coming field of queue_trb() in isoc transfer.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When xhci_discover_or_reset_device() is called after a host controller
power loss, the virtual device may need to be reallocated.  Make sure
xhci_alloc_dev() uses GFP_NOIO.  This avoid causing a deadlock by allowing
the kernel to flush pending I/O while reallocating memory for a virtual
device for a USB mass storage device that's holding the backing store for
dirty memory buffers.

This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

when unloading xhci_hcd, I got:
[  134.856813] xhci_hcd 0000:02:00.0: remove, state 4
[  134.858140] usb usb3: USB disconnect, address 1
[  134.874956] xhci_hcd 0000:02:00.0: Host controller not halted, aborting reset.
[  134.876351] BUG: sleeping function called from invalid context at kernel/mutex.c:85
[  134.877657] in_atomic(): 0, irqs_disabled(): 1, pid: 1451, name: modprobe
[  134.878975] Pid: 1451, comm: modprobe Not tainted 2.6.37-rc5+ #162
[  134.880298] Call Trace:
[  134.881602]  [<ffffffff8104156a>] __might_sleep+0xeb/0xf0
[  134.882921]  [<ffffffff814763dc>] mutex_lock+0x24/0x50
[  134.884229]  [<ffffffff810a745c>] free_desc+0x2e/0x5f
[  134.885538]  [<ffffffff810a74c8>] irq_free_descs+0x3b/0x71
[  134.886853]  [<ffffffff8102584d>] free_irq_at+0x31/0x36
[  134.888167]  [<ffffffff8102723f>] destroy_irq+0x69/0x71
[  134.889486]  [<ffffffff8102747a>] native_teardown_msi_irq+0xe/0x10
[  134.890820]  [<ffffffff8124c382>] default_teardown_msi_irqs+0x57/0x80
[  134.892158]  [<ffffffff8124be46>] free_msi_irqs+0x8b/0xe9
[  134.893504]  [<ffffffff8124cd46>] pci_disable_msix+0x35/0x39
[  134.894844]  [<ffffffffa01b444a>] xhci_cleanup_msix+0x31/0x51 [xhci_hcd]
[  134.896186]  [<ffffffffa01b4b3a>] xhci_stop+0x3a/0x80 [xhci_hcd]
[  134.897521]  [<ffffffff81341dd4>] usb_remove_hcd+0xfd/0x14a
[  134.898859]  [<ffffffff813500ae>] usb_hcd_pci_remove+0x5c/0xc6
[  134.900193]  [<ffffffff8123c606>] pci_device_remove+0x3f/0x91
[  134.901535]  [<ffffffff812e7ea4>] __device_release_driver+0x83/0xd9
[  134.902899]  [<ffffffff812e8571>] driver_detach+0x86/0xad
[  134.904222]  [<ffffffff812e7d56>] bus_remove_driver+0xb2/0xd8
[  134.905540]  [<ffffffff812e8633>] driver_unregister+0x6c/0x74
[  134.906839]  [<ffffffff8123c8e4>] pci_unregister_driver+0x44/0x89
[  134.908121]  [<ffffffffa01b940e>] xhci_unregister_pci+0x15/0x17 [xhci_hcd]
[  134.909396]  [<ffffffffa01bd7d2>] xhci_hcd_cleanup+0xe/0x10 [xhci_hcd]
[  134.910652]  [<ffffffff8107fcd1>] sys_delete_module+0x1ca/0x23b
[  134.911882]  [<ffffffff81123932>] ? path_put+0x22/0x26
[  134.913104]  [<ffffffff8109a800>] ? audit_syscall_entry+0x2c/0x148
[  134.914333]  [<ffffffff8100ac82>] system_call_fastpath+0x16/0x1b
[  134.915658] xhci_hcd 0000:02:00.0: USB bus 3 deregistered
[  134.916465] xhci_hcd 0000:02:00.0: PCI INT A disabled

and the same issue when xhci_suspend is invoked.  (Note from Sarah: That's
fixed by Andiry's patch before this, by synchronizing the irqs rather than
freeing them on suspend.)

Do not run xhci_cleanup_msix with irq disabled.

This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Synchronize the interrupts instead of free them in xhci_suspend(). This will
prevent a double free when the host is suspended and then the card removed.

Set the flag hcd->msix_enabled when using MSI-X, and check the flag in
suspend_common(). MSI-X synchronization will be handled by xhci_suspend(),
and MSI/INTx will be synchronized in suspend_common().

This patch should be queued for the 2.6.37 stable tree.
Reported-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

The original code that resumed the USB bus on a port status change would
only do so when there was a device connected to the port.  If a device was
just disconnected, the event would be queued for khubd, but khubd wouldn't
run.  That would leave the connect status change (CSC) bit set.

If a USB device was plugged into that same port, the xHCI host controller
would set the current connect status (CCS) bit.  But since the CSC bit was
already set, it would not generate an interrupt for a port status change
event.  That would mean the user could "Safely Remove" a device, have the
bus suspend, disconnect the device, re-plug it in, and then the device
would never be enumerated.

Plugging in a different device on another port would cause the bus to
resume, and khubd would notice the re-connected device.  Running lsusb
would also resume the bus, leading users to report the problem "went away"
when using diagnostic tools.

The solution is to resume the bus when a port status change event is
received, regardless of the port status.

Thank you very much to Maddog for helping me track down this Heisenbug.

This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NJon 'maddog' Hall <maddog@li.org>
Tested-by: NAndiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org

The below patch fixes a typo "diable" to "disable" and also fixes another typo in a comment.
Please let me know if this is correct or not.
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Current code doesn't really enable the usb clocks so if they're disabled
when booting linux, the kernel/machine will hang as soon as someone is trying
to read a usb register
Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

flush_scheduled_work() is being deprecated.  Directly flush or cancel
work items instead.

* u_ether, isp1301_omap, speedtch conversions are straight-forward.

* ochi-hcd should only flush when quirk_nec() is true as otherwise the
  work wouldn't have been initialized.

* In oti6858, cancel_delayed_work() + flush_scheduled_work() ->
  cancel_delayed_work_sync().
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Duncan Sands <duncan.sands@free.fr>
Cc: linux-usb@vger.kernel.org

In order to read/write to the i.MX OTG viewport register it is necessary to setup
the PORTSCx register first.

By default i.MX OTG port is configured for USB serial PHY. In order to use a ULPI PHY
the PORTSCx register needs to be configured properly.

commit 724c8525 (USB: ehci/mxc: compile fix) placed the PORTSC setup after the OTG
viewport is accessed and this causes ULPI read/write to fail.

Revert the PORTSC setup order.

Tested on a MX31PDK board with a ISP1504 transceiver:

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
mxc-ehci mxc-ehci.0: initializing i.MX USB Controller
ULPI transceiver vendor/product ID 0x04cc/0x1504
Found NXP ISP1504 ULPI transceiver.
ULPI integrity check: passed.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The TLL channel enable code searches for the wrong mask, and
could end up enabling the wrong port. Fix this.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is the ohci-omap3 driver, not ehci-omap. Correct this
obvious typo.
Signed-off-by: NKeshava Munegowda <keshava_mgowda@ti.com>
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Enable runtime PM and mark no_callbacks flag.  OTG device, parent of
HCD takes care of putting hardware into low power mode.  Adjust port
power wakeup flags during system suspend and resume.
Signed-off-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds support for EHCI compliant HSUSB Host controller found
on MSM chips.  The root hub has a single port and TT is built into it.
This driver depends on OTG driver for PHY initialization, clock
management and powering up VBUS.
Signed-off-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When ASPM PM Feature is enabled on UMI link, devices that use ISOC stream of
data transfer may be exposed to longer latency causing less than optimal per-
formance of the device. The longer latencies are normal and are due to link
wake time coming out of low power state which happens frequently to save
power when the link is not active.
The following code will make exception for certain features of ASPM to be by
passed and keep the logic normal state only when the ISOC device is connected
and active. This change will allow the device to run at optimal performance
yet minimize the impact on overall power savings.
Signed-off-by: NAlex He <alex.he@amd.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fixed coding style issues (delete trailing whitespaces, break
long line)
Signed-off-by: NTobias Ollmann <tobias.ollmann@gmx.at>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Annotate whci_hcd_id_table as '__used' to fix following warning:

  CC      drivers/usb/host/whci/hcd.o
drivers/usb/host/whci/hcd.c:359: warning: ‘whci_hcd_id_table’ defined but not used
Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix two bugs with the port array setup.

The first bug will only show up with broken xHCI hosts with Extended
Capabilities registers that have duplicate port speed entries for the same
port.  The idea with the original code was to set the port_array entry to
-1 if the duplicate port speed entry said the port was a different speed
than the original port speed entry.  That would mean that later, the port
would not be exposed to the USB core. Unfortunately, I forgot a continue
statement, and the port_array entry would just be overwritten in the next
line.

The second bug would happen if there are conflicting port speed registers
(so that some entry in port_array is -1), or one of the hardware port
registers was not described in the port speed registers (so that some
entry in port_array is 0).  The code that sets up the usb2_ports array
would accidentally claim those ports.  That wouldn't really cause any
user-visible issues, but it is a bug.

This patch should go into the stable trees that have the port array and
USB 3.0 port disabling prevention patches.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Several of the EHCI glue drivers either predate or were merged in the
same timeframe as API changes at the USB core level, resulting in some
missing endpoint_reset and clear_tt_buffer_complete callbacks.

This fixes up all of ehci-atmel, mxc, w90x900, and xilinx-of to tie in
the new helpers, which brings them in line with everyone else.
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Hi,

The [vk][cmz]alloc(_node) family of functions return void pointers which
it's completely unnecessary/pointless to cast to other pointer types since
that happens implicitly.

This patch removes such casts from drivers/usb/
Signed-off-by: NJesper Juhl <jj@chaosbits.net>

Update the ehci-omap glue layer to support the controller in the
OMAP4. Major differences from OMAP3 is that the OMAP4 has per-port
clocking, and supports ULPI output clocking mode. The old input
clocking mode is not supported.

Also, there are only 2 externally available ports as against 3
in the OMAP3. The third port is internally tied off and should
not be used.
Signed-off-by: NKeshava Munegowda <keshava_mgowda@ti.com>
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>

Introduce helper functions to test port mode. These checks are
performed in several places in the driver, and these helpers
improve readability.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>

Use the recently updated aliases to get functional clocks needed by
the driver. This allows the driver to acquire OMAP4-specific clocks
without having to use different clock names for OMAP3 and OMAP4.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>