If kick transfer command fail and the return value isn't
EAGAIN, the current code will issue end transfer command
to stop the active transfer, and only set dep->flags with
DWC3_EP_END_TRANSFER_PENDING if the end transfer command
is done successfully. If the DWC3_EP_END_TRANSFER_PENDING
isn't set, it cleanup the cancelled requests and give the
request back to the gadget layer immediately.
For uvc gadget, the uvc gadget driver hold spinlock and
then call usb_ep_queue() to submit uvc usb request to dwc3
controller. The dwc3 controller may kick transfer for the
request sequentially, if the kick transfer command and
the end transfer command all failed, the dwc3 will give
the request back to the uvc gadget driver via the request
complete function uvc_video_complete(), in this function,
it try to get the spinlock again that lead to deadlock.
This case always happens with the following warning log:
WARNING: CPU: 0 PID: 14450 at drivers/usb/dwc3/gadget.c:1839 __dwc3_gadget_kick_transfer+0x3a0/0x3b0
...
Workqueue: events uvcg_video_pump
...
Call trace:
__dwc3_gadget_kick_transfer+0x3a0/0x3b0
__dwc3_gadget_ep_queue+0x128/0x1f0
dwc3_gadget_ep_queue+0x40/0x6c
usb_ep_queue+0x44/0x100
uvcg_video_pump+0xd0/0x1d4
process_one_work+0x1f4/0x490
worker_thread+0x278/0x4dc
kthread+0x13c/0x344
ret_from_fork+0x10/0x30
Fixes: 0ec00e864a ("UPSTREAM: usb: dwc3: gadget: move cmd_endtransfer to extra function")
Change-Id: I43d455a45d542efcaa9234de60e37277611b3c47
Signed-off-by: William Wu <william.wu@rock-chips.com>
drivers/pci/controller/dwc/pcie-dw-ep-rockchip.c:533:70: error: too few arguments to function call, expected 6, have 5
ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr, as_type);
Change-Id: Iaa3083f6cfe4edbba422fff5a245515f40c70db4
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
Validate vmf_insert_pfn return value with VM_FAULT_NOPAGE
Signed-off-by: Jacob Chen <cc@rock-chips.com>
Change-Id: I53b1eabd20ab76f08f5edf571ead1ffaccd19ec1
Fix the error from pinctrl
[ 5.112827] rockchip-pinctrl pinctrl: could not request pin 235 (gpio7-19) from group i2c5-xfer on device rockchip-pinctrl
[ 5.123951] rk3x-i2c ff170000.i2c: Error applying setting, reverse things back
[ 5.131207] rk3x-i2c: probe of ff170000.i2c failed with error -22
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: I7bdf76832fb2805ced05f0a5bb52612f528d8ebf
when uvc calls uvcg_video_enable() to disable the video
stream, it dequeues all requests from the usb endpoint,
and it expects the usb controller to giveback the requests
immediately, and then it can free the requests safely.
But for usb dwc3 controller, it doesn't giveback the
started requests in dequeue ops. Instead, it issues the
end transfer command and wait for the command completion
IRQ, then giveback the requests to uvc. If the uvc driver
free req before the command completion IRQ, it will led
to null pointer dereference problem. So need to wait
for the req complete before free it.
Example call stack on RK3588 platform:
Thread#1:
uvcg_video_enable()
-> usb_ep_dequeue()
-> dwc3_gadget_ep_dequeue()
-> dwc3_stop_active_transfer()
issue end transfer command
-> dwc3_gadget_move_cancelled_request()
...
-> uvc_video_free_requests()
-> Thread#2 executes
Thread#2:
dwc3 end transfer command completion IRQ occurs
dwc3_gadget_endpoint_command_complete()
-> dwc3_gadget_ep_cleanup_cancelled_requests()
-> dwc3_gadget_giveback()
-> usb_gadget_giveback_request()
-> uvc_video_complete()
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I0bcb8d18e851448fc973f901d74afa19ab1e2406
Due to the particularity of the px30 iommu, it is necessary to configure
the grf to switch iommu.
So need to configure rockchip,shootdown-entire to prevent a case from
happening: when one device is running, the task of another device
operates iommu when doing map.
This commit relies on the following commit:
commit 3b67ff56d6 ("video: rockchip: mpp: add iommu flush tlb before hw run for px30")
Signed-off-by: Yandong Lin <yandong.lin@rock-chips.com>
Change-Id: Ifd94ab4b5d7f53f711320b608ff105539fd9b38d
The rk3568 usb dwc3 controller has phy management at its
own driver to cover both device and host mode. And for
usb otg0, it enable device wakeup that make the usb hcd
core to keep the phy initialized so the device can wake
up the system. However, most of rk3568 platforms power
off the logic and cause phy grf lost power, thus we need
to add quirk-skip-phy-init to reinit phy grf upon system
resume.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I14061e3b8bad05818e8496d4710695ef31deed9f
PLL_CPLL is for VOP only, which does not need to be
initialized in CRU.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Change-Id: Ic51b4e2ef377ee6f796e807131f1fe02d0db39cc
When there is no acquire_fence, the allocated release_fence_fd must be
closed when the job submission fails, and it is unreasonable to require
user-space to close.
Update driver version to 1.2.22
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: Ie7c3006968dbb1ba22e21d6de65037183386112e
The gadget driver may wait on the request completion when it sets the
USB_GADGET_DELAYED_STATUS. Make sure that the End Transfer command can
go through if the dwc->delayed_status is set so that the request can
complete. When the delayed_status is set, the Setup packet is already
processed, and the next phase should be either Data or Status. It's
unlikely that the host would cancel the control transfer and send a new
Setup packet during End Transfer command. But if that's the case, we can
try again when ep0state returns to EP0_SETUP_PHASE.
Change-Id: Ie99f8e9306e1212dd602a8d9345dd5fabb640b0d
Fixes: e1ee843488 ("usb: dwc3: gadget: Force sending delayed status during soft disconnect")
Cc: stable@vger.kernel.org
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/3f9f59e5d74efcbaee444cf4b30ef639cc7b124e.1666146954.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 4db0fbb601)
DWC3_EP_DELAYED_STOP is utilized to defer issuing the end transfer command
until the subsequent SETUP stage, in order to avoid end transfer timeouts.
During cable disconnect scenarios, __dwc3_gadget_ep_disable() is
responsible for ensuring endpoints have no active transfers pending. Since
dwc3_remove_request() can now exit early if the EP delayed stop is set,
avoid clearing all DEP flags, otherwise the transition back into the SETUP
stage won't issue an endxfer command.
Change-Id: Ifaaf6405e24868b1b52f23aa492ed8ed783d1e14
Fixes: 2b2da6574e ("usb: dwc3: Avoid unmapping USB requests if endxfer is not complete")
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220919231213.21364-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 76bff31c7f)
If DWC3_EP_DELAYED_STOP is set during stop active transfers, then do not
continue attempting to unmap request buffers during dwc3_remove_requests().
This can lead to SMMU faults, as the controller has not stopped the
processing of the TRB. Defer this sequence to the EP0 out start, which
ensures that there are no pending SETUP transactions before issuing the
endxfer.
Change-Id: I576922c1a9566507f8ac268a4fc2c4bfb4129aee
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220901193625.8727-2-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 2b2da6574e)
During soft disconnect, EP0 events are expected to be handled in order to
allow the controller to successfully move into the halted state. Since
__dwc3_gadget_stop() is executed before polling, EP0 has been disabled, and
events are being blocked. Allow xfercomplete events to be handled, so that
cached SETUP packets can be read out from the internal controller memory.
Without doing so, it will lead to endxfer timeouts, which results to
controller halt failures.
Change-Id: Ie58a709ee48f8f8e869285414ee2fd93d4d56326
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220817182359.13550-5-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit dff981842a)
If any function drivers request for a delayed status phase, this leads to a
SETUP transfer timeout error, since the function may take longer to process
the DATA stage. This eventually results in end transfer timeouts, as there
is a pending SETUP transaction.
In addition, allow the DWC3_EP_DELAY_STOP to be set for if there is a
delayed status requested. Ocasionally, a host may abort the current SETUP
transaction, by issuing a subsequent SETUP token. In those situations, it
would result in an endxfer timeout as well.
Change-Id: I7decd682cf7f5714779364465383827efa22f2a1
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220817182359.13550-3-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit e1ee843488)
There are some operations that need to be ignored if there is a soft
disconnect in progress. This is to avoid having a pending EP0 transfer in
progress while attempting to stop active transfers and halting the
controller.
There were several instances seen where a soft disconnect was able to occur
during early link negotiation, i.e. bus reset/conndone, which leads to the
conndone handler re-configuring EPs while attempting to halt the
controller, as DEP flags are cleared as part of the soft disconnect path.
ep0out: cmd 'Start New Configuration'
ep0out: cmd 'Set Endpoint Transfer Resource'
ep0in: cmd 'Set Endpoint Transfer Resource'
ep1out: cmd 'Set Endpoint Transfer Resource'
...
event (00030601): Suspend [U3]
event (00000101): Reset [U0]
ep0out: req ffffff87e5c9e100 length 0/0 zsI ==> 0
event (00000201): Connection Done [U0]
ep0out: cmd 'Start New Configuration'
ep0out: cmd 'Set Endpoint Transfer Resource'
In addition, if a soft disconnect occurs, EP0 events are still allowed to
process, however, it will stall/restart during the SETUP phase. The
host is still able to query for the DATA phase, leading to a
xfernotready(DATA) event. Since none of the SETUP transfer parameters are
populated, the xfernotready is treated as a "wrong direction" error,
leading to a duplicate stall/restart routine.
Add the proper softconnect/connected checks in sequences that are
potentially involved during soft disconnect processing.
Change-Id: Iaeae73684d91391ab51a02db59e7d04d3a196301
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220817182359.13550-2-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 359d5a85a7)
Relocate the pullups_connected check until after it is ensured that there
are no runtime PM transitions. If another context triggered the DWC3
core's runtime resume, it may have already enabled the Run/Stop. Do not
re-run the entire pullup sequence again, as it may issue a core soft
reset while Run/Stop is already set.
This patch depends on
commit 69e131d1ac ("usb: dwc3: gadget: Prevent repeat pullup()")
Change-Id: Ic4fa942b4c5f39da71741146fb50b6785ba026ba
Fixes: 77adb8bdf4 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@kernel.org>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220728020647.9377-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 040f2dbd20)
The functions stop_active_transfers and ep_disable are both calling
remove_requests. This functions in both cases will giveback the requests
with status ESHUTDOWN, which also represents an physical disconnection.
For ep_disable this is not true. This patch adds the status parameter to
remove_requests and sets the status to ECONNRESET on ep_disable.
Change-Id: I7bb9dead0d4f4a50bc5600abb2a64d1d63257355
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220720213523.1055897-1-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit b44c0e7fef)
During a 3 stage SETUP transfer, if the host sends another SETUP token
before completing the status phase, it signifies that the host has aborted
the current control transfer. Currently, if a setup_packet_pending is
received, there are no subsequent calls to dwc3_ep0_out_start() to fetch
the new SETUP packet. This leads to a stall on EP0, as host does not
expect another STATUS phase as it has aborted the current transfer.
Fix this issue by explicitly stalling and restarting EP0, as well as
resetting the trb_enqueue indexes. (without this, there is a chance the
SETUP TRB is set up on trb_endqueue == 1)
Change-Id: Ib4502a1e5d70b46b6314b4061788d3883e2bdf42
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220712014403.2977-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 5e76ee96be)
According to the databook ep0 should be in setup phase during reset.
If host issues reset between control transfers, ep0 will be in an
invalid state. Fix this by issuing stall and restart on ep0 if it
is not in setup phase.
Also SW needs to complete pending control transfer and setup core for
next setup stage as per data book. Hence check ep0 state during reset
interrupt handling and make sure active transfers on ep0 out/in
endpoint are stopped by queuing ENDXFER command for that endpoint and
restart ep0 out again to receive next setup packet.
Change-Id: I4127a1d80d3f555ef606e22b49b309f24b7413bc
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
Link: https://lore.kernel.org/r/1651693001-29891-1-git-send-email-quic_mrana@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 9d778f0c5f)
If the controller hasn't DMA'ed the Setup data from its fifo, it won't
process the End Transfer command. Polling for the command completion may
block the driver from servicing the Setup phase and cause a timeout.
Previously we only check and delay issuing End Transfer in the case of
endpoint dequeue. Let's do that for all End Transfer scenarios.
Change-Id: I38ca19735337ca3e09d0d27d6623ea7acae37b16
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/2fcf3b5d90068d549589a57a27a79f76c6769b04.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f66eef8fb8)
The driver shouldn't be able to issue End Transfer to the control
endpoint at anytime. Typically we should only do so in error cases such
as invalid/unexpected direction of Data Phase as described in the
control transfer flow of the programming guide. It _may_ end started
data phase during controller deinitialization from soft disconnect or
driver removal. However, that should not happen because the driver
should be maintained in EP0_SETUP_PHASE during driver tear-down. On
soft-connect, the controller should be reset from a soft-reset and there
should be no issue starting the control endpoint.
Change-Id: I1dabd91d5078be2af8ff65e1fadd3cf16e76db7f
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/3c6643678863a26702e4115e9e19d7d94a30d49c.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit ace17b6ee4)
Since we can't guarantee that the host won't send new Setup packet
before going through the device-initiated disconnect, don't prepare
beyond the Setup stage and keep the device in EP0_SETUP_PHASE. This
ensures that the device-initated disconnect sequence can go through
gracefully. Note that the controller won't service the End Transfer
command if it can't DMA out the Setup packet.
Change-Id: I797d9cc93f775929acdead9762e79e073ac61239
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/6bacec56ecabb2c6e49a09cedfcac281fdc97de0.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c96683798e)
