With CPU re-ordering on write instructions, there might
be a chance that the HWO is set before the TRB is updated
with the new mapped buffer address.
And in the case where core is processing a list of TRBs
it is possible that it fetched the TRBs when the HWO is set
but before the buffer address is updated.
Prevent this by adding a memory barrier before the HWO
is updated to ensure that the core always process the
updated TRBs.

Fixes: f6bafc6a ("usb: dwc3: convert TRBs into bitshifts")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: NPavankumar Kondeti <quic_pkondeti@quicinc.com>
Signed-off-by: NUdipto Goswami <quic_ugoswami@quicinc.com>
Link: https://lore.kernel.org/r/1644207958-18287-1-git-send-email-quic_ugoswami@quicinc.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A previous patch to skip part of the initialization when a USB3 PHY was
not present could result in the return value being uninitialized in that
case, causing spurious probe failures. Initialize ret to 0 to avoid this.

Fixes: 9678f336 ("usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0 mode")
Cc: <stable@vger.kernel.org>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NRobert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20220127221500.177021-1-robert.hancock@calian.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The code that looked up the USB3 PHY was ignoring all errors other than
EPROBE_DEFER in an attempt to handle the PHY not being present. Fix and
simplify the code by using devm_phy_optional_get and dev_err_probe so
that a missing PHY is not treated as an error and unexpected errors
are handled properly.

Fixes: 84770f02 ("usb: dwc3: Add driver for Xilinx platforms")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NRobert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20220126000253.1586760-3-robert.hancock@calian.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It appears that the PIPE clock should not be selected when only USB 2.0
is being used in the design and no USB 3.0 reference clock is used.
Also, the core resets are not required if a USB3 PHY is not in use, and
will break things if USB3 is actually used but the PHY entry is not
listed in the device tree.

Skip core resets and register settings that are only required for
USB3 mode when no USB3 PHY is specified in the device tree.

Fixes: 84770f02 ("usb: dwc3: Add driver for Xilinx platforms")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NRobert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20220126000253.1586760-2-robert.hancock@calian.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since the acpi_create_platform_device() function may return error
pointers, dwc3_qcom_create_urs_usb_platdev() function may return error
pointers too. Using IS_ERR_OR_NULL() to check the return value to fix this.

Fixes: c25c210f ("usb: dwc3: qcom: add URS Host support for sdm845 ACPI boot")
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20211222111823.22887-1-linmq006@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the missing platform_device_put() before return from
dwc3_qcom_acpi_register_core in the error handling case.
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20211231113641.31474-1-linmq006@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Drop unneeded calls to platform_get_resource_byname() from
dwc3_host_init(). dwc3_host_init() already calls dwc3_host_get_irq()
which gets the irq number, just use this to get the IRQ resource data
and fill the xhci_resources[1]
Reviewed-by: NRoger Quadros <rogerq@kernel.org>
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20211220010411.12075-4-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Synopsys introduced a new enhancement to DWC_usb32 called Multi-Stream
Transfer (MST) to improve bulk streams performance for SuperSpeed and
SuperSpeed Plus. This enhancement allows the controller to look ahead
and process multiple bulk streams.

Previously, to initiate a bulk stream transfer, the driver has to issue
Start Transfer command and wait for the stream to complete before
initiating a new stream. As a result, the controller does not process
TRBs beyond a single stream. With the enhancement, as long as there are
new requests, the dwc3 driver can keep preparing new TRBs and the
controller can keep caching and processing them without waiting for the
transfer completion.

The programming flow is similar to regular bulk endpoint with a few
additional rules:

1) Chained TRBs of the same stream must have a matching stream ID
2) The last TRB of a stream must have CHN=0
3) All the TRBs with LST=0 must have CSP=1

Depends on the application and usage, internal tests show significant
performance improvement in UASP transfers with this enhancement.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/cd9c7a8bf11f790983ac546222dd114893f16b3a.1638242424.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit cefdd52f.

On sc7180-trogdor class devices with 'fw_devlink=permissive' and KASAN
enabled, you'll see a Use-After-Free reported at bootup.

The root of the problem is that dwc3_qcom_of_register_core() is adding
a devm-allocated "tx-fifo-resize" property to its device tree node
using of_add_property().

The issue is that of_add_property() makes a _permanent_ addition to
the device tree that lasts until reboot. That means allocating memory
for the property using "devm" managed memory is a terrible idea since
that memory will be freed upon probe deferral or device unbinding.

Let's revert the patch since the system is still functional without
it. The fact that of_add_property() makes a permanent change is extra
fodder for those folks who were aruging that the device tree isn't
really the right way to pass information between parts of the
driver. It is an exercise left to the reader to submit a patch
re-adding the new feature in a way that makes everyone happier.

