aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb/dwc3/gadget.c
AgeCommit message (Collapse)AuthorFilesLines
2020-05-05usb: dwc3: gadget: Give back staled requestsThinh Nguyen1-1/+14
If a request is dequeued, the transfer is cancelled. Give back all the started requests. In most scenarios, the function driver dequeues all requests of a transfer when there's a failure. If the function driver follows this, then it's fine. If not, then we'd be skipping TRBs at different points within the dequeue and enqueue pointers, making dequeue/enqueue pointers useless. To enforce and make sure that we're properly skipping TRBs, cancel all the started requests and give back all the cancelled requests to the function drivers. Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-05-05usb: dwc3: gadget: Properly handle ClearFeature(halt)Thinh Nguyen1-3/+33
DWC3 must not issue CLEAR_STALL command to control endpoints. The controller automatically clears the STALL when it receives the SETUP token. Also, when the driver receives ClearFeature(halt_ep), DWC3 must stop any active transfer from the endpoint and give back all the requests to the function drivers. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-04-17usb: dwc3: gadget: Fix request completion checkThinh Nguyen1-10/+2
A request may not be completed because not all the TRBs are prepared for it. This happens when we run out of available TRBs. When some TRBs are completed, the driver needs to prepare the rest of the TRBs for the request. The check dwc3_gadget_ep_request_completed() shouldn't be checking the amount of data received but rather the number of pending TRBs. Revise this request completion check. Cc: [email protected] Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-04-16usb: dwc3: gadget: Do link recovery for SS and SSPThinh Nguyen1-6/+2
The controller always supports link recovery for device in SS and SSP. Remove the speed limit check. Also, when the device is in RESUME or RESET state, it means the controller received the resume/reset request. The driver must send the link recovery to acknowledge the request. They are valid states for the driver to send link recovery. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Fixes: ee5cd41c9117 ("usb: dwc3: Update speed checks for SuperSpeedPlus") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-04-16usb: dwc3: gadget: Properly set maxpacket limitThinh Nguyen1-11/+41
Currently the calculation of max packet size limit for IN endpoints is too restrictive. This prevents a matching of a capable hardware endpoint during configuration. Below is the minimum recommended HW configuration to support a particular endpoint setup from the databook: For OUT endpoints, the databook recommended the minimum RxFIFO size to be at least 3x MaxPacketSize + 3x setup packets size (8 bytes each) + clock crossing margin (16 bytes). For IN endpoints, the databook recommended the minimum TxFIFO size to be at least 3x MaxPacketSize for endpoints that support burst. If the endpoint doesn't support burst or when the device is operating in USB 2.0 mode, a minimum TxFIFO size of 2x MaxPacketSize is recommended. Base on these recommendations, we can calculate the MaxPacketSize limit of each endpoint. This patch revises the IN endpoint MaxPacketSize limit and also sets the MaxPacketSize limit for OUT endpoints. Reference: Databook 3.30a section 3.2.2 and 3.2.3 Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-04-16usb: dwc3: Fix GTXFIFOSIZ.TXFDEP macro nameThinh Nguyen1-2/+2
Change the macro name DWC3_GTXFIFOSIZ_TXFDEF to DWC3_GTXFIFOSIZ_TXFDEP to match with the register name GTXFIFOSIZ.TXFDEP. Fixes: 457e84b6624b ("usb: dwc3: gadget: dynamically re-size TxFifos") Fixes: 0cab8d26d6e5 ("usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-03-15usb: dwc3: gadget: Wrap around when skip TRBsThinh Nguyen1-1/+1
When skipping TRBs, we need to account for wrapping around the ring buffer and not modifying some invalid TRBs. Without this fix, dwc3 won't be able to check for available TRBs. Cc: stable <[email protected]> Fixes: 7746a8dfb3f9 ("usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-03-15usb: dwc3: gadget: Don't clear flags before transfer endedThinh Nguyen1-3/+1
We track END_TRANSFER command completion. Don't clear transfer started/ended flag prematurely. Otherwise, we'd run into the problem with restarting transfer before END_TRANSFER command finishes. Fixes: 6d8a019614f3 ("usb: dwc3: gadget: check for Missed Isoc from event status") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-03-04usb: dwc3: gadget: Update chain bit correctly when using sg listPratham Pratap1-1/+8
If scatter-gather operation is allowed, a large USB request is split into multiple TRBs. For preparing TRBs for sg list, driver iterates over the list and creates TRB for each sg and mark the chain bit to false for the last sg. The current IOMMU driver is clubbing the list of sgs which shares a page boundary into one and giving it to USB driver. With this the number of sgs mapped it not equal to the the number of sgs passed. Because of this USB driver is not marking the chain bit to false since it couldn't iterate to the last sg. This patch addresses this issue by marking the chain bit to false if it is the last mapped sg. At a practical level, this patch resolves USB transfer stalls seen with adb on dwc3 based db845c, pixel3 and other qcom hardware after functionfs gadget added scatter-gather support around v4.20. Credit also to Anurag Kumar Vulisha <[email protected]> who implemented a very similar fix to this issue. Cc: Felipe Balbi <[email protected]> Cc: Yang Fei <[email protected]> Cc: Thinh Nguyen <[email protected]> Cc: Tejas Joglekar <[email protected]> Cc: Andrzej Pietrasiewicz <[email protected]> Cc: Jack Pham <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Greg KH <[email protected]> Cc: Linux USB List <[email protected]> Cc: stable <[email protected]> #4.20+ Signed-off-by: Pratham Pratap <[email protected]> [jstultz: Slight tweak to remove sg_is_last() usage, reworked commit message, minor comment tweak] Signed-off-by: John Stultz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-02-11usb: dwc3: gadget: Check for IOC/LST bit in TRB->ctrl fieldsAnurag Kumar Vulisha1-1/+2
The current code in dwc3_gadget_ep_reclaim_completed_trb() will check for IOC/LST bit in the event->status and returns if IOC/LST bit is set. This logic doesn't work if multiple TRBs are queued per request and the IOC/LST bit is set on the last TRB of that request. Consider an example where a queued request has multiple queued TRBs and IOC/LST bit is set only for the last TRB. In this case, the core generates XferComplete/XferInProgress events only for the last TRB (since IOC/LST are set only for the last TRB). As per the logic in dwc3_gadget_ep_reclaim_completed_trb() event->status is checked for IOC/LST bit and returns on the first TRB. This leaves the remaining TRBs left unhandled. Similarly, if the gadget function enqueues an unaligned request with sglist already in it, it should fail the same way, since we will append another TRB to something that already uses more than one TRB. To aviod this, this patch changes the code to check for IOC/LST bits in TRB->ctrl instead. At a practical level, this patch resolves USB transfer stalls seen with adb on dwc3 based HiKey960 after functionfs gadget added scatter-gather support around v4.20. Cc: Felipe Balbi <[email protected]> Cc: Yang Fei <[email protected]> Cc: Thinh Nguyen <[email protected]> Cc: Tejas Joglekar <[email protected]> Cc: Andrzej Pietrasiewicz <[email protected]> Cc: Jack Pham <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Greg KH <[email protected]> Cc: Linux USB List <[email protected]> Cc: stable <[email protected]> Tested-by: Tejas Joglekar <[email protected]> Reviewed-by: Thinh Nguyen <[email protected]> Signed-off-by: Anurag Kumar Vulisha <[email protected]> [jstultz: forward ported to mainline, reworded commit log, reworked to only check trb->ctrl as suggested by Felipe] Signed-off-by: John Stultz <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2020-01-15usb: dwc3: gadget: Remove END_TRANSFER delayThinh Nguyen1-13/+5
We had a 100us delay to synchronize the END_TRANSFER command completion before giving back requests to the function drivers. Now, the controller driver can handle cancelled TRBs with the requests' cancelled_list and it can also wait until the END_TRANSFER completion before starting new transfers. Synchronization can simply base on the controller's command completion interrupt. The 100us delay is no longer needed. Remove this arbitrary delay. Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-15usb: dwc3: gadget: Delay starting transferThinh Nguyen1-0/+11
If the END_TRANSFER command hasn't completed yet, then don't send the START_TRANSFER command. The controller may not be able to start if that's the case. Some controller revisions depend on this. See commit 76a638f8ac0d ("usb: dwc3: gadget: wait for End Transfer to complete"). Let's only send START_TRANSFER command after the END_TRANSFER command had completed. Fixes: 3aec99154db3 ("usb: dwc3: gadget: remove DWC3_EP_END_TRANSFER_PENDING") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-15usb: dwc3: gadget: Check END_TRANSFER completionThinh Nguyen1-1/+5
While the END_TRANSFER command is sent but not completed, any request dequeue during this time will cause the driver to issue the END_TRANSFER command. The driver needs to submit the command only once to stop the controller from processing further. The controller may take more time to process the same command multiple times unnecessarily. Let's add a flag DWC3_EP_END_TRANSFER_PENDING to check for this condition. Fixes: 3aec99154db3 ("usb: dwc3: gadget: remove DWC3_EP_END_TRANSFER_PENDING") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-15usb: dwc3: gadget: Clear DCTL.ULSTCHNGREQ before setThinh Nguyen1-0/+3
Send a no-action link state change request before the actual request so DWC3 can send the same request whenever we call dwc3_gadget_set_link_state(). Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-15usb: dwc3: gadget: Set link state to RX_Detect on disconnectThinh Nguyen1-0/+2
When DWC3 receives disconnect event, it needs to set the link state to RX_Detect. DWC_usb3 3.30a programming guide 4.1.7 Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-15usb: dwc3: gadget: Don't send unintended link state changeThinh Nguyen1-9/+7
DCTL.ULSTCHNGREQ is a write-only field. When doing a read-modify-write to DCTL, the driver must make sure that there's no unintended link state change request from whatever is read from DCTL.ULSTCHNGREQ. Set link state change to no-action when the driver writes to DCTL. Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-30usb: dwc3: gadget: Fix request complete checkThinh Nguyen1-0/+7
We can only check for IN direction if the request had completed. For OUT direction, it's perfectly fine that the host can send less than the setup length. Let's return true fall all cases of OUT direction. Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling") Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/ac5a3593a94fdaa3d92e6352356b5f7a01ccdc7c.1576291140.git.thinhn@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-10usb: dwc3: gadget: Clear started flag for non-IOCThinh Nguyen1-0/+3
Normally the END_TRANSFER command completion handler will clear the DWC3_EP_TRANSFER_STARTED flag. However, if the command was sent without interrupt on completion, then the flag will not be cleared. Make sure to clear the flag in this case. Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-12-10usb: dwc3: gadget: Fix logical conditionTejas Joglekar1-1/+1
This patch corrects the condition to kick the transfer without giving back the requests when either request has remaining data or when there are pending SGs. The && check was introduced during spliting up the dwc3_gadget_ep_cleanup_completed_requests() function. Fixes: f38e35dd84e2 ("usb: dwc3: gadget: split dwc3_gadget_ep_cleanup_completed_requests()") Cc: [email protected] Signed-off-by: Tejas Joglekar <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-10-31usb: dwc3: gadget: fix race when disabling ep with cancelled xfersFelipe Balbi1-0/+6
When disabling an endpoint which has cancelled requests, we should make sure to giveback requests that are currently pending in the cancelled list, otherwise we may fall into a situation where command completion interrupt fires after endpoint has been disabled, therefore causing a splat. Fixes: fec9095bdef4 "usb: dwc3: gadget: remove wait_end_transfer" Reported-by: Roger Quadros <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-07usb: dwc3: Remove dev_err() on platform_get_irq() failureHans de Goede1-3/+0
Since commit 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()"), platform_get_irq() will call dev_err() itself on failure, so there is no need for the driver to also do this. Signed-off-by: Hans de Goede <[email protected]> Acked-by: Felipe Balbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-10-07usb: dwc3: Switch to platform_get_irq_byname_optional()Hans de Goede1-2/+2
The dwc3 code to get the "peripheral" / "host" / "otg" IRQ first tries platform_get_irq_byname() and then falls back to the IRQ at index 0 if the platform_get_irq_byname(). In this case we do not want platform_get_irq_byname() to print an error on failure, so switch to platform_get_irq_byname_optional() instead which does not print an error. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205037 Signed-off-by: Hans de Goede <[email protected]> Acked-by: Felipe Balbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-08-30usb: dwc3: gadget: Workaround Mirosoft's BESL checkThinh Nguyen1-2/+12
While testing our host system using Microsoft's usb stack against our gadget for various BESL values, we found an issue with their usb stack when the recommended baseline BESL value is 0 (125us) or when the deep BESL is 1 or less. The Windows host will issue a usb reset immediately after it receives the extended BOS descriptor and the enumeration will fail after a few attempts. To keep compatibility with Microsoft's host usb stack, let's workaround this issue by using the recommended baseline BESL of 1 (or 150us) and clamp the deep BESL value within 2 to 15. This was tested against Windows 10 build 18956. Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-08-28usb: dwc3: gadget: Set BESL config parameterThinh Nguyen1-0/+10
When operating with LPM signals, the controller asserts the deep low-power signal (utmi_l1_suspend_n) to the phy when the BESL value of the LPM token is equal to or greater than DCTL.HIRD_Thres[3:0] (and with DCTL.HIRD_Thres[4] set). Otherwise, the shallow low-power signal (utmi_sleep_n) is asserted. Set the recommended deep BESL equal to the controller's DCTL.HIRD_Thres[3:0] setting, and set the baseline BESL to 0 for the shallow low-power signal. This maximizes the opportunity for L1 residency and optimizes power savings. Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-08-28usb: dwc3: Separate field holding multiple propertiesThinh Nguyen1-1/+2
dwc->hird_threshold field should store "snps,hird_threshold" property only and not a combination of multiple properties. Remove the value of "snps,is-utmi-l1-suspend" property from the field dwc->hird_threshold. Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-08-28usb: dwc3: don't set gadget->is_otg flagRoger Quadros1-1/+0
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 <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-06-20usb: dwc3: remove unused @lock member of dwc3_ep structChunfeng Yun1-2/+0
The member @lock of dwc3_ep struct is only initialized, and not used elsewhere, so remove it. Signed-off-by: Chunfeng Yun <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-06-18usb: dwc3: gadget: Add support for disabling U1 and U2 entriesAnurag Kumar Vulisha1-0/+20
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: Anurag Kumar Vulisha <[email protected]> Signed-off-by: Claus H. Stovgaard <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-05-03usb: dwc3: Rename DWC3_DCTL_LPM_ERRATAThinh Nguyen1-1/+1
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: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-05-03usb: dwc3: gadget: Set lpm_capableThinh Nguyen1-0/+1
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: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-05-03usb: dwc3: move synchronize_irq() out of the spinlock protected blockMarek Szyprowski1-2/+0
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: 01c10880d242 ("usb: dwc3: gadget: synchronize_irq dwc irq in suspend") Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-02-15Merge tag 'usb-for-v5.1' of ↵Greg Kroah-Hartman1-31/+34
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Felipe writes: USB: changes for v5.1 merge window Dwc3 now works on TI's AM6xx platforms. Also on dwc3 we have a few changes which improve request cancellation and some improvements to how we print to the trace buffer. Renesas_usb3 got support for r8a774c0 device. Dwc2 got scatter-gather support. Apart from these, the usual set of minor fixes and all sorts of small details. * tag 'usb-for-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (40 commits) usb: phy: twl6030-usb: fix possible use-after-free on remove usb: misc: usbtest: add super-speed isoc support usb: dwc3: Reset num_trbs after skipping usb: dwc3: gadget: don't enable interrupt when disabling endpoint fotg210-udc: pass struct device to DMA API functions fotg210-udc: remove a bogus dma_sync_single_for_device call usb: gadget: Change Andrzej Pietrasiewicz's e-mail address usb: f_fs: Avoid crash due to out-of-scope stack ptr access usb: dwc3: haps: Workaround matching VID PID usb: gadget: f_fs: preserve wMaxPacketSize across usb_ep_autoconfig() call usb: gadget: move non-super speed code out of usb_ep_autoconfig_ss() usb: gadget: function: sync f_uac1 ac header baInterfaceNr usb: dwc2: gadget: Add scatter-gather mode usb: gadget: fix various indentation issues usb: dwc2: Fix EP TxFIFO number setting udc: net2280: Fix net2280_disable USB: gadget: Improve kerneldoc for usb_ep_dequeue() usb: dwc3: debug: purge usage of strcat usb: dwc3: trace: pass trace buffer size to decoding functions usb: dwc3: gadget: remove DWC3_EP_END_TRANSFER_PENDING ...
2019-02-13usb: dwc3: Reset num_trbs after skippingThinh Nguyen1-0/+2
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: c3acd5901414 ("usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()") Signed-off-by: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-02-13usb: dwc3: gadget: don't enable interrupt when disabling endpointFelipe Balbi1-7/+9
Since we're disabling the endpoint anyway, we don't worry about getting endpoint command completion interrupt. Signed-off-by: Felipe Balbi <[email protected]>
2019-02-04usb: dwc3: gadget: remove DWC3_EP_END_TRANSFER_PENDINGFelipe Balbi1-10/+5
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: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-02-04usb: dwc3: gadget: early giveback if End Transfer already completedFelipe Balbi1-1/+5
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: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-02-04usb: dwc3: gadget: don't use resource_index as a flagFelipe Balbi1-2/+2
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: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-02-01usb: dwc3: gadget: clear DWC3_EP_TRANSFER_STARTED on cmd completeFelipe Balbi1-14/+5
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: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-01-28usb: dwc3: gadget: Handle 0 xfer length for OUT EPTejas Joglekar1-1/+1
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: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: [email protected] Signed-off-by: Tejas Joglekar <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-01-28usb: dwc3: gadget: remove req->started flagFelipe Balbi1-1/+0
Now that we have req->status, we don't need this extra flag anymore. It's safe to remove it. Signed-off-by: Felipe Balbi <[email protected]>
2019-01-28usb: dwc3: gadget: prevent dwc3_request from being queued twiceFelipe Balbi1-0/+5
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: Felipe Balbi <[email protected]>
2019-01-28usb: dwc3: gadget: add dwc3_request status trackingFelipe Balbi1-0/+3
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: Felipe Balbi <[email protected]>
2019-01-28usb: dwc3: gadget: Fix OTG events when gadget driver isn't loadedRoger Quadros1-0/+2
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: Roger Quadros <[email protected]> Signed-off-by: Sekhar Nori <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-01-14usb: dwc3: gadget: Fix the uninitialized link_state when udc startsZeng Tao1-0/+1
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 <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-01-14usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanupJack Pham1-0/+1
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: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: [email protected] Signed-off-by: Jack Pham <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2019-01-14usb: dwc3: gadget: synchronize_irq dwc irq in suspendBo He1-0/+2
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 <[email protected]> Signed-off-by: Yu Wang <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2018-12-12Merge tag 'usb-for-v4.21' of ↵Greg Kroah-Hartman1-120/+222
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Felipe writes: USB changes for v4.21 So it looks like folks are interested in dwc3 again. Almost 64% of the changes are in dwc3 this time around with some other bits in gadget functions and dwc2. There are two important parts here: a. removal of the waitqueue from dwc3's dequeue implementation, which will guarantee that gadget functions can dequeue from any context and; b. better method for starting isochronous transfers to avoid, as much as possible, missed isoc frames. Apart from these, we have the usual set of non-critical fixes and new features all over the place. * tag 'usb-for-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (56 commits) usb: dwc2: Fix disable all EP's on disconnect usb: dwc3: gadget: Disable CSP for stream OUT ep usb: dwc2: disable power_down on Amlogic devices Revert "usb: dwc3: pci: Use devm functions to get the phy GPIOs" USB: gadget: udc: s3c2410_udc: convert to DEFINE_SHOW_ATTRIBUTE usb: mtu3: fix dbginfo in qmu_tx_zlp_error_handler usb: dwc3: trace: add missing break statement to make compiler happy usb: dwc3: gadget: Report isoc transfer frame number usb: gadget: Introduce frame_number to usb_request usb: renesas_usbhs: Use SIMPLE_DEV_PM_OPS macro usb: renesas_usbhs: Remove dummy runtime PM callbacks usb: dwc2: host: use hrtimer for NAK retries usb: mtu3: clear SOFTCONN when clear USB3_EN if work as HS mode usb: mtu3: enable SETUPENDISR interrupt usb: mtu3: fix the issue about SetFeature(U1/U2_Enable) usb: mtu3: enable hardware remote wakeup from L1 automatically usb: mtu3: remove QMU checksum usb/mtu3: power down device ip at setup usb: dwc2: Disable power down feature on Samsung SoCs usb: dwc3: Correct the logic for checking TRB full in __dwc3_prepare_one_trb() ...
2018-12-10usb: dwc3: gadget: Disable CSP for stream OUT epTejas Joglekar1-2/+6
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: Tejas Joglekar <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2018-12-05usb: dwc3: gadget: Report isoc transfer frame numberThinh Nguyen1-0/+13
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: Thinh Nguyen <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2018-12-05usb: dwc3: Correct the logic for checking TRB full in __dwc3_prepare_one_trb()Anurag Kumar Vulisha1-3/+3
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: Anurag Kumar Vulisha <[email protected]> Reviewed-by: Thinh Nguyen <[email protected]> Tested-by: Tejas Joglekar <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.