This patch (as1382) changes the USB_EHCI_TT_NEWSCHED Kconfig option to
be non-experimental and to default to Y.  This option has existed for
a long time, and I have not heard any complaints concerning it.  By
contrast, several people have reported that their devices could be
made to work only by enabling the option.

The point of changing the default is to cause the option to be enabled
by distros that simply use the default settings for esoteric things
like this.

This change was motivated by Bugzilla #15649.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When code to manipulate the command register was refactored from
xhci_run() to xhci_start(), a debugging statement was left behind that no
longer applies.  Remove that statement.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NSergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1392) fixes a bug in uhci-hcd: The start_rh() routine is
supposed to be called with the private spinlock held.  If an IRQ comes
in at just the wrong time, the driver will think the controller has
died when in fact it simply hasn't start yet.

The patch also addresses some issues that may prevent an URB from
being unlinked after the controller has stopped.  This is an abnormal
occurrence (ordinarily the controller stops only when the entire bus
is suspended and hence there are no active URBs), so the pathways
haven't gotten much testing.  These two changes may be a little more
than is strictly necessary, but clearly they won't hurt.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add OHCI glue code for JZ4740 SoCs OHCI module.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: linux-usb@vger.kernel.org
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1411/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Remove the CONFIG_SOC_AU1X00 Kconfig symbol since its job can also be done
by MACH_ALCHEMY, now renamed to MIPS_ALCHEMY.
Signed-off-by: NManuel Lauss <manuel.lauss@googlemail.com>
To: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/1461/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Instead of io_req_t, drivers are now requested to fill out
struct pcmcia_device *p_dev->resource[0,1] for up to two ioport
ranges. After a call to pcmcia_request_io(), the ports found there
are reserved, after calling pcmcia_request_configuration(), they may
be used.

CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-ide@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: laforge@gnumonks.org
CC: linux-mtd@lists.infradead.org
CC: alsa-devel@alsa-project.org
CC: linux-serial@vger.kernel.org
CC: Michael Buesch <mb@bu3sch.de>
Acked-by: Marcel Holtmann <marcel@holtmann.org> (for drivers/bluetooth/)
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

After pcmcia_request_io(), do not make use of the values stored in
io_req_t, but instead use those found in struct pcmcia_device->resource[].

CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-ide@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: laforge@gnumonks.org
CC: linux-mtd@lists.infradead.org
CC: alsa-devel@alsa-project.org
CC: linux-serial@vger.kernel.org
Acked-by: Marcel Holtmann <marcel@holtmann.org> (for drivers/bluetooth/)
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Remove cs_types.h which is no longer needed: Most definitions aren't
used at all, a few can be made away with, and two remaining definitions
(typedefs, unfortunatley) may be moved to more specific places.

CC: linux-ide@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: laforge@gnumonks.org
CC: linux-mtd@lists.infradead.org
CC: alsa-devel@alsa-project.org
CC: linux-serial@vger.kernel.org
Acked-by: Marcel Holtmann <marcel@holtmann.org> (for drivers/bluetooth/)
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

The bmAttributes field of the SuperSpeed Endpoint Companion Descriptor has
different meanings, depending on the endpoint type.  If the endpoint is
isochronous, the bmAttributes field is the maximum number of packets
within a service interval that this endpoint supports.  If the endpoint is
bulk, it's the number of stream IDs this endpoint supports.

Only set the Mult field of the xHCI endpoint context using the
bmAttributes field if the endpoint is isochronous, and the device is a
SuperSpeed device.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a configured device is reset, the control endpoint's ring is reused.
If control transfers to the device were issued before the device is reset,
the dequeue pointer will be somewhere in the middle of the ring.  If the
device is then issued an address with the set address command, the xHCI
driver must provide a valid input context for control endpoint zero.

The original code would give the hardware the original input context,
which had a dequeue pointer set to the top of the ring.  This would cause
the host to re-execute any control transfers until it reached the ring's
enqueue pointer.  When issuing a set address command for a device that has
just been configured and then reset, use the control endpoint's enqueue
pointer as the hardware's dequeue pointer.

