linux-stable.git/drivers/usb/host, branch v4.6.4 Linux kernel stable tree usb: host: ehci-tegra: Grab the correct UTMI pads reset 2016-07-11T16:30:02+00:00 Thierry Reding treding@nvidia.com 2016-05-26T15:23:29+00:00 094f827e836e7172cdd16bbe5e195d919013acbf commit f8a15a9650694feaa0dabf197b0c94d37cd3fb42 upstream. There are three EHCI controllers on Tegra SoCs, each with its own reset line. However, the first controller contains a set of UTMI configuration registers that are shared with its siblings. These registers will only be reset as part of the first controller's reset. For proper operation it must be ensured that the UTMI configuration registers are reset before any of the EHCI controllers are enabled, irrespective of the probe order. Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB") introduced code that ensures the first controller is always reset before setting up any of the controllers, and is never again reset afterwards. This code, however, grabs the wrong reset. Each EHCI controller has two reset controls attached: 1) the USB controller reset and 2) the UTMI pads reset (really the first controller's reset). In order to reset the UTMI pads registers the code must grab the second reset, but instead it grabbing the first. Fixes: a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB") Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f8a15a9650694feaa0dabf197b0c94d37cd3fb42 upstream.

There are three EHCI controllers on Tegra SoCs, each with its own reset
line. However, the first controller contains a set of UTMI configuration
registers that are shared with its siblings. These registers will only
be reset as part of the first controller's reset. For proper operation
it must be ensured that the UTMI configuration registers are reset
before any of the EHCI controllers are enabled, irrespective of the
probe order.

Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to
broken USB") introduced code that ensures the first controller is always
reset before setting up any of the controllers, and is never again reset
afterwards.

