- 20 6月, 2019 1 次提交
-
-
由 Chunfeng Yun 提交于
The member @lock of dwc3_ep struct is only initialized, and not used elsewhere, so remove it. Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 18 6月, 2019 1 次提交
-
-
由 Anurag Kumar Vulisha 提交于
Gadget applications may have a requirement to disable the U1 and U2 entry based on the usecase. Below are few usecases where the disabling U1/U2 entries may be possible. Usecase 1: When combining dwc3 with an redriver for a USB Type-C device solution, it sometimes have problems with leaving U1/U2 for certain hosts, resulting in link training errors and reconnects. For this U1/U2 state entries may be avoided. Usecase 2: When performing performance benchmarking on mass storage gadget the U1 and U2 entries can be disabled. Usecase 3: When periodic transfers like ISOC transfers are used with bInterval of 1 which doesn't require the link to enter into U1 or U2 state entry (since ping is issued from host for every uframe interval). In this case the U1 and U2 entry can be disabled. Disablement of U1/U2 can be done by setting U1DevExitLat and U2DevExitLat values to 0 in the BOS descriptor. Host on seeing 0 value for U1DevExitLat and U2DevExitLat, it doesn't send SET_SEL requests to the gadget. There may be some hosts which may send SET_SEL requests even after seeing 0 in the UxDevExitLat of BOS descriptor. To aviod U1/U2 entries for these type of hosts, dwc3 controller can be programmed to reject those U1/U2 requests by not enabling ACCEPTUxENA bits in DCTL register. This patch updates the same. Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com> Signed-off-by: NClaus H. Stovgaard <cst@phaseone.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 03 5月, 2019 3 次提交
-
-
由 Thinh Nguyen 提交于
The macro name DWC3_DCTL_LPM_ERRATA is uninformative and does not do masking. Remove DWC3_DCTL_LPM_ERRATA_MASK and rename DWC3_DCTL_LPM_ERRATA to DWC3_DCTL_NYET_THRES with proper masking. Signed-off-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Thinh Nguyen 提交于
All DWC3 controllers are LPM capable. Report that in the usb_gadget.lpm_capable for the gadget driver to properly output the bcdUSB value in the descriptor. Signed-off-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Marek Szyprowski 提交于
dwc3_gadget_suspend() is called under dwc->lock spinlock. In such context calling synchronize_irq() is not allowed. Move the problematic call out of the protected block to fix the following kernel BUG during system suspend: BUG: sleeping function called from invalid context at kernel/irq/manage.c:112 in_atomic(): 1, irqs_disabled(): 128, pid: 1601, name: rtcwake 6 locks held by rtcwake/1601: #0: f70ac2a2 (sb_writers#7){.+.+}, at: vfs_write+0x130/0x16c #1: b5fe1270 (&of->mutex){+.+.}, at: kernfs_fop_write+0xc0/0x1e4 #2: 7e597705 (kn->count#60){.+.+}, at: kernfs_fop_write+0xc8/0x1e4 #3: 8b3527d0 (system_transition_mutex){+.+.}, at: pm_suspend+0xc4/0xc04 #4: fc7f1c42 (&dev->mutex){....}, at: __device_suspend+0xd8/0x74c #5: 4b36507e (&(&dwc->lock)->rlock){....}, at: dwc3_gadget_suspend+0x24/0x3c irq event stamp: 11252 hardirqs last enabled at (11251): [<c09c54a4>] _raw_spin_unlock_irqrestore+0x6c/0x74 hardirqs last disabled at (11252): [<c09c4d44>] _raw_spin_lock_irqsave+0x1c/0x5c softirqs last enabled at (9744): [<c0102564>] __do_softirq+0x3a4/0x66c softirqs last disabled at (9737): [<c0128528>] irq_exit+0x140/0x168 Preemption disabled at: [<00000000>] (null) CPU: 7 PID: 1601 Comm: rtcwake Not tainted 5.0.0-rc3-next-20190122-00039-ga3f4ee4f8a52 #5252 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c01110f0>] (unwind_backtrace) from [<c010d120>] (show_stack+0x10/0x14) [<c010d120>] (show_stack) from [<c09a4d04>] (dump_stack+0x90/0xc8) [<c09a4d04>] (dump_stack) from [<c014c700>] (___might_sleep+0x22c/0x2c8) [<c014c700>] (___might_sleep) from [<c0189d68>] (synchronize_irq+0x28/0x84) [<c0189d68>] (synchronize_irq) from [<c05cbbf8>] (dwc3_gadget_suspend+0x34/0x3c) [<c05cbbf8>] (dwc3_gadget_suspend) from [<c05bd020>] (dwc3_suspend_common+0x154/0x410) [<c05bd020>] (dwc3_suspend_common) from [<c05bd34c>] (dwc3_suspend+0x14/0x2c) [<c05bd34c>] (dwc3_suspend) from [<c051c730>] (platform_pm_suspend+0x2c/0x54) [<c051c730>] (platform_pm_suspend) from [<c05285d4>] (dpm_run_callback+0xa4/0x3dc) [<c05285d4>] (dpm_run_callback) from [<c0528a40>] (__device_suspend+0x134/0x74c) [<c0528a40>] (__device_suspend) from [<c052c508>] (dpm_suspend+0x174/0x588) [<c052c508>] (dpm_suspend) from [<c0182134>] (suspend_devices_and_enter+0xc0/0xe74) [<c0182134>] (suspend_devices_and_enter) from [<c0183658>] (pm_suspend+0x770/0xc04) [<c0183658>] (pm_suspend) from [<c0180ddc>] (state_store+0x6c/0xcc) [<c0180ddc>] (state_store) from [<c09a9a70>] (kobj_attr_store+0x14/0x20) [<c09a9a70>] (kobj_attr_store) from [<c02d6800>] (sysfs_kf_write+0x4c/0x50) [<c02d6800>] (sysfs_kf_write) from [<c02d594c>] (kernfs_fop_write+0xfc/0x1e4) [<c02d594c>] (kernfs_fop_write) from [<c02593d8>] (__vfs_write+0x2c/0x160) [<c02593d8>] (__vfs_write) from [<c0259694>] (vfs_write+0xa4/0x16c) [<c0259694>] (vfs_write) from [<c0259870>] (ksys_write+0x40/0x8c) [<c0259870>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xed55ffa8 to 0xed55fff0) ... Fixes: 01c10880 ("usb: dwc3: gadget: synchronize_irq dwc irq in suspend") Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 13 2月, 2019 2 次提交
-
-
由 Thinh Nguyen 提交于
Currently req->num_trbs is not reset after the TRBs are skipped and processed from the cancelled list. The gadget driver may reuse the request with an invalid req->num_trbs, and DWC3 will incorrectly skip trbs. To fix this, simply reset req->num_trbs to 0 after skipping through all of them. Fixes: c3acd590 ("usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()") Signed-off-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Since we're disabling the endpoint anyway, we don't worry about getting endpoint command completion interrupt. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 04 2月, 2019 3 次提交
-
-
由 Felipe Balbi 提交于
Now that we modified the code to fix a race condition, it's clear that DWC3_EP_END_TRANSFER_PENDING is unnecessary, considering that DWC3_EP_TRANSFER_STARTED will remain set until End Transfer completes. Tested-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
There is a rare race condition that may happen during a Disconnect Interrupt if we have a started request that happens to be dequeued *after* completion of End Transfer command. If that happens, that request will be left waiting for completion of an End Transfer command that will never happen. If End Transfer command has already completed before, we are safe to giveback the request straight away. Tested-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
We have a proper flag for testing that we have a valid transfer in flight, let's use that instead. This patch is in preparation to fix a rare race condition that happens upon Disconnect Interrupt. Tested-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 01 2月, 2019 1 次提交
-
-
由 Felipe Balbi 提交于
We must wait until End Transfer completes in order to clear DWC3_EP_TRANSFER_STARTED, otherwise we may confuse the driver. This patch is in preparation to fix a rare race condition that happens upon Disconnect Interrupt. Tested-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 28 1月, 2019 5 次提交
-
-
由 Tejas Joglekar 提交于
For OUT endpoints, zero-length transfers require MaxPacketSize buffer as per the DWC_usb3 programming guide 3.30a section 4.2.3.3. This patch fixes this by explicitly checking zero length transfer to correctly pad up to MaxPacketSize. Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable@vger.kernel.org Signed-off-by: NTejas Joglekar <joglekar@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Now that we have req->status, we don't need this extra flag anymore. It's safe to remove it. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Queueing the same request twice can introduce hard-to-debug problems. At least one function driver - Android's f_mtp.c - is known to cause this problem. While that function is out-of-tree, this is a problem that's easy enough to avoid. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
This patch starts tracking dwc3_request status. A following patch will build on top of this to prevent a request from being queued twice. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Roger Quadros 提交于
On v3.10a in dual-role mode, if port is in device mode and gadget driver isn't loaded, the OTG event interrupts don't come through. It seems that if the core is configured to be OTG2.0 only, then we can't leave the DCFG.DEVSPD at Super-speed (default) if we expect OTG to work properly. It must be set to High-speed. Fix this issue by configuring DCFG.DEVSPD to the supported maximum speed at gadget init. Device tree still needs to provide correct supported maximum speed for this to work. This issue wasn't present on v2.40a but is seen on v3.10a. It doesn't cause any side effects on v2.40a. Signed-off-by: NRoger Quadros <rogerq@ti.com> Signed-off-by: NSekhar Nori <nsekhar@ti.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 14 1月, 2019 3 次提交
-
-
由 Zeng Tao 提交于
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: NZeng Tao <prime.zeng@hisilicon.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Jack Pham 提交于
OUT endpoint requests may somtimes have this flag set when preparing to be submitted to HW indicating that there is an additional TRB chained to the request for alignment purposes. If that request is removed before the controller can execute the transfer (e.g. ep_dequeue/ep_disable), the request will not go through the dwc3_gadget_ep_cleanup_completed_request() handler and will not have its needs_extra_trb flag cleared when dwc3_gadget_giveback() is called. This same request could be later requeued for a new transfer that does not require an extra TRB and if it is successfully completed, the cleanup and TRB reclamation will incorrectly process the additional TRB which belongs to the next request, and incorrectly advances the TRB dequeue pointer, thereby messing up calculation of the next requeust's actual/remaining count when it completes. The right thing to do here is to ensure that the flag is cleared before it is given back to the function driver. A good place to do that is in dwc3_gadget_del_and_unmap_request(). Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable@vger.kernel.org Signed-off-by: NJack Pham <jackp@codeaurora.org> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Bo He 提交于
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: NBo He <bo.he@intel.com> Signed-off-by: NYu Wang <yu.y.wang@intel.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 10 12月, 2018 1 次提交
-
-
由 Tejas Joglekar 提交于
In stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. So we don't want controller to carry on transfers when short packet is received. So disable the CSP for stream capable endpoint. This is based on the 3.30a Programming guide, where table 3-1 device descriptor structure field definitions says for CSP bit If this bit is 0, the controller generates an XferComplete event and remove the stream. So if we keep CSP as 1 then switching between streams would not happen as in stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. Signed-off-by: NTejas Joglekar <joglekar@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 05 12月, 2018 4 次提交
-
-
由 Thinh Nguyen 提交于
Implement the new frame_number API to report the isochronous interval frame number. This patch checks and reports the interval in which the isoc transfer was transmitted or received via the Isoc-First TRB SOF number field. Signed-off-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Anurag Kumar Vulisha 提交于
Availability of TRB's is calculated using dwc3_calc_trbs_left(), which determines total available TRB's based on the HWO bit set in a TRB. In the present code, __dwc3_prepare_one_trb() is called with a TRB which needs to be prepared for transfer. This __dwc3_prepare_one_trb() calls dwc3_calc_trbs_left() to determine total available TRBs and set IOC bit if the total available TRBs are zero. Since the present working TRB (which is passed as an argument to __dwc3_prepare_one_trb() ) doesn't yet have the HWO bit set before calling dwc3_calc_trbs_left(), there are chances that dwc3_calc_trbs_left() wrongly calculates this present working TRB as free(since the HWO bit is not yet set) and returns the total available TRBs as greater than zero (including the present working TRB). This could be a problem. This patch corrects the above mentioned problem in __dwc3_prepare_one_trb() by increementing the dep->trb_enqueue at the last (after preparing the TRB) instead of increementing at the start and setting the IOC bit only if the total available TRBs returned by dwc3_calc_trbs_left() is 1 . Since we are increementing the dep->trb_enqueue at the last, the present working TRB is also considered as available by dwc3_calc_trbs_left() and non zero value is returned . So, according to the modified logic, when the total available TRBs is equal to 1 that means the total available TRBs in the pool are 0. Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com> Reviewed-by: NThinh Nguyen <thinhn@synopsys.com> Tested-by: NTejas Joglekar <tejas.joglekar@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Anurag Kumar Vulisha 提交于
The stream capable endpoints require stream id to be given when issuing START TRANSFER. While issuing no-op trb the stream id is not yet known, so don't issue no-op trb's on stream capable endpoints. Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Anurag Kumar Vulisha 提交于
For stream capable endpoints, stream id related information needs to be updated into DEPCMD while issuing START TRANSFER. This patch does the same. Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 27 11月, 2018 1 次提交
-
-
由 Felipe Balbi 提交于
Gadget driver may take an unbounded amount of time to queue requests after XferNotReady. This is important for isochronous endpoints which need to be started for a specific (micro-)frame. If we fail to start a transfer for isochronous endpoint, let's try queueing to a future interval and see if that helps. We will stop trying if we fail a start transfer for 5 intervals in the future. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 26 11月, 2018 11 次提交
-
-
由 Felipe Balbi 提交于
Running out of requests on isochronous endpoints is part of normal operation. We don't really need to know about it every time it happens. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Sometimes, errors happen when kicking transfers from __dwc3_gadget_start_isoc(). In those cases, we need to pass along the error so gadget driver can make informed decisions. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Now that we have a list of cancelled requests, we can skip over TRBs when END_TRANSFER command completes. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Whenever we have a request in flight, we can move it to the cancelled list and later simply iterate over that list and skip over any TRBs we find. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
This list will host cancelled requests who still have TRBs being processed. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Extract the logic for skipping over TRBs to its own function. This makes the code slightly more readable and makes it easier to move this call to its final resting place as a following patch. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Now that we track how many TRBs a request uses, it's easier to skip over them in case of a call to usb_ep_dequeue(). Let's do so and simplify the code a bit. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
This will help us remove the wait_event() from our ->dequeue(). Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
Both flags are used for the same purpose in dwc3: appending an extra TRB at the end to deal with controller requirements. By combining both flags into one, we make it clear that the situation is the same and that they should be treated equally. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Thinh Nguyen 提交于
In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed isochronous IN, BIT[15:14] of the 16-bit microframe number reported by the XferNotReady event are invalid. The driver uses this number to schedule the isochronous transfer and passes it to the START TRANSFER command. Because this number is invalid, the command may fail. If BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER command will pass and the transfer will start at the scheduled time, if it is off by 1, the command will still pass, but the transfer will start 2 seconds in the future. For all other conditions, the START TRANSFER command will fail with bus-expiry. In order to workaround this issue, we can test for the correct combination of BIT[15:14] by sending START TRANSFER commands with different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11. Each combination is 2^14 uframe apart (or 2 seconds). 4 seconds into the future will result in a bus-expiry status. As the result, within the 4 possible combinations for BIT[15:14], there will be 2 successful and 2 failure START COMMAND status. One of the 2 successful command status will result in a 2-second delay start. The smaller BIT[15:14] value is the correct combination. Since there are only 4 outcomes and the results are ordered, we can simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00 and 'b01 to deduce the smaller successful combination. Let test0 = test status for combination 'b00 and test1 = test status for 'b01 of BIT[15:14]. The correct combination is as follow: if test0 fails and test1 passes, BIT[15:14] is 'b01 if test0 fails and test1 fails, BIT[15:14] is 'b10 if test0 passes and test1 fails, BIT[15:14] is 'b11 if test0 passes and test1 passes, BIT[15:14] is 'b00 Synopsys STAR 9001202023: Wrong microframe number for isochronous IN endpoints. Signed-off-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
由 Felipe Balbi 提交于
This reverts commit ffb80fc6. 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: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 14 11月, 2018 1 次提交
-
-
由 Felipe Balbi 提交于
When chaining ISOC TRBs together, only the first ISOC TRB should be of type ISOC_FIRST, all others should be of type ISOC. This patch fixes that. Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 06 11月, 2018 1 次提交
-
-
由 Thinh Nguyen 提交于
Current check for the last extra TRB for zero and unaligned transfers does not account for isoc OUT. The last TRB of the Buffer Descriptor for isoc OUT transfers will be retired with HWO=0. As a result, we won't return early. The req->remaining will be updated to include the BUFSIZ count of the extra TRB, and the actual number of transferred bytes calculation will be wrong. To fix this, check whether it's a short or zero packet and the last TRB chain bit to return early. Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: <stable@vger.kernel.org> Signed-off-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 02 10月, 2018 1 次提交
-
-
由 Thinh Nguyen 提交于
When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an endpoint command. Current implementation only save and restore GUSB2PHYCFG.SUSPHY configuration. We must save and clear both GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY settings. Restore them after the command is completed. DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2 Signed-off-by: NThinh Nguyen <thinhn@synopsys.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
-
- 05 9月, 2018 1 次提交
-
-
由 Randy Dunlap 提交于
Fix kernel-doc warning: ../drivers/usb/dwc3/gadget.c:510: warning: Excess function parameter 'dwc' description in 'dwc3_gadget_start_config' Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Cc: Felipe Balbi <balbi@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-