Fixes: cefdd52f ("usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20211207094327.1.Ie3cde3443039342e2963262a4c3ac36dc2c08b30@changeidSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver knows what it needs to set for GEVNTSIZn, and the controller
doesn't modify this register unless there's a hard reset. To save a few
microseconds of register read in read-modify-write operation, simply do
register write with the expected values. This can improve performance
when there are many interrupts generated, which the driver needs to
check and handle.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/efddf4ee5821c4bc5ae7ad90d629ec7a0ebcbf9a.1638240306.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The controller doesn't check for Update Transfer command parameters
DEPCMDPAR{0,1,2}. Writing to these registers is unnecessary. Ignoring
this improves performance slightly by removing the register write
delay.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/997d9ebf38c6bba920d4ee77bd8c77bf81978a55.1638240306.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we're not setting CMDACT (from "No Response" Update Transfer
command), then there's no point in checking for the command status. So
skip it. This can reduce a register read delay and improve performance.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/3dc31cf11581ae3ee82d9202dda3fc17d897d786.1638240306.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

in case of a PCI dwc3 controller, leave the default DMA
mask. Calling of a 64 bit DMA mask breaks the driver on
cherrytrail based tablets like Cyberbook T116.

Fixes: 45d39448 ("usb: dwc3: support 64 bit DMA in platform driver")
Cc: stable <stable@vger.kernel.org>
Reported-by: NHans De Goede <hdegoede@redhat.com>
Tested-by: NFabio Aiuto <fabioaiuto83@gmail.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NFabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/20211113142959.27191-1-fabioaiuto83@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the endpoint interrupt functions
dwc3_gadget_endpoint_transfer_in_progress() and
dwc3_gadget_endpoint_trbs_complete() will dereference the endpoint
descriptor. But it could be cleared in __dwc3_gadget_ep_disable()
when accessory disconnected. So we need to check whether it is null
or not before dereferencing it.

Fixes: f09ddcfc ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: NJack Pham <quic_jackp@quicinc.com>
Signed-off-by: NAlbert Wang <albertccwang@google.com>
Link: https://lore.kernel.org/r/20211109092642.3507692-1-albertccwang@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The programming guide noted that the driver needs to verify if the link
state is in U0 before executing the Start Transfer command. If it's not
in U0, the driver needs to perform remote wakeup. This is not accurate.
If the link state is in U1/U2, then the controller will not respond to
link recovery request from DCTL.ULSTCHNGREQ. The Start Transfer command
will trigger a link recovery if it is in U1/U2. A clarification will be
added to the programming guide for all controller versions.

The current implementation shouldn't cause any functional issue. It may
occasionally report an invalid time out warning from failed link
recovery request. The driver will still go ahead with the Start Transfer
command if the remote wakeup fails. The new change only initiates remote
wakeup where it is needed, which is when the link state is in L1/L2/U3.

Fixes: c36d8e94 ("usb: dwc3: gadget: put link to U0 before Start Transfer")
Cc: <stable@vger.kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/05b4a5fbfbd0863fc9b1d7af934a366219e3d0b4.1635204761.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The End Transfer command from a stream endpoint will generate a NoStream
event, and we should ignore it. Currently we set the flag
DWC3_EP_IGNORE_NEXT_NOSTREAM to track this prior to sending the command,
and it will be cleared on the next stream event. However, a stream event
may be generated before the End Transfer command completion and
prematurely clear the flag. Fix this by setting the flag on End Transfer
completion instead.

Fixes: 140ca4cf ("usb: dwc3: gadget: Handle stream transfers")
Cc: <stable@vger.kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/cee1253af4c3600edb878d11c9c08b040817ae23.1635203975.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During our predesign phase for DWC_usb32, the GHWPARAMS9 register offset
was 0xc680. We revised our final design, and the GHWPARAMS9 offset is
now moved to 0xc6e8 on release.

Fixes: 16710380 ("usb: dwc3: Capture new capability register GHWPARAMS9")
Cc: <stable@vger.kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1541737108266a97208ff827805be1f32852590c.1635202893.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

reset_control_(de)assert() calls are called on a shared reset line when
reset_control_reset has been used. This is not allowed by the reset
framework.

Use reset_control_rearm() call in suspend() and remove() as a way to state
that the resource is no longer used, hence the shared reset line
may be triggered again by other devices. Use reset_control_rearm() also in
case probe fails after reset() has been called.