This code, however, grabs the wrong reset. Each EHCI controller has two
reset controls attached: 1) the USB controller reset and 2) the UTMI
pads reset (really the first controller's reset). In order to reset the
UTMI pads registers the code must grab the second reset, but instead it
grabbing the first.

Fixes: a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB")
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: Fix handling timeouted commands on hosts in weird states. 2016-07-11T16:30:02+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2016-06-01T15:09:08+00:00 ab4d7f6ccd76513da9c2909aa5a2d595cba748e7 commit 3425aa03f484d45dc21e0e791c2f6c74ea656421 upstream. If commands timeout we mark them for abortion, then stop the command ring, and turn the commands to no-ops and finally restart the command ring. If the host is working properly the no-op commands will finish and pending completions are called. If we notice the host is failing, driver clears the command ring and completes, deletes and frees all pending commands. There are two separate cases reported where host is believed to work properly but is not. In the first case we successfully stop the ring but no abort or stop command ring event is ever sent and host locks up. The second case is if a host is removed, command times out and driver believes the ring is stopped, and assumes it will be restarted, but actually ends up timing out on the same command forever. If one of the pending commands has the xhci->mutex held it will block xhci_stop() in the remove codepath which otherwise would cleanup pending commands. Add a check that clears all pending commands in case host is removed, or we are stuck timing out on the same command. Also restart the command timeout timer when stopping the command ring to ensure we recive an ring stop/abort event. Tested-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3425aa03f484d45dc21e0e791c2f6c74ea656421 upstream.

If commands timeout we mark them for abortion, then stop the command
ring, and turn the commands to no-ops and finally restart the command
ring.

If the host is working properly the no-op commands will finish and
pending completions are called.
If we notice the host is failing, driver clears the command ring and
completes, deletes and frees all pending commands.

There are two separate cases reported where host is believed to work
properly but is not. In the first case we successfully stop the ring
but no abort or stop command ring event is ever sent and host locks up.

The second case is if a host is removed, command times out and driver
believes the ring is stopped, and assumes it will be restarted, but
actually ends up timing out on the same command forever.
If one of the pending commands has the xhci->mutex held it will block
xhci_stop() in the remove codepath which otherwise would cleanup pending
commands.

Add a check that clears all pending commands in case host is removed,
or we are stuck timing out on the same command. Also restart the
command timeout timer when stopping the command ring to ensure we
recive an ring stop/abort event.

Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: xhci: Add broken streams quirk for Frescologic device id 1009 2016-07-11T16:30:02+00:00 Hans de Goede hdegoede@redhat.com 2016-06-01T19:01:29+00:00 cbe6a061de8d27494254a4929ed750962f8feec1 commit d95815ba6a0f287213118c136e64d8c56daeaeab upstream. I got one of these cards for testing uas with, it seems that with streams it dma-s all over the place, corrupting memory. On my first tests it managed to dma over the BIOS of the motherboard somehow and completely bricked it. Tests on another motherboard show that it does work with streams disabled. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d95815ba6a0f287213118c136e64d8c56daeaeab upstream.

I got one of these cards for testing uas with, it seems that with streams
it dma-s all over the place, corrupting memory. On my first tests it
managed to dma over the BIOS of the motherboard somehow and completely
bricked it.

Tests on another motherboard show that it does work with streams disabled.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: xhci-plat: properly handle probe deferral for devm_clk_get() 2016-07-11T16:30:02+00:00 Thomas Petazzoni thomas.petazzoni@free-electrons.com 2016-06-01T15:09:09+00:00 89f707fd51859e23c18de0140b305b529bdcc217 commit de95c40d5beaa47f6dc8fe9ac4159b4672b51523 upstream. On some platforms, the clocks might be registered by a platform driver. When this is the case, the clock platform driver may very well be probed after xhci-plat, in which case the first probe() invocation of xhci-plat will receive -EPROBE_DEFER as the return value of devm_clk_get(). The current code handles that as a normal error, and simply assumes that this means that the system doesn't have a clock for the XHCI controller, and continues probing without calling clk_prepare_enable(). Unfortunately, this doesn't work on systems where the XHCI controller does have a clock, but that clock is provided by another platform driver. In order to fix this situation, we handle the -EPROBE_DEFER error condition specially, and abort the XHCI controller probe(). It will be retried later automatically, the clock will be available, devm_clk_get() will succeed, and the probe() will continue with the clock prepared and enabled as expected. In practice, such issue is seen on the ARM64 Marvell 7K/8K platform, where the clocks are registered by a platform driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit de95c40d5beaa47f6dc8fe9ac4159b4672b51523 upstream.

On some platforms, the clocks might be registered by a platform
driver. When this is the case, the clock platform driver may very well
be probed after xhci-plat, in which case the first probe() invocation
of xhci-plat will receive -EPROBE_DEFER as the return value of
devm_clk_get().

The current code handles that as a normal error, and simply assumes
that this means that the system doesn't have a clock for the XHCI
controller, and continues probing without calling
clk_prepare_enable(). Unfortunately, this doesn't work on systems
where the XHCI controller does have a clock, but that clock is
provided by another platform driver. In order to fix this situation,
we handle the -EPROBE_DEFER error condition specially, and abort the
XHCI controller probe(). It will be retried later automatically, the
clock will be available, devm_clk_get() will succeed, and the probe()
will continue with the clock prepared and enabled as expected.

In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
where the clocks are registered by a platform driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: Cleanup only when releasing primary hcd 2016-07-11T16:30:02+00:00 Gabriel Krisman Bertazi krisman@linux.vnet.ibm.com 2016-06-01T15:09:07+00:00 5149a103c8803ede888a79fe38c79b5619753721 commit 27a41a83ec54d0edfcaf079310244e7f013a7701 upstream. Under stress occasions some TI devices might not return early when reading the status register during the quirk invocation of xhci_irq made by usb_hcd_pci_remove. This means that instead of returning, we end up handling this interruption in the middle of a shutdown. Since xhci->event_ring has already been freed in xhci_mem_cleanup, we end up accessing freed memory, causing the Oops below. commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to xhci_stop") is the one that changed the instant in which we clean up the event queue when stopping a device. Before, we didn't call xhci_mem_cleanup at the first time xhci_stop is executed (for the shared HCD), instead, we only did it after the invocation for the primary HCD, much later at the removal path. The code flow for this oops looks like this: xhci_pci_remove() usb_remove_hcd(xhci->shared) xhci_stop(xhci->shared) xhci_halt() xhci_mem_cleanup(xhci); // Free the event_queue usb_hcd_pci_remove(primary) xhci_irq() // Access the event_queue if STS_EINT is set. Crash. xhci_stop() xhci_halt() // return early The fix modifies xhci_stop to only cleanup the xhci data when releasing the primary HCD. This way, we still have the event_queue configured when invoking xhci_irq. We still halt the device on the first call to xhci_stop, though. I could reproduce this issue several times on the mainline kernel by doing a bind-unbind stress test with a specific storage gadget attached. I also ran the same test over-night with my patch applied and didn't observe the issue anymore. [ 113.334124] Unable to handle kernel paging request for data at address 0x00000028 [ 113.335514] Faulting instruction address: 0xd00000000d4f767c [ 113.336839] Oops: Kernel access of bad area, sig: 11 [#1] [ 113.338214] SMP NR_CPUS=1024 NUMA PowerNV [c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80 [c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0 [c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0 [xhci_pci] [c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110 [c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190 [c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70 [c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150 [c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0 [c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0 [c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0 [c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190 [c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200 [c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110 [c000000efe47be30] c000000000009260 system_call+0x38/0x108 Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Roger Quadros <rogerq@ti.com> Cc: joel@jms.id.au Reviewed-by: Roger Quadros <rogerq@ti.com> Tested-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 27a41a83ec54d0edfcaf079310244e7f013a7701 upstream.

Under stress occasions some TI devices might not return early when
reading the status register during the quirk invocation of xhci_irq made
by usb_hcd_pci_remove.  This means that instead of returning, we end up
handling this interruption in the middle of a shutdown.  Since
xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
accessing freed memory, causing the Oops below.

commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to
xhci_stop") is the one that changed the instant in which we clean up the
event queue when stopping a device.  Before, we didn't call
xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
HCD), instead, we only did it after the invocation for the primary HCD,
much later at the removal path.  The code flow for this oops looks like
this:

xhci_pci_remove()
	usb_remove_hcd(xhci->shared)
	        xhci_stop(xhci->shared)
 			xhci_halt()
			xhci_mem_cleanup(xhci);  // Free the event_queue
	usb_hcd_pci_remove(primary)
		xhci_irq()  // Access the event_queue if STS_EINT is set. Crash.
		xhci_stop()
			xhci_halt()
			// return early

The fix modifies xhci_stop to only cleanup the xhci data when releasing
the primary HCD.  This way, we still have the event_queue configured
when invoking xhci_irq.  We still halt the device on the first call to
xhci_stop, though.

I could reproduce this issue several times on the mainline kernel by
doing a bind-unbind stress test with a specific storage gadget attached.
I also ran the same test over-night with my patch applied and didn't
observe the issue anymore.

[  113.334124] Unable to handle kernel paging request for data at address 0x00000028
[  113.335514] Faulting instruction address: 0xd00000000d4f767c
[  113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
[  113.338214] SMP NR_CPUS=1024 NUMA PowerNV

[c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80
[c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0
[c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0
[xhci_pci]
[c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110
[c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190
[c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70
[c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150
[c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0
[c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0
[c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0
[c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190
[c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200
[c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110
[c000000efe47be30] c000000000009260 system_call+0x38/0x108

Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: joel@jms.id.au
Reviewed-by: Roger Quadros <rogerq@ti.com>
Tested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: host: xhci-rcar: Avoid long wait in xhci_reset() 2016-06-01T19:18:02+00:00 Yoshihiro Shimoda yoshihiro.shimoda.uh@renesas.com 2016-05-06T06:20:11+00:00 9dfa165864f52609326ac12ddf3c34c29a4b3805 commit f879fc32aa0c96fbac261b3d857a1239d554ad01 upstream. The firmware of R-Car USB 3.0 host controller will control the reset. So, if the xhci driver doesn't do firmware downloading (e.g. kernel configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR is not set), the reset of USB 3.0 host controller doesn't work correctly. Then, the host controller will cause long wait in xhci_reset() because the CMD_RESET bit of op_regs->command is not cleared for 10 seconds. So, this patch modifies the Kconfig to enable both CONFIG_USB_XHCI_PLATFORM and CONFIG_USB_XHCI_RCAR. Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers) Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f879fc32aa0c96fbac261b3d857a1239d554ad01 upstream.

The firmware of R-Car USB 3.0 host controller will control the reset.
So, if the xhci driver doesn't do firmware downloading (e.g. kernel
configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR
is not set), the reset of USB 3.0 host controller doesn't work
correctly. Then, the host controller will cause long wait in
xhci_reset() because the CMD_RESET bit of op_regs->command is not
cleared for 10 seconds.

So, this patch modifies the Kconfig to enable both CONFIG_USB_XHCI_PLATFORM
and CONFIG_USB_XHCI_RCAR.

Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers)
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value 2016-04-13T18:58:02+00:00 Peter Griffin peter.griffin@linaro.org 2016-04-13T16:58:44+00:00 f9a85f6e61c695daeb427dfc6c1d5a279654207b Otherwise generic-xhci and xhci-platform which have no data get wrongly detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is(). This fixes a regression in v4.5 for STiH407 family SoC's which use the synopsis dwc3 IP, whereby the disable_clk error path gets taken due to wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd never gets added. I suspect this will also fix other dwc3 DT platforms such as Exynos, although I've only tested on STih410 SoC. Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv") Cc: stable@vger.kernel.org Cc: gregory.clement@free-electrons.com Cc: yoshihiro.shimoda.uh@renesas.com Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Otherwise generic-xhci and xhci-platform which have no data get wrongly
detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is().

This fixes a regression in v4.5 for STiH407 family SoC's which use the
synopsis dwc3 IP, whereby the disable_clk error path gets taken due to
wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd never
gets added.

I suspect this will also fix other dwc3 DT platforms such as Exynos,
although I've only tested on STih410 SoC.

Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv")
Cc: stable@vger.kernel.org
Cc: gregory.clement@free-electrons.com
Cc: yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers 2016-04-13T18:55:56+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2016-04-08T13:25:10+00:00 98d74f9ceaefc2b6c4a6440050163a83be0abede PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will remove the xhci controller from the PCI bus when the last USB device is disconnected. Add a flag to indicate that the host is being removed to avoid queueing configure_endpoint commands for the dropped endpoints. For PCI hotplugged controllers this will prevent 5 second command timeouts For static xhci controllers the configure_endpoint command is not needed in the removal case as everything will be returned, freed, and the controller is reset. For now the flag is only set for PCI connected host controllers. Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will
remove the xhci controller from the PCI bus when the last USB device is
disconnected.

Add a flag to indicate that the host is being removed to avoid queueing
configure_endpoint commands for the dropped endpoints.
For PCI hotplugged controllers this will prevent 5 second command timeouts
For static xhci controllers the configure_endpoint command is not needed
in the removal case as everything will be returned, freed, and the
controller is reset.

For now the flag is only set for PCI connected host controllers.

Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: xhci: fix wild pointers in xhci_mem_cleanup 2016-04-13T18:55:56+00:00 Lu Baolu baolu.lu@linux.intel.com 2016-04-08T13:25:09+00:00 71504062a7c34838c3fccd92c447f399d3cb5797 This patch fixes some wild pointers produced by xhci_mem_cleanup. These wild pointers will cause system crash if xhci_mem_cleanup() is called twice. Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch fixes some wild pointers produced by xhci_mem_cleanup.
These wild pointers will cause system crash if xhci_mem_cleanup()
is called twice.

Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys 2016-04-13T18:55:56+00:00 Yoshihiro Shimoda yoshihiro.shimoda.uh@renesas.com 2016-04-08T13:25:08+00:00 5ad3b03e4910f9f62342956ecdc758c7af6b8699 This patch fixes an issue that cannot work if R-Car Gen2/3 run on above 4GB physical memory environment to use a quirk XHCI_NO_64BIT_SUPPORT. Cc: <stable@vger.kernel.org> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch fixes an issue that cannot work if R-Car Gen2/3 run on
above 4GB physical memory environment to use a quirk XHCI_NO_64BIT_SUPPORT.

Cc: <stable@vger.kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>