Use devm_platform_get_and_ioremap_resource() to simplify code, which
contains platform_get_resource() and devm_ioremap_resource(), it also
get the resource for use by the following code.
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NDejin Zheng <zhengdejin5@gmail.com>
Link: https://lore.kernel.org/r/20200323160612.17277-4-zhengdejin5@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_platform_get_and_ioremap_resource() to simplify code, which
contains platform_get_resource() and devm_ioremap_resource(), it also
get the resource for use by the following code.
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NDejin Zheng <zhengdejin5@gmail.com>
Link: https://lore.kernel.org/r/20200323160612.17277-3-zhengdejin5@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Get usb-phy's for availbale USB 2 phys. Register id notifiers for available
usb-phy's to receive role change notifications. Perform PP for the received
role change usb ports.
Signed-off-by: NNagarjuna Kristam <nkristam@nvidia.com>
[treding@nvidia.com: rebase onto Greg's usb-next branch]
Signed-off-by: NThierry Reding <treding@nvidia.com>

In the same way as Intel Ice Lake TCSS (Type-C Subsystem) the Tiger Lake
TCSS xHCI needs to be runtime suspended whenever possible to allow the
TCSS hardware block to enter D3cold and thus save energy.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-10-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Depending on the current link state the steps to resume the link to U0
varies. The normal case when a port is suspended (U3) we set the link
to U0 and wait for a port event when U3exit completed and port moved to
U0.

If the port is in U1/U2, then no event is issued, just set link to U0

If port is in Resume or Recovery state then the device has already
initiated resume, and this host initiated resume is racing against it.
Port event handler for device initiated resume will set link to U0,
just wait for the port to reach U0 before returning.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-9-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Like U3 case, xHCI spec doesn't specify the upper bound of U0 transition
time. The 20ms is not enough for some devices.

Intead of polling PLS or PLC, we can facilitate the port change event to
know that the link transits to U0 is completed.

While at it, also separate U0 and U3 case to make the code cleaner.

[variable rename to u3exit, and skip completion for usb2 ports -Mathias ]
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-8-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The xHCI spec doesn't specify the upper bound of U3 transition time. For
some devices 20ms is not enough, so we need to make sure the link state
is in U3 before further actions.

I've tried to use U3 Entry Capability by setting U3 Entry Enable in
config register, however the port change event for U3 transition
interrupts the system suspend process.

For now let's use the less ideal method by polling PLS.

[use usleep_range(), and shorten the delay time while polling -Mathias]
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-7-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Tegra186 and Tegra194 xHC supports USB 3.0 LPM. This commit enables
XHCI_LPM_SUPPORT quirk for Tegra186 and Tegra194.
Signed-off-by: NJC Kuo <jckuo@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-6-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This PCIe controller chip is used on the Raspberry Pi 4 and multiple
adapter cards. There is no publicly available documentation for the
chip, yet both the downstream RPi4 kernel and the controller cards
support/advertise LPM support.
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-5-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Additional debugging to show xHC USBSTS register when stop endpoint
command watchdog triggers and host is assumed dead.

useful to know the current status before the controller is stopped by
the xhci driver and everything is released and freed.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't show the same error message for transaction errors and split
transaction errors. It's very confusing while debugging.

Transaction errors are often due to electrical interference.
Split transaction errors are about xHC not being able to
schedule start and complete split transactions needed to address
low- and full-speed devices behind high-speed hubs.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Bail out early if the xHC host needs to be reset at resume
but driver can't access xHC PCI registers.

If xhci driver already fails to reset the controller then there
is no point in attempting to free, re-initialize, re-allocate and
re-start the host. If failure to access the host is detected later,
failing the resume, xhci interrupts will be double freed
when remove is called.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200312144517.1593-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In case there are multiple Marvell EHCI blocks in system, we need a
different bus name for each one. Otherwise debugfs gets mildly upset about
a directory name in usb/ehci:

  debugfs: Directory 'mv ehci' with parent 'ehci' already present!
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200309130014.548168-2-lkundrak@v3.skSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Turns out the undocumented and reserved bits of port status/control
register of the root port need to be set to use the HCI in HSIC mode.

Typically the firmware does this, but that is not always good enough,
because the bits get lost if the HSIC clock is disabled (e.g. when
ehci-mv is build as a module).

This supplements commit 7b104f89 ("USB: EHCI: ehci-mv: add HSIC
support").
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200309130014.548168-1-lkundrak@v3.skSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When loading new kernel via kexec, we need to shutdown host controller to
avoid any un-expected memory accessing during new kernel boot.
Signed-off-by: NRan Wang <ran.wang_1@nxp.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200306092328.41253-1-ran.wang_1@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This controller timeouts during suspend (S3) with
[  240.521724] xhci_hcd 0000:30:00.3: WARN: xHC save state timeout
[  240.521729] xhci_hcd 0000:30:00.3: ERROR mismatched command completion event
thus preventing the system from entering S3.
Moreover it remains in an undefined state where some connected devices stop
working until a reboot.
Apply the XHCI_SUSPEND_DELAY quirk to make it suspend properly.

CC: stable@vger.kernel.org
Signed-off-by: NAlberto Mattea <alberto@mattea.info>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200306150858.21904-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

libtraceevent (used by perf and trace-cmd) failed to parse the
xhci_urb_dequeue trace event. This is because the user space trace
event format parsing is not a full C compiler. It can handle some basic
logic, but is not meant to be able to handle everything C can do.

In cases where a trace event field needs to be converted from a number
to a string, there's the __print_symbolic() macro that should be used:

 See samples/trace_events/trace-events-sample.h

Some xhci trace events open coded the __print_symbolic() causing the
user spaces tools to fail to parse it. This has to be replaced with
__print_symbolic() instead.

CC: stable@vger.kernel.org
Reported-by: NTzvetomir Stoyanov <tstoyanov@vmware.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206531
Fixes: 5abdc2e6 ("usb: host: xhci: add urb_enqueue/dequeue/giveback tracers")
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200306150858.21904-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200220132017.GA29262@embeddedorSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pci_driver name is const char pointer, so it not useful to cast
hcd_name (which is already const char).
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/1582054383-35760-20-git-send-email-clabbe@baylibre.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pci_driver name is const char pointer, so it not useful to cast
hcd_name (which is already const char).
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/1582054383-35760-19-git-send-email-clabbe@baylibre.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

device_driver name is const char pointer, so it not useful to cast
hcd_name (which is already const char).
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/1582054383-35760-18-git-send-email-clabbe@baylibre.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pci_driver name is const char pointer, so it not useful to cast
hcd_name (which is already const char).
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/1582054383-35760-17-git-send-email-clabbe@baylibre.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pci_driver name is const char pointer, so it not useful to cast
hcd_name (which is already const char).
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/1582054383-35760-16-git-send-email-clabbe@baylibre.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After this was made buildable for something other than PPC32, kbuild
starts warning

drivers/usb/host/fhci-hcd.c:398:8: warning: this statement may fall
through [-Wimplicit-fallthrough=]

I don't know this code, but from the construction (initializing size
with 0 and explicitly using "size +=" in the PIPE_BULK case) I assume
that fallthrough is indeed intended.
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: NLi Yang <leoyang.li@nxp.com>
Link: https://lore.kernel.org/r/20200213085401.27862-1-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sparse reports a warning at xhci_enter_test_mode()

warning: context imbalance in  xhci_enter_test_mode - unexpected unlock

The root cause is the missing annotation at xhci_enter_test_mode()
Add the missing __must_hold(&xhci->lock) annotattion
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20200214204741.94112-24-jbi.octave@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sparse reports a warning at xhci_set_port_power()

warning: context imbalance in xhci_set_port_power - unexpected unlock

The root cause is the missing annotation at xhci_set_port_power()
Add the missing __must_hold(&xhci->lock) annotattion
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20200214204741.94112-23-jbi.octave@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

libtraceevent (used by perf and trace-cmd) failed to parse the
xhci_urb_dequeue trace event. This is because the user space trace
event format parsing is not a full C compiler. It can handle some basic
logic, but is not meant to be able to handle everything C can do.

In cases where a trace event field needs to be converted from a number
to a string, there's the __print_symbolic() macro that should be used:

 See samples/trace_events/trace-events-sample.h

Some xhci trace events open coded the __print_symbolic() causing the
user spaces tools to fail to parse it. This has to be replaced with
__print_symbolic() instead.

CC: stable@vger.kernel.org
Reported-by: NTzvetomir Stoyanov <tstoyanov@vmware.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206531
Fixes: 5abdc2e6 ("usb: host: xhci: add urb_enqueue/dequeue/giveback tracers")
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lore.kernel.org/r/20200214115634.30e8ebf2@gandalf.local.homeSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci driver assumed that xHC controllers have at most one custom
supported speed table (PSI) for all usb 3.x ports.
Memory was allocated for one PSI table under the xhci hub structure.

Turns out this is not the case, some controllers have a separate
"supported protocol capability" entry with a PSI table for each port.
This means each usb3 roothub port can in theory support different custom
speeds.

To solve this, cache all supported protocol capabilities with their PSI
tables in an array, and add pointers to the xhci port structure so that
every port points to its capability entry in the array.

When creating the SuperSpeedPlus USB Device Capability BOS descriptor
for the xhci USB 3.1 roothub we for now will use only data from the
first USB 3.1 capable protocol capability entry in the array.
This could be improved later, this patch focuses resolving
the memory leak.
Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Reported-by: NSajja Venkateswara Rao <VenkateswaraRao.Sajja@amd.com>
Fixes: 47189098 ("xhci: parse xhci protocol speed ID list for usb 3.1 usage")
Cc: stable <stable@vger.kernel.org> # v4.4+
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20200211150158.14475-1-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit fc57313d.

Marek reports that it breaks things:
	This patch landed in today's linux-next (20200211) and causes
	NULL pointer dereference during second suspend/resume cycle on
	Samsung Exynos5422-based (arm 32bit) Odroid XU3lite board:

A more complete fix will be added soon.
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Fixes: fc57313d ("xhci: Fix memory leak when caching protocol extended capability PSI tables")
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Sajja Venkateswara Rao <VenkateswaraRao.Sajja@amd.com>
Cc: stable <stable@vger.kernel.org> # v4.4+
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since EHCI/OHCI controllers on R-Car Gen3 SoCs are possible to
be getting stuck very rarely after a full/low usb device was
disconnected. To detect/recover from such a situation, the controllers
require a special way which poll the EHCI PORTSC register and changes
the OHCI functional state.

So, this patch adds a polling timer into the ehci-platform driver,
and if the ehci driver detects the issue by the EHCI PORTSC register,
the ehci driver removes a companion device (= the OHCI controller)
to change the OHCI functional state to USB Reset once. And then,
the ehci driver adds the companion device again.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/1580114262-25029-1-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel Comet Lake based platform require the XHCI_PME_STUCK_QUIRK
quirk as well. Without this xHC can not enter D3 in runtime suspend.

Cc: stable@vger.kernel.org
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200210134553.9144-5-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel hosts that need the XHCI_PME_STUCK_QUIRK flag should enable
runtime pm by calling xhci_pme_acpi_rtd3_enable() before
usb_hcd_pci_probe() calls pci_dev_run_wake().
Otherwise usage count for the device won't be decreased, and runtime
suspend is prevented.

usb_hcd_pci_probe() only decreases the usage count if device can
generate run-time wake-up events, i.e. when pci_dev_run_wake()
returns true.

This issue was exposed by pci_dev_run_wake() change in
commit 8feaec33 ("PCI / PM: Always check PME wakeup capability for
runtime wakeup support")
and should be backported to kernels with that change

Cc: <stable@vger.kernel.org> # 4.13+
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200210134553.9144-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci driver assumed that xHC controllers have at most one custom
supported speed table (PSI) for all usb 3.x ports.
Memory was allocated for one PSI table under the xhci hub structure.

Turns out this is not the case, some controllers have a separate
"supported protocol capability" entry with a PSI table for each port.
This means each usb3 roothub port can in theory support different custom
speeds.

To solve this, cache all supported protocol capabilities with their PSI
tables in an array, and add pointers to the xhci port structure so that
every port points to its capability entry in the array.

When creating the SuperSpeedPlus USB Device Capability BOS descriptor
for the xhci USB 3.1 roothub we for now will use only data from the
first USB 3.1 capable protocol capability entry in the array.
This could be improved later, this patch focuses resolving
the memory leak.
Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Reported-by: NSajja Venkateswara Rao <VenkateswaraRao.Sajja@amd.com>
Fixes: 47189098 ("xhci: parse xhci protocol speed ID list for usb 3.1 usage")
Cc: stable <stable@vger.kernel.org> # v4.4+
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200210134553.9144-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A Full-speed bulk USB audio device (DJ-Tech CTRL) with a invalid Maximum
Packet Size of 4 causes a xHC "Parameter Error" at enumeration.

This is because valid Maximum packet sizes for Full-speed bulk endpoints
are 8, 16, 32 and 64 bytes. Hosts are not required to support other values
than these. See usb 2 specs section 5.8.3 for details.

The device starts working after forcing the maximum packet size to 8.
This is most likely the case with other devices as well, so force the
maximum packet size to a valid range.

Cc: stable@vger.kernel.org
Reported-by: NRene D Obermueller <cmdrrdo@gmail.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200210134553.9144-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Set the MODULE_FIRMWARE for tegra186, it's registered for 124/210 and
ensures the firmware is available at the appropriate time such as in
the initrd, else if the firmware is unavailable the driver fails with
the following errors:

tegra-xusb 3530000.usb: Direct firmware load for nvidia/tegra186/xusb.bin failed with error -2
tegra-xusb 3530000.usb: failed to request firmware: -2
tegra-xusb 3530000.usb: failed to load firmware: -2
tegra-xusb: probe of 3530000.usb failed with error -2

Fixes: 5f9be5f3 ("usb: host: xhci-tegra: Add Tegra186 XUSB support")
Signed-off-by: NPeter Robinson <pbrobinson@gmail.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200120141910.116097-1-pbrobinson@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are few stale fields in tegra_ehci_hcd structure, let's remove them.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200106013416.9604-21-digetx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no need to use usb_phy_set_suspend during of driver's probe
because now PHY driver enables hardware during of PHY's initialization.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200106013416.9604-20-digetx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I found that PHY's enable refcounting was broken and after fixing it
I also found that machine started to hang after EHCI driver module
removal. Turned out that the teardown order is incorrect because HCD must
be unregistered *before* PHY's disabling. Note that it is also not correct
to assert the shared reset during of driver's removal because PHY takes
care of resetting shared pads and thus it's better to remove that part
from the EHCI driver.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200106013416.9604-3-digetx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix up inconsistent usage of upper and lowercase letters in "Samsung"
and "Exynos" names.

"SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked
names.  Therefore they should be written with lowercase letters starting
with capital letter.

The lowercase "Exynos" name is promoted by its manufacturer Samsung
Electronics Co., Ltd., in advertisement materials and on website.

Although advertisement materials usually use uppercase "SAMSUNG", the
lowercase version is used in all legal aspects (e.g. on Wikipedia and in
privacy/legal statements on
https://www.samsung.com/semiconductor/privacy-global/).
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200104152107.11407-9-krzk@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix missing __iomem in cast to struct ehci_caps.  This fixes the Sparse
warning visible on x86_64 compile test:

   drivers/usb/host/ehci-mv.c:167:23: warning: cast removes address space '<asn:2>' of expression
   drivers/usb/host/ehci-mv.c:167:20: warning: incorrect type in assignment (different address spaces)
   drivers/usb/host/ehci-mv.c:167:20:    expected struct ehci_caps [noderef] <asn:2> *caps
   drivers/usb/host/ehci-mv.c:167:20:    got struct ehci_caps *
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200103164031.4089-1-krzk@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>