reset_control_rearm() keeps use of triggered_count sane in the reset
framework, use of reset_control_reset() on shared reset line should be
balanced with reset_control_rearm().
Signed-off-by: NAmjad Ouled-Ameur <aouledameur@baylibre.com>
Reported-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20211112162827.128319-3-aouledameur@baylibre.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix the DWC3_EP_* flag macros so that the definitions are all
lined up on the same tab column for consistent style.

No functional change.
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20211021180129.27938-2-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some functions may dynamically enable and disable their endpoints
regularly throughout their operation, particularly when Set Interface
is employed to switch between Alternate Settings.  For instance the
UAC2 function has its respective endpoints for playback & capture
associated with AltSetting 1, in which case those endpoints would not
get enabled until the host activates the AltSetting.  And they
conversely become disabled when the interfaces' AltSetting 0 is
chosen.

With the DWC3 FIFO resizing algorithm recently added, every
usb_ep_enable() call results in a call to resize that EP's TXFIFO,
but if the same endpoint is enabled again and again, this incorrectly
leads to FIFO RAM allocation exhaustion as the mechanism did not
account for the possibility that endpoints can be re-enabled many
times.

Example log splat:

	dwc3 a600000.dwc3: Fifosize(3717) > RAM size(3462) ep3in depth:217973127
	configfs-gadget gadget: u_audio_start_capture:521 Error!
	dwc3 a600000.dwc3: request 000000000be13e18 was not queued to ep3in

Add another bit DWC3_EP_TXFIFO_RESIZED to dep->flags to keep track of
whether an EP had already been resized in the current configuration.
If so, bail out of dwc3_gadget_resize_tx_fifos() to avoid the
calculation error resulting from accumulating the EP's FIFO depth
repeatedly.  This flag is retained across multiple ep_disable() and
ep_enable() calls and is cleared when GTXFIFOSIZn is reset in
dwc3_gadget_clear_tx_fifos() upon receiving the next Set Config.

