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
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
Note, the corresponding mali_csffw.bin for DDK g15 MUST be used.
Change-Id: Ic30634fa6247d62bf96f506c64d13b89e16b02e6
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
CONFIG_LRU_GEN=y to build multi-gen LRU.
To enable it, echo y >/sys/kernel/mm/lru_gen/enabled.
According to gki commit 321995d280 ("ANDROID: GKI: build multi-gen LRU").
Signed-off-by: Bian Jin chen <kenjc.bian@rock-chips.com>
Change-Id: I5fe01da22e84d7d3f6786d3586b8c795c23e9af5
According to gki commit d0bf79a102 ("ANDROID: GKI: enable CONFIG_ANON_VMA_NAME to support anonymous vma names").
Signed-off-by: Bian Jin chen <kenjc.bian@rock-chips.com>
Change-Id: Ib713f511e99bc688f093e7274b3dd51a801ac044
https://source.android.com/docs/security/bulletin/2022-11-01
* tag 'ASB-2022-11-01_13-5.10':
FROMLIST: binder: fix UAF of alloc->vma in race with munmap()
ANDROID: Update the ABI representation
ANDROID: vendor hook to control blk_plug for shrink_lruvec
UPSTREAM: mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region()
UPSTREAM: af_key: Do not call xfrm_probe_algs in parallel
UPSTREAM: mm: Force TLB flush for PFNMAP mappings before unlink_file_vma()
ANDROID: KVM: arm64: Donate memory per vcpu for each vcpu shadow state
ANDROID: KVM: arm64: Initialize shadow vcpus with separate hypercalls
ANDROID: KVM: arm64: Refactor unpinning host vcpu
ANDROID: KVM: arm64: Separate functions for shadow vm and vcpu init
ANDROID: KVM: arm64: Refactor code for reclaiming guest memory into a function
ANDROID: pass argument in zap_pte_range vendor hooks
ANDROID: GKI: Add for rockchip platform basic symbol
ANDROID: GKI: Add Bazel rockchip symbol list entry
ANDROID: sched: check on_rq in freezer_should_skip()
ANDROID: Update the ABI representation
ANDROID: KVM: arm64: Only unpin a vCPU SVE state if set
Change-Id: I4d2dad507abf94433e515048bb64f11597e36981
* android13-5.10-2022-11: (27 commits)
ANDROID: Update the ABI representation
FROMGIT: f2fs: let's avoid to get cp_rwsem twice by f2fs_evict_inode by d_invalidate
ANDROID: Update the ABI representation
ANDROID: vendor hook to control blk_plug for memory reclaim
ANDROID: Update the ABI representation
UPSTREAM: wifi: mac80211: fix MBSSID parsing use-after-free
UPSTREAM: wifi: mac80211: don't parse mbssid in assoc response
UPSTREAM: mac80211: mlme: find auth challenge directly
UPSTREAM: wifi: cfg80211: update hidden BSSes to avoid WARN_ON
UPSTREAM: wifi: mac80211: fix crash in beacon protection for P2P-device
UPSTREAM: wifi: mac80211_hwsim: avoid mac80211 warning on bad rate
UPSTREAM: wifi: cfg80211: avoid nontransmitted BSS list corruption
UPSTREAM: wifi: cfg80211: fix BSS refcounting bugs
UPSTREAM: wifi: cfg80211: ensure length byte is present before access
UPSTREAM: wifi: cfg80211/mac80211: reject bad MBSSID elements
UPSTREAM: wifi: cfg80211: fix u8 overflow in cfg80211_update_notlisted_nontrans()
ANDROID: Update the ABI representation
ANDROID: vendor hook to control bh_lru and lru_cache_disable
ANDROID: Update the ABI representation
ANDROID: vendor hook for TLB batching control
...
Change-Id: Iad3143c43143372e590aca59aae77836b3b71c8a
https://source.android.com/docs/security/bulletin/2022-10-01
CVE-2022-1786
CVE-2022-20421
CVE-2022-20422
CVE-2022-20423
CVE-2022-20409
* tag 'ASB-2022-10-01_13-5.10': (68 commits)
UPSTREAM: crypto: jitter - add oversampling of noise source
ANDROID: Update the ABI representation
FROMGIT: f2fs: support recording stop_checkpoint reason into super_block
ANDROID: Update the ABI representation
ANDROID: Fix for kernelci !CONFIG_SMP break-breaks
ANDROID: fuse-bpf: set error_in to ENOENT in negative lookup
ANDROID: fuse-bpf: Add ability to run ranges of tests to fuse_test
BACKPORT: NFC: netlink: fix sleep in atomic bug when firmware download timeout
ANDROID: KVM: arm64: Initialize ptr auth in protected mode
ANDROID: cgroup: Add vendor hook for rebuild_root_domains_bypass
FROMGIT: KVM: arm64: Ignore kvm-arm.mode if !is_hyp_mode_available()
ANDROID: Update the ABI symbol list and xml
UPSTREAM: wifi: mac80211_hwsim: use 32-bit skb cookie
UPSTREAM: wifi: mac80211_hwsim: add back erroneously removed cast
UPSTREAM: wifi: mac80211_hwsim: fix race condition in pending packet
ANDROID: Update the ABI representation
ANDROID: sched: Fix off-by-one with cpupri MAX_RT_PRIO evaluation
Revert "ANDROID: workqueue: add vendor hook for wq lockup information"
UPSTREAM: kernel/irq: export irq_gc_set_wake
ANDROID: Update the ABI representation
...
Change-Id: I0e90348befd683d679799deb2b2f0bf738dbc99f
Conflicts:
sound/soc/codecs/hdmi-codec.c
* 4bcdb727b2: (154 commits)
video: rockchip: rga3: fix leak of release_fence_fd
drm/bridge: synopsys: dw-hdmi-qp: Fix hdmi phy power off in DVI mode
arm64: dts: rockchip: rk3399: add gpio drive strength 10ma
crypto: rockchip: fix crush when skcipher fallback alloc failed
UPSTREAM: usb: dwc3: gadget: Don't delay End Transfer on delayed_status
UPSTREAM: usb: dwc3: gadget: Do not clear ep delayed stop flag during ep disable
UPSTREAM: usb: dwc3: gadget: Submit endxfer command if delayed during disconnect
UPSTREAM: usb: dwc3: gadget: Skip waiting for CMDACT cleared during endxfer
UPSTREAM: usb: dwc3: Increase DWC3 controller halt timeout
UPSTREAM: usb: dwc3: Remove DWC3 locking during gadget suspend/resume
UPSTREAM: usb: dwc3: Avoid unmapping USB requests if endxfer is not complete
UPSTREAM: usb: dwc3: gadget: Continue handling EP0 xfercomplete events
UPSTREAM: usb: dwc3: gadget: Synchronize IRQ between soft connect/disconnect
UPSTREAM: usb: dwc3: gadget: Force sending delayed status during soft disconnect
BACKPORT: usb: dwc3: Do not service EP0 and conndone events if soft disconnected
UPSTREAM: usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop
UPSTREAM: usb: dwc3: gadget: conditionally remove requests
UPSTREAM: usb: dwc3: ep0: Properly handle setup_packet_pending scenario in data stage
UPSTREAM: usb: dwc3: Fix a repeated word checkpatch warning
UPSTREAM: usb: dwc3: Fix bare use of unsigned checkpatch warning
...
Change-Id: I78167bdf7a4c2f19e4ba56f5022aa689bc18bac7
Conflicts:
drivers/usb/dwc3/core.h
drivers/usb/dwc3/gadget.c
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)
Don't do soft-disconnect if it's previously done. Likewise, don't do
soft-connect if the device is currently connected and running. It would
break normal operation.
Currently the caller of pullup() (udc's sysfs soft_connect) only checks
if it had initiated disconnect to prevent repeating soft-disconnect. It
doesn't check for soft-connect. To be safe, let's keep the check here
regardless whether the udc core is fixed.
Change-Id: I07eaeb0ed388ef967eeb9c7513a9c1b260f8d9c5
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1c1345bd66c97a9d32f77d63aaadd04b7b037143.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 69e131d1ac)
The usb_ep_clear_halt() API can be called from the function driver, and
translates to dwc3_gadget_ep_set_halt(). This routine is shared with when
the host issues a clear feature ENDPOINT_HALT, and is differentiated by the
protocol argument. If the following sequence occurs, there can be a
situation where the delayed_status flag is improperly cleared for the wrong
SETUP transaction:
1. Vendor specific control transfer returns USB_GADGET_DELAYED_STATUS.
2. DWC3 gadget sets dwc->delayed_status to '1'.
3. Another function driver issues a usb_ep_clear_halt() call.
4. DWC3 gadget issues dwc3_stop_active_transfer() and sets
DWC3_EP_PENDING_CLEAR_STALL.
5. EP command complete interrupt triggers for the end transfer, and
dwc3_ep0_send_delayed_status() is allowed to run, as delayed_status
is '1' due to step#1.
6. STATUS phase is sent, and delayed_status is cleared.
7. Vendor specific control transfer is finished being handled, and issues
usb_composite_setup_continue(). This results in queuing of a data
phase.
Cache the protocol flag so that DWC3 gadget is aware of when the clear halt
is due to a SETUP request from the host versus when it is sourced from a
function driver. This allows for the EP command complete interrupt to know
if it needs to issue a delayed status phase.
Change-Id: If19e1628c151a109820a60e7b4c4c6f6128a2242
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220414073902.21960-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 2840d6dfcf)
