Immediate data transfers (IDT) allow the HCD to copy small chunks of
data (up to 8bytes) directly into its output transfer TRBs. This avoids
the somewhat expensive DMA mappings that are performed by default on
most URBs submissions.

In the case an URB was suitable for IDT. The data is directly copied
into the "Data Buffer Pointer" region of the TRB and the IDT flag is
set. Instead of triggering memory accesses the HC will use the data
directly.

The implementation could cover all kind of output endpoints. Yet
Isochronous endpoints are bypassed as I was unable to find one that
matched IDT's constraints. As we try to bypass the default DMA mappings
on URB buffers we'd need to find a Isochronous device with an
urb->transfer_buffer_length <= 8 bytes.

The implementation takes into account that the 8 byte buffers provided
by the URB will never cross a 64KB boundary.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
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>

It's pointless to scan the hub' i2c-bus segment if GPIOs aren't supported
by the system, since no GPIO-driven reset could be cleared by the driver
then. Moreover if CONFIG_GPIOLIB is disabled the gpio_chip structure
definition won't be available, which causes the incomplete type pointer
dereference compilation error. In order to fix this we need to create an
empty usb251x_check_gpio_chip() method returning zero, so the driver would
skip the i2c-bus segment checking and proceed with further probing in this
case.

Fixes: 6e3c8beb ("usb: usb251xb: Lock i2c-bus segment the hub resides")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This change will send an OFFLINE event to udev with the ERROR=DEAD
environment variable set when the HC dies.

By notifying user space the appropriate policies can be applied.
i.e.,
 * Collect error logs.
 * Notify the user that USB is no longer functional.
 * Perform a graceful reboot.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Latest NVIDIA GPUs support VirtualLink device. Since USBIF
has not assigned a Standard ID (SID) for VirtualLink
so using NVIDA VID 0x955 as SVID.
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

VirtualLink standard extends the DisplayPort Alt Mode by
utilizing also the USB 2 pins on the USB Type-C connector.
It uses the same messages as DisplayPort, but not the DP
SVID. At the time of writing, USB IF has not assigned a
Standard ID (SID) for VirtualLink, so the manufacturers of
VirtualLink adapters use their Vendor IDs as the SVID.

Since the SVID specific communication is exactly the same as
with DisplayPort alternate mode, there is no need to
implement separate driver for VirtualLink. We'll handle the
current VirtualLink adapters with probe drivers, and once
there is SVID assigned for it, we add it to the displayport
alt mode driver.

To support probing drivers, exporting the probe and remove
functions, and also changing the DP_HEADER helper macro to
use the SVID of the alternate mode device instead of the
DisplayPort alt mode SVID.
Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This makes it possible to bind a driver to a DisplayPort
alt mode adapter devices.

The driver attempts to cope with the limitations of UCSI by
"emulating" behaviour and attempting to guess things when
ever possible in order to satisfy the requirements the
standard DisplayPort alt mode driver has.
Tested-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

With UCSI the alternate modes, just like everything else
related to USB Type-C connectors, are handled in firmware.
The operating system can see the status and is allowed to
request certain things, for example entering and exiting the
modes, but the support for alternate modes is very limited
in UCSI. The feature is also optional, which means that even
when the platform supports alternate modes, the operating
system may not be even made aware of them.

UCSI does not support direct VDM reading or writing.
Instead, alternate modes can be entered and exited using a
single custom command which takes also an optional SVID
specific configuration value as parameter. That means every
supported alternate mode has to be handled separately in
UCSI driver.

This commit does not include support for any specific
alternate mode. The discovered alternate modes are now
registered, but binding a driver to an alternate mode will
not be possible until support for that alternate mode is
added to the UCSI driver.
Tested-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

CCGx has two copies of the firmware in addition to the bootloader.
If the device is running FW1, FW2 can be updated with the new version.
Dual firmware mode allows the CCG device to stay in a PD contract and
support USB PD and Type-C functionality while a firmware update is in
progress.