Fixes: 9f607a30 ("usb: dwc3: Resize TX FIFOs to meet EP bursting requirements")
Reviewed-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20211021180129.27938-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since function drivers will still be active until dwc3_disconnect_gadget()
is called, some applications will continue to queue packets to DWC3
gadget.  This can lead to a flood of messages regarding failed ep queue,
as the endpoint is in the process of being disabled.  Change the log
level to debug, so that it can be enabled when debugging issues.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20211018192647.32121-1-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit c6e23b89 ("usb: dwc3: gadget: set gadgets parent to the right
controller") changed the device for the UDC and broke the user space scripts
that instantiate the USB gadget(s) via ConfigFS.

Revert it for now until the better solution will be proposed.

Fixes: c6e23b89 ("usb: dwc3: gadget: set gadgets parent to the right controller")
Tested-by: NFerry Toth <fntoth@gmail.com>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Cc: Felipe Balbi <balbi@kernel.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211004141839.49079-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Describe better which driver applies to which SoC, to make configuring
kernel for Samsung SoC easier.
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210924133005.111564-1-krzysztof.kozlowski@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a race present where the DWC3 runtime resume runs in parallel
to the UDC unbind sequence.  This will eventually lead to a possible
scenario where we are enabling the run/stop bit, without a valid
composition defined.

Thread#1 (handling UDC unbind):
usb_gadget_remove_driver()
-->usb_gadget_disconnect()
  -->dwc3_gadget_pullup(0)
--> continue UDC unbind sequence
-->Thread#2 is running in parallel here

Thread#2 (handing next cable connect)
__dwc3_set_mode()
  -->pm_runtime_get_sync()
    -->dwc3_gadget_resume()
      -->dwc->gadget_driver is NOT NULL yet
      -->dwc3_gadget_run_stop(1)
      --> _dwc3gadget_start()
...

Fix this by tracking the pullup disable routine, and avoiding resuming
of the DWC3 gadget.  Once the UDC is re-binded, that will trigger the
pullup enable routine, which would handle enabling the DWC3 gadget.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20210917021852.2037-1-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After we start to do core soft reset while usb role switch,
the phy init is invoked at every switch to device mode, but
its counter part de-init is missing, this causes the actual
phy init can not be done when we really want to re-init phy
like system resume, because the counter maintained by phy
core is not 0. considering phy init is actually redundant for
role switch, so move out the phy init from core soft reset to
dwc3 core init where is the only place required.

Fixes: f88359e1 ("usb: dwc3: core: Do core softreset when switch mode")
Cc: <stable@vger.kernel.org>
Tested-by: Nfaqiang.zhu <faqiang.zhu@nxp.com>
Tested-by: John Stultz <john.stultz@linaro.org> #HiKey960
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NLi Jun <jun.li@nxp.com>
Link: https://lore.kernel.org/r/1631068099-13559-1-git-send-email-jun.li@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Set reference clock period when it differs from dwc3 default hardware
set.

We could calculate clock period based on reference clock frequency. But
this information is not always available. This is the case of PCI bus
attached USB host. For that reason we use a custom property.

Tested (USB2 only) on IPQ6010 SoC based board with 24 MHz reference
clock while hardware default is 19.2 MHz.

[ baruch: rewrite commit message; drop GFLADJ code; remove 'quirk-' from
  property name; mention tested hardware ]
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NBalaji Prakash J <bjagadee@codeaurora.org>
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Nacked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/9f399bdf1ff752e31ab7497e3d5ce19bbb3ff247.1630389452.git.baruch@tkos.co.ilSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During a USB cable disconnect, or soft disconnect scenario, a pending
SETUP transaction may not be completed, leading to the following
error:

    dwc3 a600000.dwc3: timed out waiting for SETUP phase

If this occurs, then the entire pullup disable routine is skipped and
proper cleanup and halting of the controller does not complete.

Instead of returning an error (which is ignored from the UDC
perspective), allow the pullup disable routine to continue, which
will also handle disabling of EP0/1.  This will end any active
transfers as well.  Ensure to clear any delayed_status also, as the
timeout could happen within the STATUS stage.

Fixes: bb014736 ("usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to do so")
Cc: <stable@vger.kernel.org>
Reviewed-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20210825042855.7977-1-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We can't depend on the TRB's HWO bit to determine if the TRB ring is
"full". A TRB is only available when the driver had processed it, not
when the controller consumed and relinquished the TRB's ownership to the
driver. Otherwise, the driver may overwrite unprocessed TRBs. This can
happen when many transfer events accumulate and the system is slow to
process them and/or when there are too many small requests.

If a request is in the started_list, that means there is one or more
unprocessed TRBs remained. Check this instead of the TRB's HWO bit
whether the TRB ring is full.

Fixes: c4233573 ("usb: dwc3: gadget: prepare TRBs on update transfers too")
Cc: <stable@vger.kernel.org>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/e91e975affb0d0d02770686afc3a5b9eb84409f6.1629335416.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

AMD's latest platforms has DWC3 controller. Add the PCI ID and
properties for the same.
Signed-off-by: NNehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Link: https://lore.kernel.org/r/20210823184449.2796184-2-Nehal-Bakulchandra.shah@amd.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If IRQ occurs between calling  devm_request_threaded_irq() and
initializing dwc3_imx->dwc3, then null pointer dereference occurs
since dwc3_imx->dwc3 is used in dwc3_imx8mp_interrupt().

The patch puts registration of the interrupt handler after
initializing of neccesery data.

Found by Linux Driver Verification project (linuxtesting.org).
Reviewed-by: NFabio Estevam <festevam@gmail.com>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NNadezda Lutovinova <lutovinova@ispras.ru>
Link: https://lore.kernel.org/r/20210819154818.18334-1-lutovinova@ispras.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On DWC_usb3 revisions 3.00a and newer (including DWC_usb31 and
DWC_usb32) the GUCTL1 register gained the DEV_DECOUPLE_L1L2_EVT
field (bit 31) which when enabled allows the controller in device
mode to treat USB 2.0 L1 LPM & L2 events separately.

After commit d1d90dd2 ("usb: dwc3: gadget: Enable suspend
events") the controller will now receive events (and therefore
interrupts) for every state change when entering/exiting either
L1 or L2 states.  Since L1 is handled entirely by the hardware
and requires no software intervention, there is no need to even
enable these events and unnecessarily notify the gadget driver.
Enable the aforementioned bit to help reduce the overall interrupt
count for these L1 events that don't need to be handled while
retaining the events for full L2 suspend/wakeup.
Tested-by: NJun Li <jun.li@nxp.com>
Tested-by: Amit Pundir <amit.pundir@linaro.org> # for RB5 (sm8250)
Tested-by: John Stultz <john.stultz@linaro.org> # for HiKey960 & db845c
Reviewed-by: NJun Li <jun.li@nxp.com>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Link: https://lore.kernel.org/r/20210812082635.12924-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In dwc3_qcom_acpi_register_core(), the driver neglects to check the result
of platform_get_irq()'s call and blithely assigns the negative error codes
to the allocated child device's IRQ resource and then passing this resource
to platform_device_add_resources() and later causing dwc3_otg_get_irq() to
fail anyway.  Stop calling platform_device_add_resources() with the invalid
IRQ #s, so that there's less complexity in the IRQ error checking.

