summaryrefslogtreecommitdiff
path: root/drivers/usb/dwc3/gadget.c
AgeCommit message (Collapse)Author
2020-05-19Merge tag 'v4.9.220' into 4.9-2.3.x-imxMarcel Ziswiler
This is the 4.9.220 stable release Conflicts: arch/arm/Kconfig.debug arch/arm/boot/dts/imx7s.dtsi arch/arm/mach-imx/common.h arch/arm/mach-imx/cpuidle-imx6q.c arch/arm/mach-imx/cpuidle-imx6sx.c arch/arm/mach-imx/suspend-imx6.S block/blk-core.c drivers/crypto/caam/caamalg.c drivers/crypto/mxs-dcp.c drivers/dma/imx-sdma.c drivers/gpu/drm/bridge/adv7511/adv7511_drv.c drivers/input/keyboard/imx_keypad.c drivers/input/keyboard/snvs_pwrkey.c drivers/mmc/host/sdhci.c drivers/net/can/flexcan.c drivers/net/ethernet/freescale/fec_main.c drivers/net/phy/phy_device.c drivers/net/wireless/ath/ath10k/pci.c drivers/tty/serial/imx.c drivers/usb/dwc3/gadget.c drivers/usb/host/xhci.c include/linux/blkdev.h include/linux/cpu.h include/linux/platform_data/dma-imx-sdma.h kernel/cpu.c net/wireless/util.c sound/soc/fsl/Kconfig sound/soc/fsl/fsl_esai.c sound/soc/fsl/fsl_sai.c sound/soc/fsl/imx-sgtl5000.c
2020-04-13usb: dwc3: don't set gadget->is_otg flagRoger Quadros
commit c09b73cfac2a9317f1104169045c519c6021aa1d upstream. This reverts commit 6a4290cc28be1 ("usb: dwc3: gadget: set the OTG flag in dwc3 gadget driver.") We don't yet support any of the OTG mechanisms (HNP/SRP/ADP) and are not setting gadget->otg_caps, so don't set gadget->is_otg flag. If we do then we end up publishing a OTG1.0 descriptor in the gadget descriptor which causes device enumeration to fail if we are connected to a host with CONFIG_USB_OTG enabled. Host side log without this patch [ 96.720453] usb 1-1: new high-speed USB device number 2 using xhci-hcd [ 96.901391] usb 1-1: Dual-Role OTG device on non-HNP port [ 96.907552] usb 1-1: set a_alt_hnp_support failed: -32 [ 97.060447] usb 1-1: new high-speed USB device number 3 using xhci-hcd [ 97.241378] usb 1-1: Dual-Role OTG device on non-HNP port [ 97.247536] usb 1-1: set a_alt_hnp_support failed: -32 [ 97.253606] usb usb1-port1: attempt power cycle [ 97.960449] usb 1-1: new high-speed USB device number 4 using xhci-hcd [ 98.141383] usb 1-1: Dual-Role OTG device on non-HNP port [ 98.147540] usb 1-1: set a_alt_hnp_support failed: -32 [ 98.300453] usb 1-1: new high-speed USB device number 5 using xhci-hcd [ 98.481391] usb 1-1: Dual-Role OTG device on non-HNP port [ 98.487545] usb 1-1: set a_alt_hnp_support failed: -32 [ 98.493532] usb usb1-port1: unable to enumerate USB device Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-28Merge tag 'v4.9.166' into 4.9-2.3.x-imxMarcel Ziswiler
This is the 4.9.166 stable release
2019-03-05usb: dwc3: gadget: Fix the uninitialized link_state when udc startsZeng Tao
[ Upstream commit 88b1bb1f3b88e0bf20b05d543a53a5b99bd7ceb6 ] Currently the link_state is uninitialized and the default value is 0(U0) before the first time we start the udc, and after we start the udc then stop the udc, the link_state will be undefined. We may have the following warnings if we start the udc again with an undefined link_state: WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308 dwc3 100e0000.hidwc3_0: wakeup failed --> -22 [...] Call Trace: [<c010f270>] (unwind_backtrace) from [<c010b3d8>] (show_stack+0x10/0x14) [<c010b3d8>] (show_stack) from [<c034a4dc>] (dump_stack+0x84/0x98) [<c034a4dc>] (dump_stack) from [<c0118000>] (__warn+0xe8/0x100) [<c0118000>] (__warn) from [<c0118050>](warn_slowpath_fmt+0x38/0x48) [<c0118050>] (warn_slowpath_fmt) from [<c0442ec0>](dwc3_send_gadget_ep_cmd+0x304/0x308) [<c0442ec0>] (dwc3_send_gadget_ep_cmd) from [<c0445e68>](dwc3_ep0_start_trans+0x48/0xf4) [<c0445e68>] (dwc3_ep0_start_trans) from [<c0446750>](dwc3_ep0_out_start+0x64/0x80) [<c0446750>] (dwc3_ep0_out_start) from [<c04451c0>](__dwc3_gadget_start+0x1e0/0x278) [<c04451c0>] (__dwc3_gadget_start) from [<c04452e0>](dwc3_gadget_start+0x88/0x10c) [<c04452e0>] (dwc3_gadget_start) from [<c045ee54>](udc_bind_to_driver+0x88/0xbc) [<c045ee54>] (udc_bind_to_driver) from [<c045f29c>](usb_gadget_probe_driver+0xf8/0x140) [<c045f29c>] (usb_gadget_probe_driver) from [<bf005424>](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite]) [<bf005424>] (gadget_dev_desc_UDC_store [libcomposite]) from[<c023d8e0>] (configfs_write_file+0xd4/0x160) [<c023d8e0>] (configfs_write_file) from [<c01d51e8>] (__vfs_write+0x1c/0x114) [<c01d51e8>] (__vfs_write) from [<c01d5ff4>] (vfs_write+0xa4/0x168) [<c01d5ff4>] (vfs_write) from [<c01d6d40>] (SyS_write+0x3c/0x90) [<c01d6d40>] (SyS_write) from [<c0107400>] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Zeng Tao <prime.zeng@hisilicon.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-05usb: dwc3: gadget: synchronize_irq dwc irq in suspendBo He
[ Upstream commit 01c10880d24291a96a4ab0da773e3c5ce4d12da8 ] We see dwc3 endpoint stopped by unwanted irq during suspend resume test, which is caused dwc3 ep can't be started with error "No Resource". Here, add synchronize_irq before suspend to sync the pending IRQ handlers complete. Signed-off-by: Bo He <bo.he@intel.com> Signed-off-by: Yu Wang <yu.y.wang@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-12-05Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"Felipe Balbi
commit 38317f5c0f2faae5110854f36edad810f841d62f upstream. This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3. Turns out that commit is wrong. Host controllers are allowed to use Clear Feature HALT as means to sync data toggle between host and periperal. Cc: <stable@vger.kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-24MLK-18922-2 usb: dwc3: add OTG capabilities handlingPeter Chen
During the USB certification CV9 test, if we report OTG descriptor to test suite, it will require doing OTG test, but in fact, it does not support OTG-compliance in dwc3 driver. For one Image configuration, it may choose CONFIG_USB_OTG, in order to skip OTG descriptor, we need to set gadget->is_otg as false for non OTG-compliance hardware. Due to dwc3 IP supports OTG-compliance, the user can add "hnp-disable", "srp-disable" and "adp-disable" at firmware to disable OTG features (skip OTG descriptor). This patch does NOT affect current configuration descriptors. Acked-by: Jun Li <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com>
2018-08-24MLK-17887 Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"Li Jun
This reverts commit 3ccf60e1ff5e ("usb: dwc3: gadget: skip Set/Clear Halt when invalid") "At least macOS seems to be sending ClearFeature(ENDPOINT_HALT) to endpoints which aren't Halted. This makes DWC3's CLEARSTALL command time out which causes several issues for the driver." but this change is impacting usb CV compliance test with windows, which using clear EP halt for other purpose in this case, as this is not resolved on upstream, so revert this patch for now. Acke-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Li Jun <jun.li@nxp.com>
2018-08-24usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeueFelipe Balbi
If request was already started, this means we had to stop the transfer. With that we also need to ignore all TRBs used by the request, however TRBs can only be modified after completion of END_TRANSFER command. So what we have to do here is wait for END_TRANSFER completion and only after that jump over TRBs by clearing HWO and incrementing dequeue pointer. Note that we have 2 possible types of transfers here: i) Linear buffer request ii) SG-list based request SG-list based requests will have r->num_pending_sgs set to a valid number (> 0). Linear requests, normally use a single TRB. All of these cases need to be taken into consideration so we don't mess up our TRB ring pointers. Tested-by: Janusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> (cherry picked from commit cf3113d893d4427b166ec8695460efa7aa660923)
2018-08-24usb: dwc3: gadget: wait for End Transfer to completeBaolin Wang
Instead of just delaying for 100us, we should actually wait for End Transfer Command Complete interrupt before moving on. Note that this should only be done if we're dealing with one of the core revisions that actually require the interrupt before moving on. [ felipe.balbi@linux.intel.com: minor improvements ] Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> (cherry picked from commit 76a638f8ac0dd1dadee8f87acff36174d473b7c1)
2018-08-24MLK-16775-1 usb: dwc3: gadget: add high bus freq supportLi Jun
Add high bus request for connection to host in reset handling, and high bus release for disconnection. Signed-off-by: Li Jun <jun.li@nxp.com>
2018-08-24usb: dwc3: gadget: Fix ISO transfer performanceRoger Quadros
Commit 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()") caused a small change in the way ISO transfer is handled in the case when XferInProgress event happens on Isoc EP with an active transfer. This caused a performance degradation of 50%. e.g. using g_webcam on DUT and luvcview on host the video frame rate dropped from 16fps to 8fps @high-speed. Make the ISO transfer handling equivalent to that prior to that commit to get back the original ISO performance numbers. Fixes: 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()") Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> (cherry picked from commit f1d6826cae30e97e37a1f2481d7e1dc4faa09ce1)
2018-08-24usb: dwc3: gadget: cope with XferNotReady before usb_ep_queue()Felipe Balbi
If XferNotReady comes before usb_ep_queue() we will set our PENDING request flag and wait for a request. However, originally, we were assuming usb_ep_queue() would always happen before our first XferNotReady and that causes a corner case where we could try to issue ENDTRANSFER command before STARTTRANSFER. Let's fix that by tracking endpoints which have been started. Reported-by: Janusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> (cherry picked from commit 6cb2e4e3de10893f38dbf3923a9cc50c76548a89)
2018-08-24usb: dwc3: gadget: properly check ep cmdFelipe Balbi
The cmd argument we pass to dwc3_send_gadget_ep_cmd() could contain extra arguments embedded. When checking for StartTransfer command, we need to make sure to match only lower 4 bits which contain the actual command and ignore the rest. Reported-by: Janusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> (cherry picked from commit 5999914f227b20addf01297b3df24be6b4161f69)
2018-08-24MLK-16013-7 usb: dwc3: gadget: increase timeout count for ep cmdLi Jun
Increase the timeout value for wait ep command complete, this is temp solution to workaround it but no harm any good cases. Reviewed-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Li Jun <jun.li@nxp.com>
2018-02-28usb: dwc3: gadget: Set maxpacket size for ep0 INThinh Nguyen
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream. There are 2 control endpoint structures for DWC3. However, the driver only updates the OUT direction control endpoint structure during ConnectDone event. DWC3 driver needs to update the endpoint max packet size for control IN endpoint as well. If the max packet size is not properly set, then the driver will incorrectly calculate the data transfer size and fail to send ZLP for HS/FS 3-stage control read transfer. The fix is simply to update the max packet size for the ep0 IN direction during ConnectDone event. Cc: stable@vger.kernel.org Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-02-25usb: dwc3: gadget: Wait longer for controller to end command processingVincent Pelletier
[ Upstream commit 8722e095f5a44d0e409e45c5ddc2ee9cf589c777 ] DWC3_DEPCMD_ENDTRANSFER has been witnessed to require around 600 iterations before controller would become idle again after unplugging the USB cable with AIO reads submitted. Bump timeout from 500 iterations to 1000 so dwc3_stop_active_transfer does not receive -ETIMEDOUT and does not WARN: [ 81.326273] ------------[ cut here ]------------ [ 81.335341] WARNING: CPU: 0 PID: 1874 at drivers/usb/dwc3/gadget.c:2627 dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3] [ 81.347094] Modules linked in: usb_f_fs libcomposite configfs bnep btsdio bluetooth ecdh_generic brcmfmac brcmutil dwc3 intel_powerclamp coretemp ulpi kvm_intel udc_core kvm irqbypass crc32_pclmul crc32c_intel pcbc dwc3_pci aesni_intel aes_i586 crypto_simd cryptd ehci_pci ehci_hcd basincove_gpadc industrialio gpio_keys usbcore usb_common [ 81.378142] CPU: 0 PID: 1874 Comm: irq/34-dwc3 Not tainted 4.14.0-edison+ #119 [ 81.385545] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 81.394548] task: f5b1be00 task.stack: f420a000 [ 81.399219] EIP: dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3] [ 81.406086] EFLAGS: 00010086 CPU: 0 [ 81.409672] EAX: 0000001f EBX: f5729800 ECX: c132a2a2 EDX: 00000000 [ 81.416096] ESI: f4054014 EDI: f41cf400 EBP: f420be10 ESP: f420bdf4 [ 81.422521] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 81.428061] CR0: 80050033 CR2: b7a3f000 CR3: 01d94000 CR4: 001006d0 [ 81.434483] Call Trace: [ 81.437063] __dwc3_gadget_ep_disable+0xa3/0x2b0 [dwc3] [ 81.442438] ? _raw_spin_lock_irqsave+0x32/0x40 [ 81.447135] dwc3_gadget_ep_disable+0xbf/0xe0 [dwc3] [ 81.452269] usb_ep_disable+0x1c/0xd0 [udc_core] [ 81.457048] ffs_func_eps_disable.isra.15+0x3b/0x90 [usb_f_fs] [ 81.463070] ffs_func_set_alt+0x7d/0x310 [usb_f_fs] [ 81.468132] ffs_func_disable+0x14/0x20 [usb_f_fs] [ 81.473075] reset_config+0x5b/0x90 [libcomposite] [ 81.478023] composite_disconnect+0x2b/0x50 [libcomposite] [ 81.483685] dwc3_disconnect_gadget+0x39/0x50 [dwc3] [ 81.488808] dwc3_gadget_disconnect_interrupt+0x21b/0x250 [dwc3] [ 81.495014] dwc3_thread_interrupt+0x2a8/0xf70 [dwc3] [ 81.500219] ? __schedule+0x78c/0x7e0 [ 81.504027] irq_thread_fn+0x18/0x30 [ 81.507715] ? irq_thread+0xb7/0x180 [ 81.511400] irq_thread+0x111/0x180 [ 81.515000] ? irq_finalize_oneshot+0xe0/0xe0 [ 81.519490] ? wake_threads_waitq+0x30/0x30 [ 81.523806] kthread+0x107/0x110 [ 81.527131] ? disable_percpu_irq+0x50/0x50 [ 81.531439] ? kthread_stop+0x150/0x150 [ 81.535397] ret_from_fork+0x19/0x24 [ 81.539136] Code: 89 d8 c7 45 ec 00 00 00 00 c7 45 f0 00 00 00 00 c7 45 f4 00 00 00 00 e8 56 ef ff ff 85 c0 74 12 50 68 b9 1c 14 f8 e8 64 0f f7 c8 <0f> ff 58 5a 8d 76 00 8b 83 98 00 00 00 c6 83 a0 00 00 00 00 83 [ 81.559295] ---[ end trace f3133eec81a473b8 ]--- Number of iterations measured on 4 consecutive unplugs: [ 1088.799777] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 605 times [ 1222.024986] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 580 times [ 1317.590452] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 598 times [ 1453.218314] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 594 times Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14usb: dwc3: gadget: Fix system suspend/resume on TI platformsRoger Quadros
[ Upstream commit 1551e35ea4189c1f7199fe278395fc94196715f2 ] On TI platforms (dra7, am437x), the DWC3_DSTS_DEVCTRLHLT bit is not set after the device controller is stopped via DWC3_DCTL_RUN_STOP. If we don't disconnect and stop the gadget, it stops working after a system resume with the trace below. There is no point in preventing gadget disconnect and gadget stop during system suspend/resume as we're going to suspend in any case, whether DEVCTRLHLT timed out or not. [ 141.727480] ------------[ cut here ]------------ [ 141.732349] WARNING: CPU: 1 PID: 2135 at drivers/usb/dwc3/gadget.c:2384 dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3] [ 141.744299] Modules linked in: usb_f_ss_lb g_zero libcomposite xhci_plat_hcd xhci_hcd usbcore dwc3 evdev udc_core m25p80 usb_common spi_nor snd_soc_davinci_mcasp snd_soc_simple_card snd_soc_edma snd_soc_tlv3e [ 141.792163] CPU: 1 PID: 2135 Comm: irq/456-dwc3 Not tainted 4.10.0-rc8 #1138 [ 141.799547] Hardware name: Generic DRA74X (Flattened Device Tree) [ 141.805940] [<c01101b4>] (unwind_backtrace) from [<c010c31c>] (show_stack+0x10/0x14) [ 141.814066] [<c010c31c>] (show_stack) from [<c04a0918>] (dump_stack+0xac/0xe0) [ 141.821648] [<c04a0918>] (dump_stack) from [<c013708c>] (__warn+0xd8/0x104) [ 141.828955] [<c013708c>] (__warn) from [<c0137164>] (warn_slowpath_null+0x20/0x28) [ 141.836902] [<c0137164>] (warn_slowpath_null) from [<bf27784c>] (dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3]) [ 141.848329] [<bf27784c>] (dwc3_stop_active_transfer.constprop.4 [dwc3]) from [<bf27ab14>] (__dwc3_gadget_ep_disable+0x64/0x528 [dwc3]) [ 141.861034] [<bf27ab14>] (__dwc3_gadget_ep_disable [dwc3]) from [<bf27c27c>] (dwc3_gadget_ep_disable+0x3c/0xc8 [dwc3]) [ 141.872280] [<bf27c27c>] (dwc3_gadget_ep_disable [dwc3]) from [<bf23b428>] (usb_ep_disable+0x11c/0x18c [udc_core]) [ 141.883160] [<bf23b428>] (usb_ep_disable [udc_core]) from [<bf342774>] (disable_ep+0x18/0x54 [usb_f_ss_lb]) [ 141.893408] [<bf342774>] (disable_ep [usb_f_ss_lb]) from [<bf3437b0>] (disable_endpoints+0x18/0x50 [usb_f_ss_lb]) [ 141.904168] [<bf3437b0>] (disable_endpoints [usb_f_ss_lb]) from [<bf343814>] (disable_source_sink+0x2c/0x34 [usb_f_ss_lb]) [ 141.915771] [<bf343814>] (disable_source_sink [usb_f_ss_lb]) from [<bf329a9c>] (reset_config+0x48/0x7c [libcomposite]) [ 141.927012] [<bf329a9c>] (reset_config [libcomposite]) from [<bf329afc>] (composite_disconnect+0x2c/0x54 [libcomposite]) [ 141.938444] [<bf329afc>] (composite_disconnect [libcomposite]) from [<bf23d7dc>] (usb_gadget_udc_reset+0x10/0x34 [udc_core]) [ 141.950237] [<bf23d7dc>] (usb_gadget_udc_reset [udc_core]) from [<bf276d70>] (dwc3_gadget_reset_interrupt+0x64/0x698 [dwc3]) [ 141.962022] [<bf276d70>] (dwc3_gadget_reset_interrupt [dwc3]) from [<bf27952c>] (dwc3_thread_interrupt+0x618/0x1a3c [dwc3]) [ 141.973723] [<bf27952c>] (dwc3_thread_interrupt [dwc3]) from [<c01a7ce8>] (irq_thread_fn+0x1c/0x54) [ 141.983215] [<c01a7ce8>] (irq_thread_fn) from [<c01a7fbc>] (irq_thread+0x120/0x1f0) [ 141.991247] [<c01a7fbc>] (irq_thread) from [<c015ba14>] (kthread+0xf8/0x138) [ 141.998641] [<c015ba14>] (kthread) from [<c01078f0>] (ret_from_fork+0x14/0x24) [ 142.006213] ---[ end trace b4ecfe9f175b9a9c ]--- Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-21usb: dwc3: gadget: Correct ISOC DATA PIDs for short packetsManu Gautam
commit 40d829fb2ec636b6b4b0cc95e2546ab9aca04cc9 upstream. The PIDs for Isochronous data transfers are incorrect for high bandwidth IN endpoints when the request length is less than EP wMaxPacketSize. As per spec correct PIDs for ISOC data transfers are: 1) For request length <= maxpacket - DATA0, 2) For maxpacket < length <= (2 * maxpacket) - DATA1, DATA0 3) For (2 * maxpacket) < length <= (3 * maxpacket) - DATA2, DATA1, DATA0. But driver always sets PCM fields based on wMaxPacketSize due to which DATA2 happens even for small requests. Fix this by setting the PCM field of trb->size depending on request length rather than fixing it to the value depending on wMaxPacketSize. Ideally it shouldn't give any issues as dwc3 will send 0-length packet for next IN token if host sends (even after receiving a short packet). Windows seems to ignore this but with MacOS frame loss observed when using f_uvc. Signed-off-by: Manu Gautam <mgautam@codeaurora.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> [b-liu@ti.com added following change for v4.9.] - unsigned int maxp = usb_endpoint_maxp(ep->desc); + unsigned int maxp; + maxp = usb_endpoint_maxp(ep->desc) & 0x07ff; Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-12usb: dwc3: replace %p with %pKFelipe Balbi
commit 04fb365c453e14ff9e8a28f1c46050d920a27a4a upstream. %p will leak kernel pointers, so let's not expose the information on dmesg and instead use %pK. %pK will only show the actual addresses if explicitly enabled under /proc/sys/kernel/kptr_restrict. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25usb: dwc3: gadget: Prevent losing events in event cacheThinh Nguyen
commit d325a1de49d61ee11aca58a529571c91ecea7879 upstream. The dwc3 driver can overwite its previous events if its top-half IRQ handler (TH) gets invoked again before processing the events in the cache. We see this as a hang in the file transfer and the host will attempt to reset the device. TH gets the event count and deasserts the interrupt line by writing DWC3_GEVNTSIZ_INTMASK to DWC3_GEVNTSIZ. If there's a new event coming between reading the event count and interrupt deassertion, dwc3 will lose previous pending events. More generally, we will see 0 event count, which should not affect anything. This shouldn't be possible in the current dwc3 implementation. However, through testing and reading the PCIe trace, the TH occasionally still gets invoked one more time after HW interrupt deassertion. (With PCIe legacy interrupts, TH is called repeatedly as long as the interrupt line is asserted). We suspect that there is a small detection delay in the SW. To avoid this issue, Check DWC3_EVENT_PENDING flag to determine if the events are processed in the bottom-half IRQ handler. If not, return IRQ_HANDLED and don't process new event. Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-12usb: dwc3: gadget: delay unmap of bounced requestsJanusz Dziedzic
commit de288e36fe33f7e06fa272bc8e2f85aa386d99aa upstream. In the case of bounced ep0 requests, we must delay DMA operation until after ->complete() otherwise we might overwrite contents of req->buf. This caused problems with RNDIS gadget. Signed-off-by: Janusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-12usb: dwc3: gadget: skip Set/Clear Halt when invalidFelipe Balbi
commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3 upstream. At least macOS seems to be sending ClearFeature(ENDPOINT_HALT) to endpoints which aren't Halted. This makes DWC3's CLEARSTALL command time out which causes several issues for the driver. Instead, let's just return 0 and bail out early. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12usb: dwc3: gadget: always unmap EP0 requestsFelipe Balbi
commit d62145929992f331fdde924d5963ab49588ccc7d upstream. commit 0416e494ce7d ("usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced") introduced a bug where we would leak DMA resources which would cause us to starve the system of them resulting in failing DMA transfers. Fix the bug by making sure that we always unmap EP0 requests since those are *always* mapped. Fixes: 0416e494ce7d ("usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced") Cc: <stable@vger.kernel.org> Tested-by: Tomasz Medrek <tomaszx.medrek@intel.com> Reported-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12usb: dwc3: gadget: Fix full speed modeRoger Quadros
commit 9418ee15f718939aa7e650fd586d73765eb21f20 upstream. DCFG.DEVSPD == 0x3 is not valid and we need to set DCFG.DEVSPD to 0x1 for full speed mode. Same goes for DSTS.CONNECTSPD. Old databooks had 0x3 for full speed in 48MHz mode for USB1.1 transceivers which was never supported. Newer databooks don't mention 0x3 at all. Cc: John Youn <John.Youn@synopsys.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-06usb: dwc3: gadget: set PCM1 field of isochronous-first TRBsFelipe Balbi
commit 6b9018d4c1e5c958625be94a160a5984351d4632 upstream. In case of High-Speed, High-Bandwidth endpoints, we need to tell DWC3 that we have more than one packet per interval. We do that by setting PCM1 field of Isochronous-First TRB. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-17usb: dwc3: Fix size used in dma_free_coherent()Christophe JAILLET
In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the size of the memory allocated with 'dma_alloc_coherent()' has been modified but the corresponding calls to 'dma_free_coherent()' have not been updated accordingly. This has been spotted with coccinelle, using the following script: //////////////////// @r@ expression x0, x1, y0, y1, z0, z1, t0, t1, ret; @@ * ret = dma_alloc_coherent(x0, y0, z0, t0); ... * dma_free_coherent(x1, y1, ret, t1); @script:python@ y0 << r.y0; y1 << r.y1; @@ if y1.find(y0) == -1: print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1) //////////////////// Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-10-17usb: dwc3: gadget: never pre-start Isochronous endpointsFelipe Balbi
We cannot pre-start isochronous endpoints because we rely on the micro-frame number passed via XferNotReady command for proper Isochronous scheduling. Fixes: 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()") Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-10-17usb: dwc3: gadget: properly account queued requestsFelipe Balbi
Some requests could be accounted for multiple times. Let's fix that so each and every requests is accounted for only once. Cc: <stable@vger.kernel.org> # v4.8 Fixes: 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for LST bit") Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-09-14Merge tag 'usb-for-v4.9' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Felipe writes: usb: patches for v4.9 merge window This time around we have 92 non-merge commits. Most of the changes are in drivers/usb/gadget (40.3%) with drivers/usb/gadget/function being the most active directory (27.2%). As for UDC drivers, only dwc3 (26.5%) and dwc2 (12.7%) have really been active. The most important changes for dwc3 are better support for scatterlist and, again, throughput improvements. While on dwc2 got some minor stability fixes related to soft reset and FIFO usage. Felipe Tonello has done some good work fixing up our f_midi gadget and Tal Shorer has implemented a nice API change for our ULPI bus. Apart from these, we have our usual set of non-critical fixes, spelling fixes, build warning fixes, etc.
2016-09-12usb: dwc3: fix Clear Stall EP command failureLu Baolu
Commit 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command") sets ClearPendIN bit for all IN endpoints of v2.60a+ cores. This causes ClearStall command fails on 2.60+ cores operating in HighSpeed mode. In page 539 of 2.60a specification: "When issuing Clear Stall command for IN endpoints in SuperSpeed mode, the software must set the "ClearPendIN" bit to '1' to clear any pending IN transcations, so that the device does not expect any ACK TP from the host for the data sent earlier." It's obvious that we only need to apply this rule to those IN endpoints that currently operating in SuperSpeed mode. Fixes: 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command") Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-09-09usb: dwc3: avoid -Wmaybe-uninitialized warningArnd Bergmann
Cleaning up the loop in dwc3_cleanup_done_reqs() introduced a gcc warning if built with "-Wmaybe-uninitialized": drivers/usb/dwc3/gadget.c: In function 'dwc3_endpoint_transfer_complete': drivers/usb/dwc3/gadget.c:2015:9: 'trb' may be used uninitialized in this function [-Wmaybe-uninitialized] I believe it is a false positive and we always have a valid 'trb' pointer at the end of the function, but neither I nor the compiler are able to prove that. This works around the warning by computing a flag earlier in the function when it's guaranteed to be valid, which tells the compiler that it's safe and makes it easier to understand to me. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 31162af447d7 ("usb: dwc3: gadget: avoid while (1) loop on completion") Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-09-05Revert "usb: dwc3: gadget: always decrement by 1"John Youn
This reverts commit 6f8245b4e37c ("usb: dwc3: gadget: always decrement by 1"). We can't always decrement this value. We should decrement only if the calculation of free slots results in a LINK TRB being among one of the free slots (dequeue < enqueue). Otherwise, if the LINK TRB is not among the free slots then it should not be decremented. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-25usb: dwc3: gadget: always decrement by 1Felipe Balbi
We need to decrement in both cases (enq > deq and enq < deq) Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-25usb: dwc3: gadget: stop kicking if we run out of spaceFelipe Balbi
In case our TRB ring is full, we can avoid trying to kick transfers which won't start and just add requests to the queue. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-25usb: dwc3: gadget: abolish trbs_leftFelipe Balbi
Instead, we can always rely on dwc3_calc_trbs_left() directly. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-25usb: dwc3: Add ENDXFER command pollingJohn Youn
ENDXFER polling is available on version 3.10a and later of the DWC_usb3 (USB 3.0) controller. With this feature, the software can poll the CMDACT bit in the DEPCMD register after issuing an ENDXFER command. This feature is enabled by writing GUCTL2[14]. This feature is NOT available on the DWC_usb31 (USB 3.1) IP. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-25usb: dwc3: gadget: improve increment request->actualFelipe Balbi
No functional changes, just a slight cosmetic change. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-25usb: dwc3: gadget: remove condition that never happensFelipe Balbi
We don't use LST bit anymore, so this condition will never trigger. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-25usb: dwc3: gadget: add remaining sg entries to ringFelipe Balbi
Upon transfer completion after a full ring, let's add more TRBs to our ring in order to complete our request successfully. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-22usb: dwc3: gadget: interrupt on ring full tooFelipe Balbi
If the ring is full and we are processing a big sglist, then let's interrupt so we can, later, add more TRBs to the ring. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-22usb: dwc3: gadget: avoid while (1) loop on completionFelipe Balbi
We know that we have to iterate over the list of started requests. Instead of looping forever, we can rely on list_for_each_entry(). Likewise, instead of a do {} while loop over all, maybe available, scatterlist entries, we can detect if $this request uses scatterlist and rely on for_each_sg(). This makes the code easier to follow while making sure that we will *always* break out of the loop. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-22usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()Felipe Balbi
Many of the comments in that function are really outdated and don't match what the driver is doing. Moreover, recent patches combined programming model for all non-control endpoints, this gives us an opportunity to get rid of our special cases in __dwc3_gadget_ep_queue(). Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-22usb: dwc3: gadget: simplify dwc3_ep_prev_trb()Felipe Balbi
We always need to decrement our index by at least one. Simplify the implementation by using a temporary local variable and making sure that we will always decrement one extra if tmp == 0. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-22usb: dwc3: gadget: increment dequeue pointer on completionFelipe Balbi
Instead of waiting until giveback before incrementing the dequeue pointer, we can increment it from dwc3_cleanup_done_reqs(), that way we avoid an extra loop over all TRBs during giveback. While at that, also avoid using req->first_trb_index as that's completely unnecessary. A follow-up patch will clean up further uses of that and remove the field altogether. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-22usb: dwc3: gadget: retire LST bit completelyFelipe Balbi
The only endpoint which actually requires LST bit and XferComplete is ep0/1. Let's save some time by completely removing LST bit support and XferComplete. This simplifies and consolidates endpoint handling for all other 3 transfer types while also avoiding extra interrupts. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-22usb: dwc3: gadget: don't rely on jiffies while holding spinlockNicolas Saenz Julienne
__dwc3_gadget_wakeup() is called while holding a spinlock, then depends on jiffies in order to timeout while polling the USB core for a link state update. In the case the wakeup failed, the timeout will never happen and will also cause the cpu to stall until rcu_preempt kicks in. This switches to a "decrement variable and wait" timeout scheme. Signed-off-by: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-11usb: dwc3: gadget: stop processing on HWO setFelipe Balbi
stop consuming TRBs when we reach one with HWO bit already set. This will prevent us from prematurely retiring a TRB. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-11usb: dwc3: don't set last bit for ISOC endpointsJanusz Dziedzic
According to Synopsys Databook 2.60a, section 8.3.4, it's stated that: The LST bit should be set to 0 (isochronous transfers normally continue until the endpoint is removed entirely, at which time an End Transfer command is used to stop the transfer). This patch makes sure that detail is observed and fixes a regression with Android Audio playback caused by recent changes to DWC3 gadget. Signed-off-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-10usb: dwc3: gadget: always cleanup all TRBsFelipe Balbi
If we stop earlier due to short packet, we will not be able to giveback all TRBs. Cc: <stable@vger.kernel.org> Cc: Brian E Rogers <brian.e.rogers@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-07 15:17:03 +0000