First we read the currently flashed firmware version of both
primary and secondary firmware and then compare it with
version of firmware file to determine if flashing is required.

Command framework is added to support sending commands to CCGx
controller. We wait for response after sending the command and then
read the response from RAB_RESPONSE register.

Below commands are supported,
	- ENTER_FLASHING
	- RESET
	- PDPORT_ENABLE
	- JUMP_TO_BOOT
	- FLASH_ROW_RW
	- VALIDATE_FW

Command specific mutex lock is also added to sync between driver
and user threads.

PD port number information is added which is required while sending
PD_PORT_ENABLE command
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
[ heikki: Added ABI documentation. ]
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Adding device property "ccgx,firmware-build" for the CCGx
device, so the CCGx driver knows which firmware binary to
use for a specific vendor.
Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Function is to get the details of ccg firmware and device version.
It will be useful in debugging and also during firmware update.
Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SMBus slave configuration is activated by CFG_SEL[1:0]=0x1 pins
state. This is the mode the hub is supposed to be to let this driver
work correctly. But a race condition might happen right after reset
is cleared due to CFG_SEL[0] pin being multiplexed with SMBus SCL
function. In case if the reset pin is handled by a i2c GPIO expander,
which is also placed at the same i2c-bus segment as the usb251x
SMB-interface connected to, then the hub reset clearance might
cause the CFG_SEL[0] being latched in unpredictable state. So
sometimes the hub configuration mode might be 0x1 (as expected),
but sometimes being 0x0, which doesn't imply to have the hub SMBus-slave
interface activated and consequently causes this driver failure.

In order to fix the problem we must make sure the GPIO-reset chip doesn't
reside the same i2c-bus segment as the SMBus-interface of the hub. If
it doesn't, we can safely block the segment for the time the reset is
cleared to prevent anyone generating a traffic at the i2c-bus SCL lane
connected to the CFG_SEL[0] pin. But if it does, nothing we can do, so
just return an error. If we locked the i2c-bus segment and tried to
communicate with the GPIO-expander, it would cause a deadlock. If we didn't
lock the i2c-bus segment, it would randomly cause the CFG_SEL[0] bit flip.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Keep EXTCON support optional, as some platforms do not need it.

Do the same for USB_DWC3_OMAP while we're at it.

Fixes: 3def4031 ("usb: dwc3: add EXTCON dependency for qcom")
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is an extra space character before the return statement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'phy-for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next

Kishon writes:

phy: for 5.2

  *) Add a new *release* phy_ops invoked when the consumer relinquishes PHY
     that can be used to undo the operation performed in xlate
  *) Add new driver to support USB2 PHY and shared USB3 + PCIE PHY in Amlogic
     G12A SoC Family.
  *) Add new driver to support for Broadcom's Stingray USB PHY (Type 1 has
     one super speed PHY and one high speed PHY, Type 2 has one high speed PHY)
  *) Add new driver to support USB PHY in hi3660 SoC of Hisilicon
  *) Add new driver to support UFS M-PHY in MediaTek SoC
  *) Add new driver to support XUSB pad controller in Tegra186 SoCs
  *) Add new driver to support SERDES in TI's AM654 platform
  *) Add support for generation 2 USB2 PHY and gneration 3 USB2 PHY in r8a77470
     to phy-rcar-gen2.c and phy-rcar-gen3-usb2.c respectively
  *) Add support for PCIe QMP PHY support in msm8998 to phy-qcom-qmp.c
  *) Add support for SERDES6G in phy-ocelot-serdes.c
  *) Add support to set drive impedance from device tree in phy-rockchip-emmc.c
  *) Add support to power up/down the VBUS voltage rail in phy-fsl-imx8mq-usb.c
  *) Add support to shut off regulators that power UFS during system suspend
  *) Re-design phy-rcar-gen3-usb2.c to create separate PHY instances for each
     channel which helps to enable/disable interrupts for each instance
     independently
  *) Fix PCIe power up sequence to follow the TRM in order to ensure the DPLL &
     PHY operates correctly over the entire temperature range.
  *) Use devm_clk_get_optional to get optional clocks instead of adding
     custom error checks
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