Fixes: 2bc02355 ("usb: dwc3: qcom: Add support for booting with ACPI")
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NSergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/45fec3da-1679-5bfe-5d74-219ca3fb28e7@omp.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.

Fixes: f90db107 ("usb: dwc3: meson-g12a: Add support for IRQ based OTG switching")
Reviewed-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NSergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/96106462-5538-0b2f-f2ab-ee56e4853912@omp.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit d25d8506 as it is
reported to cause problems on many different types of boards.
Reported-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Reported-by: NJohn Stultz <john.stultz@linaro.org>
Cc: Ray Chi <raychi@google.com>
Link: https://lore.kernel.org/r/CANcMJZCEVxVLyFgLwK98hqBEdc0_n4P0x_K6Gih8zNH3ouzbJQ@mail.gmail.com
Fixes: d25d8506 ("usb: dwc3: gadget: Use list_replace_init() before traversing lists")
Cc: stable <stable@vger.kernel.org>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Wesley Cheng <wcheng@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the device is already in the runtime suspended state, any call to
the pullup routine will issue a runtime resume on the DWC3 core
device.  If the USB gadget is disabling the pullup, then avoid having
to issue a runtime resume, as DWC3 gadget has already been
halted/stopped.

This fixes an issue where the following condition occurs:

usb_gadget_remove_driver()
-->usb_gadget_disconnect()
 -->dwc3_gadget_pullup(0)
  -->pm_runtime_get_sync() -> ret = 0
  -->pm_runtime_put() [async]
-->usb_gadget_udc_stop()
 -->dwc3_gadget_stop()
  -->dwc->gadget_driver = NULL
...

dwc3_suspend_common()
-->dwc3_gadget_suspend()
 -->DWC3 halt/stop routine skipped, driver_data == NULL

This leads to a situation where the DWC3 gadget is not properly
stopped, as the runtime resume would have re-enabled EP0 and event
interrupts, and since we avoided the DWC3 gadget suspend, these
resources were never disabled.

Fixes: 77adb8bd ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@vger.kernel.org>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1628058245-30692-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The list_for_each_entry_safe() macro saves the current item (n) and
the item after (n+1), so that n can be safely removed without
corrupting the list.  However, when traversing the list and removing
items using gadget giveback, the DWC3 lock is briefly released,
allowing other routines to execute.  There is a situation where, while
items are being removed from the cancelled_list using
dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable
routine is running in parallel (due to UDC unbind).  As the cleanup
routine removes n, and the pullup disable removes n+1, once the
cleanup retakes the DWC3 lock, it references a request who was already
removed/handled.  With list debug enabled, this leads to a panic.
Ensure all instances of the macro are replaced where gadget giveback
is used.

Example call stack:

Thread#1:
__dwc3_gadget_ep_set_halt() - CLEAR HALT
  -> dwc3_gadget_ep_cleanup_cancelled_requests()
    ->list_for_each_entry_safe()
    ->dwc3_gadget_giveback(n)
      ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]
      ->spin_unlock
      ->Thread#2 executes
      ...
    ->dwc3_gadget_giveback(n+1)
      ->Already removed!

Thread#2:
dwc3_gadget_pullup()
  ->waiting for dwc3 spin_lock
  ...
  ->Thread#1 released lock
  ->dwc3_stop_active_transfers()
    ->dwc3_remove_requests()
      ->fetches n+1 item from cancelled_list (n removed by Thread#1)
      ->dwc3_gadget_giveback()
        ->dwc3_gadget_del_and_unmap_request()- n+1
deleted[cancelled_list]
        ->spin_unlock

Fix this condition by utilizing list_replace_init(), and traversing
through a local copy of the current elements in the endpoint lists.
This will also set the parent list as empty, so if another thread is
also looping through the list, it will be empty on the next iteration.

Fixes: d4f1afe5 ("usb: dwc3: gadget: move requests to cancelled_list")
Cc: stable <stable@vger.kernel.org>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1627543994-20327-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a new compatible for SDM660's DWC3.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210728221921.52068-1-konrad.dybcio@somainline.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In case of dwc3 it is possible that the sysdev is the parent of the
controller. To ensure the right dev is set to the gadget's dev parent we
will hand over sysdev instead of dev, which will always point to the
controller.
Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20210628155311.16762-2-m.grzeschik@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the new helper usb_get_role_switch_default_mode() to
get property of "role-switch-default-mode"
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1626340078-29111-7-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There was an extra character in the dwc3_qcom_vbus_override_enable()
function.  Removed the extra character.
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210704013314.200951-2-bryan.odonoghue@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>