Assumption:  All control transfers will be completed or cancelled before
the set address command is issued to the device.  If there are any
outstanding control transfers, this code will not work.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Commit 6c12db90 also seems to have
introduced a bug that is triggered when the command ring is about to wrap.
The inc_enq() function will not have moved the enqueue pointer past the
link TRB.  It is supposed to be moved past the link TRB in prepare_ring(),
which should be called before a TD is enqueued.  However, the
queue_command() function never calls the prepare_ring() function because
prepare_ring() is only supposed to be used for endpoint rings.  That means
the enqueue pointer will not be moved past the link TRB, and will get
overwritten.

The fix is to make queue_command() call prepare_ring() with a fake
endpoint status (set to running).  Then the enqueue pointer will get moved
past the link TRB.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

i.MX25's EHCI is the same as i.MX35's one.
Signed-off-by: NEric Bénard <eric@eukrea.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Reported-by: NChristian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Stanse found that isp1362_sw_reset tries to take a isp1362_hcd->lock,
but it is already held in isp1362_hc_stop. Avoid that by introducing
__isp1362_sw_reset which doesn't take the lock and call it from
isp1362_hc_stop. isp1362_sw_reset is then as simple as lock --
__isp1362_sw_reset -- unlock.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Bryan Wu <cooloney@kernel.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The old code registered the hcd even if there were no transceivers
detected, leading to oopses like this if we try to probe a non-existant
ULPI:

[    2.730000] mxc-ehci mxc-ehci.0: unable to init transceiver
[    2.740000] timeout polling for ULPI device
[    2.740000] timeout polling for ULPI device
[    2.750000] mxc-ehci mxc-ehci.0: unable to enable vbus on transceiver
[    2.750000] mxc-ehci mxc-ehci.0: Freescale On-Chip EHCI Host Controller
[    2.760000] mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 2
[    2.770000] Unhandled fault: external abort on non-linefetch (0x808) at 0xc4876184
[    2.770000] Internal error: : 808 [#1] PREEMPT
[    2.770000] last sysfs file:
[    2.770000] Modules linked in:
[    2.770000] CPU: 0    Not tainted  (2.6.33.5 #5)
[    2.770000] PC is at ehci_hub_control+0x4d4/0x8f8
[    2.770000] LR is at ehci_mxc_setup+0xbc/0xdc
[    2.770000] pc : [<c0196dfc>]    lr : [<c019bc8c>]    psr: 00000093
[    2.770000] sp : c3815e40  ip : 00000001  fp : 60000013
[    2.770000] r10: c4876184  r9 : 00000000  r8 : c3814000
[    2.770000] r7 : c391d2cc  r6 : 00000001  r5 : 00000001  r4 : 00000000
[    2.770000] r3 : 80000000  r2 : 00000007  r1 : 80000000  r0 : c4876184
[    2.770000] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel
[    2.770000] Control: 0005317f  Table: a0004000  DAC: 00000017
[    2.770000] Process swapper (pid: 1, stack limit = 0xc3814270)
...
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable <stable@kernel.org>
Acked-by: NDaniel Mack <daniel@caiaq.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In the change by 749da5f8,
The change in the status when the USB device is connected is wrong.
Therefore, the device is not recognized.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
CC: Paul Mundt" <lethal@linux-sh.org>
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Commit 6c12db90 introduced a bug for
control transfers.  The patch was supposed to change when the link TRBs at
the end of each ring segment were given to the hardware.  If a transfer
descriptor (TD) ended just before the link TRB, the code wouldn't give
back the link TRB to the hardware; instead it would be given back in
prepare_ring() just before the next TD was enqueued at the top of the
ring.

Unfortunately, the code relied on checking the chain bit of the TRB to
determine whether the TD ended just before the link TRB.  It assumed that
the ring enqueuing code would call prepare_ring() before enqueuing the
next TD.  However, control transfers are made of multiple TDs, and
prepare_ring() is only called once before enqueuing two or three TDs.

If the first or second TD of the control transfer ended just before the
link TRB, then the code in inc_enq() would not move the enqueue pointer
past the link TRB, and the link TRB would get overwritten.  This would
cause the xHCI driver to start writing to memory past the ring segment,
and eventually the system would crash or hang.

The fix is to add a flag to inc_enq() that says whether the caller will
enqueue more TDs before calling prepare_ring().  If the chain bit is
cleared (meaning this is the last TRB in a TD), and the caller will not
enqueue more TDs, then we defer giving back the link TRB.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes the driver to allow both CONFIG_USB_EHCI_HCD_PPC_OF and
CONFIG_USB_ECHI_HCD_XILINX to be selected.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
CC: John Linn <john.linn@xilinx.com>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The NEC xHCI host controller firmware version can be found by putting a
vendor-specific command on the command ring and extracting the BCD
encoded-version out of the vendor-specific event TRB.

The firmware version debug line in dmesg will look like:

xhci_hcd 0000:05:00.0: NEC firmware version 30.21

(NEC merged with Renesas Technologies and became Renesas Electronics on
April 1, 2010.  I have their OK to merge this vendor-specific code.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Satoshi Otani <satoshi.otani.xm@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When the run bit is set in the xHCI command register, it may take a few
microseconds for the host to start running.  We cannot ring any doorbells
until the host is actually running, so wait until the status register says
the host is running.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NShinya Saito <shinya.saito.sx@renesas.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After software resets an xHCI host controller, it must wait for the
"Controller Not Ready" (CNR) bit in the status register to be cleared.
Software is not supposed to ring any doorbells or write to any registers
except the status register until this bit is cleared.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The Blackfin code is incorrectly casting the argument to inw() to a pointer.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix driver to use new location of of_node pointer (introduced by commit
use new location of of_node pointer (introduced by commit
61c7a080; of: Always use 'struct
device.of_node' to get device node pointer)
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Reported-by: NJohn Linn <john.linn@xilinx.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: linux-usb@vger.kernel.org
CC: devicetree-discuss@lists.ozlabs.org

r8a66597-hcd is erroneously using PIO routines on MMIO registers, which
presently blows up for any platform that elects to either override or do
away with PIO routines. This managed to work for the common cases since
the PIO routines were simply wrapped to their MMIO counterparts. This
switches over to using the MMIO routines directly, and enables us to kill
off a lot of superfluous casting in the process.
Acked-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

.name, .match_table and .owner are duplicated in both of_platform_driver
and device_driver.  This patch is a removes the extra copies from struct
of_platform_driver and converts all users to the device_driver members.

This patch is a pretty mechanical change.  The usage model doesn't change
and if any drivers have been missed, or if anything has been fixed up
incorrectly, then it will fail with a compile time error, and the fixup
will be trivial.  This patch looks big and scary because it touches so
many files, but it should be pretty safe.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NSean MacLennan <smaclennan@pikatech.com>

Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Since commit 7acd72eb ("kfifo: rename
kfifo_put... into kfifo_in... and kfifo_get... into kfifo_out..."),
kfifo_out() is marked __must_check, and that causes gcc to produce
lots of warnings like this:

  CC      drivers/usb/host/fhci-mem.o
In file included from drivers/usb/host/fhci-hcd.c:34:
drivers/usb/host/fhci.h: In function 'cq_get':
drivers/usb/host/fhci.h:520: warning: ignoring return value of 'kfifo_out', declared with attribute warn_unused_result
...

This patch fixes the issue by properly checking the return value.
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Cc: stable <stable@kernel.org> [.33 and .34]
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1380) fixes a bug in the wakeup settings for EHCI host
controllers.  When the controller is suspended, if it isn't enabled
for remote wakeup then we have to turn off all the port wakeup flags.
Disabling PCI PME# isn't good enough, because some systems (Intel)
evidently use alternate wakeup signalling paths.

In addition, the patch improves the handling of the Intel Moorestown
hardware by performing various power-up and power-down delays just
once instead of once for each port (i.e., the delays are moved outside
of the port loops).  This requires extra code, but the total delay
time is reduced.

There are also a few additional minor cleanups.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NOndrej Zary <linux@rainbow-software.org>
CC: Alek Du <alek.du@intel.com>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is a bug fix for PHCD (phy clock disable) low power feature:
After PHCD is set, any write to PORTSC register is illegal, so when
resume ports, clear PHCD bit first.
Signed-off-by: NAlek Du <alek.du@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Our virtual xHCI device can have as many ports as we like - I've tested
this patch with 31.
Signed-off-by: NWilliam Gulland <wgulland@vmware.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

An undocumented "feature" in the OMAP3 EHCI controller causes
suspended ports to be taken out of suspend when the USBCMD.Run/Stop
bit is cleared (this bit is normally cleared when ehci_bus_suspend
is called).

This "feature" breaks suspend-resume if the root-hub is allowed
to suspend. (The controller thinks it is in resume, and the PHY
thinks it is still in suspend).

There is an undocumented register bit that can be used to disable
this feature and restore normal behavior. Set this bit so
suspend-resume can work normally.

Tested on OMAP3 SDPs with the NXP ISP1504 and NXP ISP1703 PHYs.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Macro TRB_TYPE is misused in some places. Fix the wrong usage.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change transfer ring behavior to not follow/activate link TRBs
until active TRBs are queued after it.  This change affects
the behavior when a TD ends just before a link TRB.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On OMAP systems, we have two different OHCI controllers. The legacy
one is present in OMAP1/2 chips, and the newer one comes bundled as
a companion to the EHCI controller on OMAP3 and newer chips.

We may have multi-omap configurations where OMAP2 and OMAP3
support may be enabled in the same kernel, and need a mechanism
to keep both drivers around.

This patch adds a Kconfig entry for each of these drivers.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add support for the OHCI controller present in OMAP3 and newer chips.

The code is mostly based off the ehci-omap.c driver.
Some of it is common to both drivers and will eventually
need to be factored out to platform init files.

In its current state, the driver cannot co-exist with the ehci-omap
driver, and this will be fixed in later versions. The second driver
to be loaded will overwrite settings made by the other. For now,
this driver should allow the few users of OMAP3 OHCI to get going.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There were some reports[1] of isp1760 USB driver malfunctioning
with high speed devices, noticed on Blackfin and PowerPC targets.
These reports indicated that the original Philips 'pehcd'[2]
driver worked fine.

We've noticed the same issue with an ARM RealView platform. This
happens under load (with only some mass storage devices, not all,
just as in another report[3]):

  error bit is set in DW3
  error bit is set in DW3
  error bit is set in DW3
  usb 1-1.2: device descriptor read/64, error -32

It appears that the 'pehcd' driver checks the X bit only if the
transaction is halted (H bit), otherwise the error is so far
insignificant.

The ISP176x chips were modeled after EHCI, and EHCI spec says
(thanks to Alan Stern for pointing out):

"Transaction errors cause the status field to be updated to reflect
 the type of error, but the transaction continues to be retried until
 the Active bit is set to 0.  When the error counter reaches 0, the
 Halt bit is set and the Active bit is cleared."

So, just as the original Philips driver, isp1760 must report the
error only if the transaction error and the halt bits are set.

[1] http://markmail.org/message/lx4qrlbrs2uhcnly
[2] svn co svn://sources.blackfin.uclinux.org/linux-kernel/trunk/drivers/usb/host -r 5494
    See pehci.c:pehci_hcd_update_error_status().
[3] http://blackfin.uclinux.org/gf/tracker/5148Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix gcc warning on mixed declarations/code:
drivers/usb/host/u132-hcd.c:1450: warning: ISO C90 forbids mixed declarations and code
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After using state stored in xhci_virt_ep to clean up a stalled endpoint,
be sure to set the stalled stream ID back to 0.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the resource_size function instead of manually calculating the
resource size.  This reduces the chance of introducing off-by-one
errors.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>