* tag 'phy-for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy: (51 commits)
  dt-bindings: phy-qcom-qmp: Tweak qcom,msm8998-qmp-ufs-phy
  dt-bindings: phy-qcom-qmp: Add qcom,msm8998-qmp-pcie-phy
  phy: Add usb phy support for hi3660 Soc of Hisilicon
  dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY
  scsi: phy: mediatek: fix typo in author's email address
  phy: ocelot-serdes: Add support for SERDES6G muxing
  phy: fsl-imx8mq-usb: add support for VBUS power control
  dt-bindings: phy-imx8mq-usb: add optional vbus supply regulator
  phy: qcom-qmp: Add msm8998 PCIe QMP PHY support
  phy: ti: am654-serdes: Support all clksel values
  phy: ti: Add a new SERDES driver for TI's AM654x SoC
  dt-bindings: phy: ti: Add dt binding documentation for SERDES in AM654x SoC
  phy: core: Invoke pm_runtime_get_*/pm_runtime_put_* before invoking reset callback
  phy: core: Add *release* phy_ops invoked when the consumer relinquishes PHY
  phy: phy-meson-gxl-usb2: get optional clock by devm_clk_get_optional()
  phy: socionext: get optional clock by devm_clk_get_optional()
  phy: qcom-qusb2: get optional clock by devm_clk_get_optional()
  phy: phy-mtk-tphy: get optional clock by devm_clk_get_optional()
  phy: renesas: rcar-gen3-usb2: enable/disable independent irqs
  phy: renesas: rcar-gen3-usb2: Use pdev's device pointer on dev_vdbg()
  ...

Fixup MSM8998 UFS binding now that Evan's reset series has landed.
https://lore.kernel.org/lkml/20190321171800.104681-1-evgreen@chromium.org/Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Use devm_clk_get_optional() to get optional clock instead of
optional_clk_get() which uses devm_clk_get() to get clock and
checks for -EPROBE_DEFER but not -ENOENT as devm_clk_get_optional()
does, in fact, only ignoring -ENOENT will cover more errors, so
the replacement doesn't change original purpose.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When the driver tries to get optional clock, it ignores all errors except
-EPROBE_DEFER, but if only ignores -ENOENT, it will cover some real errors,
such as -ENOMEM, so use devm_clk_get_optional() to get optional clock.

Cc: Peter Chen <Peter.Chen@nxp.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Peter Chen <Peter.Chen@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When the driver tries to get optional clock, it ignores all errors,
but if only ignores -ENOENT, it will cover some real errors, such as
-EPROBE_DEFER, so use devm_clk_get_optional() to get optional clock.

Cc: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When the driver tries to get optional clock, it ignores all errors except
-EPROBE_DEFER, but if only ignores -ENOENT, it will cover some real errors,
such as -ENOMEM, so use devm_clk_get_optional() to get optional clock.
And remove unnecessary stack variable clk.

Cc: Dongjin Kim <tobetter@gmail.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When the driver tries to get optional clock, it ignores all errors except
-EPROBE_DEFER, but if only ignores -ENOENT, it will cover some real errors,
such as -ENOMEM, so use devm_clk_get_optional() to get optional clock.

Cc: Mathias Nyman <mathias.nyman@intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_clk_get_optional() to get optional clock instead of
optional_clk_get() which uses devm_clk_get() to get clock and
checks for -EPROBE_DEFER but not -ENOENT as devm_clk_get_optional()
does, in fact, only ignoring -ENOENT will cover more errors, so the
replacement doesn't change original purpose.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some tcpc device-drivers need to explicitly be told to watch for connection
events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
being plugged into the Type-C port will not be noticed.

For dual-role ports tcpm_start_drp_toggling() is used to tell the tcpc to
watch for connection events. But for single-role ports we've so far been
falling back to just calling tcpm_set_cc(). For some tcpc-s such as the
fusb302 this is not enough and no TCPM_CC_EVENT will be generated.

Commit ea3b4d55 ("usb: typec: fusb302: Resolve fixed power role
contract setup") fixed SRPs not working because of this by making the
fusb302 driver start connection detection on every tcpm_set_cc() call.
It turns out this breaks src->snk power-role swapping because during the
swap we first set the Cc pins to Rp, calling set_cc, and then send a PS_RDY
message. But the fusb302 cannot send PD messages while its toggling engine
is active, so sending the PS_RDY message fails.

Struct tcpc_dev now has a new start_srp_connection_detect callback and
fusb302.c now implements this. This callback gets called when we the
fusb302 needs to start connection detection, fixing fusb302 SRPs not
seeing connected devices.

This allows us to revert the changes to fusb302's set_cc implementation,
making it once again purely setup the Cc-s and matching disconnect
detection, fixing src->snk power-role swapping no longer working.

Note that since the code was refactored in between, codewise this is not a
straight forward revert. Functionality wise this is a straight revert and
the original functionality is fully restored.

Fixes: ea3b4d55 ("usb: typec: fusb302: Resolve fixed power role ...")
Cc: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When in single-role port mode, we must start single-role toggling to
get an interrupt when a device / cable gets plugged into the port.

This commit modifies the fusb302 start_toggling implementation to
start toggling for all port-types, so that connection-detection works
on single-role ports too.

Fixes: ea3b4d55("usb: typec: fusb302: Resolve fixed power role ...")
Cc: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some tcpc device-drivers need to explicitly be told to watch for connection
events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
being plugged into the Type-C port will not be noticed.

For dual-role ports tcpm_start_drp_toggling() is used to tell the tcpc to
watch for connection events. Sofar we lack a similar callback to the tcpc
for single-role ports. With some tcpc-s such as the fusb302 this means
no TCPM_CC_EVENTs will be generated when the port is configured as a
single-role port.

This commit renames start_drp_toggling to start_toggling and since the
device-properties are parsed by the tcpm-core, adds a port_type parameter
to the start_toggling callback so that the tcpc_dev driver knows the
port-type and can act accordingly when it starts toggling.

The new start_toggling callback now always gets called if defined, instead
of only being called for DRP ports.

To avoid this causing undesirable functional changes all existing
start_drp_toggling implementations are not only renamed to start_toggling,
but also get a port_type check added and return -EOPNOTSUPP when port_type
is not DRP.

Fixes: ea3b4d55("usb: typec: fusb302: Resolve fixed power role ...")
Cc: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fhci_queue_urb() shouldn't use urb->pipe to compute the maxpacket
size anyway.It should use usb_endpoint_maxp(&urb->ep->desc).
Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add compatible string for QMP PCIe phy on msm8998.
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

This driver handles usb phy power on and shutdown for hi3660 Soc of
Hisilicon.

Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Pengcheng Li <lpc.li@hisilicon.com>
Cc: Jianguo Sun <sunjianguo1@huawei.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jiancheng Xue <xuejiancheng@hisilicon.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Binghui Wang <wangbinghui@hisilicon.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Yu Chen <chenyu56@huawei.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

This patch adds binding documentation for supporting the hi3660 usb
phy on boards like the HiKey960.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Binghui Wang <wangbinghui@hisilicon.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Yu Chen <chenyu56@huawei.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

There is a typo in the module author's email address. Fix this.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Adding support for SERDES6G muxing required for QSGMII mode of operation.
Signed-off-by: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com>
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
Signed-off-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Co-developed-by: Quentin Schulz <quentin.schulz@bootlin.com>
Co-developed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

This adds support to the PHY driver to power up/down the VBUS
voltage rail at the appropriate times.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Add a vbus supply regulator phandle, so the PHY can enable the VBUS
voltage rail when powering up.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

The SCSI core does not like to have devices or hosts unregistered
while error recovery is in progress.  Trying to do so can lead to
self-deadlock: Part of the removal code tries to obtain a lock already
held by the error handler.

This can cause problems for the usb-storage and uas drivers, because
their error handler routines perform a USB reset, and if the reset
fails then the USB core automatically goes on to unbind all drivers
from the device's interfaces -- all while still in the context of the
SCSI error handler.

As it turns out, practically all the scenarios leading to a USB reset
failure end up causing a device disconnect (the main error pathway in
usb_reset_and_verify_device(), at the end of the routine, calls
hub_port_logical_disconnect() before returning).  As a result, the
hub_wq thread will soon become aware of the problem and will unbind
all the device's drivers in its own context, not in the
error-handler's context.

This means that usb_reset_device() does not need to call
usb_unbind_and_rebind_marked_interfaces() in cases where
usb_reset_and_verify_device() has returned an error, because hub_wq
will take care of everything anyway.

This particular problem was observed in somewhat artificial
circumstances, by using usbfs to tell a hub to power-down a port
connected to a USB-3 mass storage device using the UAS protocol.  With
the port turned off, the currently executing command timed out and the
error handler started running.  The USB reset naturally failed,
because the hub port was off, and the error handler deadlocked as
described above.  Not carrying out the call to
usb_unbind_and_rebind_marked_interfaces() fixes this issue.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Kento Kobayashi <Kento.A.Kobayashi@sony.com>
Tested-by: Kento Kobayashi <Kento.A.Kobayashi@sony.com>
CC: Bart Van Assche <bvanassche@acm.org>
CC: Martin K. Petersen <martin.petersen@oracle.com>
CC: Jacky Cao <Jacky.Cao@sony.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation for this PHY, and the proper configuration settings,
is *not* publicly available. Therefore the initialization sequence
is copied wholesale from downstream:

https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/msm8998-v2.dtsi?h=LE.UM.1.3.r3.25#n372Reviewed-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Add support to select all 16 CLKSEL combinations that are shown in
"SerDes Reference Clock Distribution" in AM65 TRM.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Add a new SERDES driver for TI's AM654x SoC which configures
the SERDES only for PCIe. Support fo USB3 will be added later.

SERDES in am654x has three input clocks (left input, externel reference
clock and right input) and two output clocks (left output and right
output) in addition to a PLL mux clock which the SERDES uses for Clock
Multiplier Unit (CMU refclock).

The PLL mux clock can select from one of the three input clocks.
The right output can select between left input and external reference
clock while the left output can select between the right input and
external reference clock.

The driver has support to select PLL mux and left/right output mux as
specified in device tree.

[rogerq@ti.com: Fix boot lockup caused by accessing a structure member
(hw->init) allocated in stack of probe() and accessed in get_parent]
[rogerq@ti.com: Fix "Failed to find the parent" warnings]
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

AM654x has two SERDES instances. Each instance has three input clocks
(left input, externel reference clock and right input) and two output
clocks (left output and right output) in addition to a PLL mux clock
which the SERDES uses for Clock Multiplier Unit (CMU refclock).
The PLL mux clock can select from one of the three input clocks.
The right output can select between left input and external reference
clock while the left output can select between the right input and
external reference clock.

The left and right input reference clock of SERDES0 and SERDES1
respectively are connected to the SoC clock. In the case of two lane
SERDES personality card, the left input of SERDES1 is connected to
the right output of SERDES0 in a chained fashion.

See section "Reference Clock Distribution" of AM65x Sitara Processors
TRM (SPRUID7 – April 2018) for more details.

Add dt-binding documentation in order to represent all these different
configurations in device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

PHY drivers may try to access PHY registers in the ->reset() callback.
Invoke phy_pm_runtime_get_sync() before invoking the ->reset() callback
so that the PHY drivers don't have to enable clocks by themselves before
accessing PHY registers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Add a new phy_ops *release* invoked when the consumer relinquishes the
PHY using phy_put/devm_phy_put. The initializations done by the PHY
driver in of_xlate call back can be can be cleaned up here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Use devm_clk_get_optional() to get optional clock

Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>