summaryrefslogtreecommitdiffstats
path: root/drivers/usb/dwc3
AgeCommit message (Collapse)AuthorFilesLines
2021-01-07usb: dwc3: gadget: Clear wait flag on dequeueThinh Nguyen1-0/+2
If an active transfer is dequeued, then the endpoint is freed to start a new transfer. Make sure to clear the endpoint's transfer wait flag for this case. Fixes: e0d19563eb6c ("usb: dwc3: gadget: Wait for transfer completion") Cc: stable@vger.kernel.org Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b81cd5b5281cfbfdadb002c4bcf5c9be7c017cfd.1609828485.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-04usb: dwc3: gadget: Restart DWC3 gadget when enabling pullupWesley Cheng1-11/+3
usb_gadget_deactivate/usb_gadget_activate does not execute the UDC start operation, which may leave EP0 disabled and event IRQs disabled when re-activating the function. Move the enabling/disabling of USB EP0 and device event IRQs to be performed in the pullup routine. Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the controller") Tested-by: Michael Tretter <m.tretter@pengutronix.de> Cc: stable <stable@vger.kernel.org> Reported-by: Michael Tretter <m.tretter@pengutronix.de> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1609282837-21666-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-28usb: dwc3: ulpi: Fix USB2.0 HS/FS/LS PHY suspend regressionSerge Semin1-13/+5
First of all the commit e0082698b689 ("usb: dwc3: ulpi: conditionally resume ULPI PHY") introduced the Suspend USB2.0 HS/FS/LS PHY regression, as by design of the fix any attempt to read/write from/to the PHY control registers will completely disable the PHY suspension, which consequently will increase the USB bus power consumption. Secondly the fix won't work well for the very first attempt of the ULPI PHY control registers IO, because after disabling the USB2.0 PHY suspension functionality it will still take some time for the bus to resume from the sleep state if one has been reached before it. So the very first PHY register read/write operation will take more time than the busy-loop provides and the IO timeout error might be returned anyway. Here we suggest to fix the denoted problems in the following way. First of all let's not disable the Suspend USB2.0 HS/FS/LS PHY functionality so to make the controller and the USB2.0 bus more power efficient. Secondly instead of that we'll extend the PHY IO op wait procedure with 1 - 1.2 ms sleep if the PHY suspension is enabled (1ms should be enough as by LPM specification it is at most how long it takes for the USB2.0 bus to resume from L1 (Sleep) state). Finally in case if the USB2.0 PHY suspension functionality has been disabled on the DWC USB3 controller setup procedure we'll compensate the USB bus resume process latency by extending the busy-loop attempts counter. Fixes: e0082698b689 ("usb: dwc3: ulpi: conditionally resume ULPI PHY") Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201210085008.13264-4-Sergey.Semin@baikalelectronics.ru Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-28usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based oneSerge Semin1-3/+15
Originally the procedure of the ULPI transaction finish detection has been developed as a simple busy-loop with just decrementing counter and no delays. It's wrong since on different systems the loop will take a different time to complete. So if the system bus and CPU are fast enough to overtake the ULPI bus and the companion PHY reaction, then we'll get to take a false timeout error. Fix this by converting the busy-loop procedure to take the standard bus speed, address value and the registers access mode into account for the busy-loop delay calculation. Here is the way the fix works. It's known that the ULPI bus is clocked with 60MHz signal. In accordance with [1] the ULPI bus protocol is created so to spend 5 and 6 clock periods for immediate register write and read operations respectively, and 6 and 7 clock periods - for the extended register writes and reads. Based on that we can easily pre-calculate the time which will be needed for the controller to perform a requested IO operation. Note we'll still preserve the attempts counter in case if the DWC USB3 controller has got some internals delays. [1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1, October 20, 2004, pp. 30 - 36. Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support") Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201210085008.13264-3-Sergey.Semin@baikalelectronics.ru Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-28usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completionSerge Semin2-1/+2
In accordance with [1] the DWC_usb3 core sets the GUSB2PHYACCn.VStsDone bit when the PHY vendor control access is done and clears it when the application initiates a new transaction. The doc doesn't say anything about the GUSB2PHYACCn.VStsBsy flag serving for the same purpose. Moreover we've discovered that the VStsBsy flag can be cleared before the VStsDone bit. So using the former as a signal of the PHY control registers completion might be dangerous. Let's have the VStsDone flag utilized instead then. [1] Synopsys DesignWare Cores SuperSpeed USB 3.0 xHCI Host Controller Databook, 2.70a, December 2013, p.388 Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support") Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201210085008.13264-2-Sergey.Semin@baikalelectronics.ru Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-28usb: dwc3: meson-g12a: disable clk on error handling path in probeZheng Zengkai1-1/+1
dwc3_meson_g12a_probe() does not invoke clk_bulk_disable_unprepare() on one error handling path. This patch fixes that. Fixes: 347052e3bf1b ("usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20201215025459.91794-1-zhengzengkai@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-02Merge tag 'fixes-for-v5.10-rc2' of ↵Greg Kroah-Hartman2-1/+6
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: USB: fixes for v5.10-rc2 Nothing major as of yet, we're adding support for Intel Alder Lake-S in dwc3, together with a few fixes that are quite important (memory leak in raw-gadget, probe crashes in goku_udc, and so on). Signed-off-by: Felipe Balbi <balbi@kernel.org> * tag 'fixes-for-v5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: usb: raw-gadget: fix memory leak in gadget_setup usb: dwc2: Avoid leaving the error_debugfs label unused usb: dwc3: ep0: Fix delay status handling usb: gadget: fsl: fix null pointer checking usb: gadget: goku_udc: fix potential crashes in probe usb: dwc3: pci: add support for the Intel Alder Lake-S
2020-10-28usb: fix kernel-doc markupsMauro Carvalho Chehab2-2/+2
There is a common comment marked, instead, with kernel-doc notation. Also, some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/0b964be3884def04fcd20ea5c12cb90d0014871c.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-27usb: dwc3: ep0: Fix delay status handlingThinh Nguyen1-1/+2
If we want to send a control status on our own time (through delayed_status), make sure to handle a case where we may queue the delayed status before the host requesting for it (when XferNotReady is generated). Otherwise, the driver won't send anything because it's not EP0_STATUS_PHASE yet. To resolve this, regardless whether dwc->ep0state is EP0_STATUS_PHASE, make sure to clear the dwc->delayed_status flag if dwc3_ep0_send_delayed_status() is called. The control status can be sent when the host requests it later. Cc: <stable@vger.kernel.org> Fixes: d97c78a1908e ("usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-27usb: dwc3: pci: add support for the Intel Alder Lake-SHeikki Krogerus1-0/+4
This patch adds the necessary PCI ID for Intel Alder Lake-S devices. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: of-simple: Add compatible string for Intel Keem Bay platformWan Ahmad Zainie1-0/+1
Add compatible string to use this generic glue layer to support Intel Keem Bay platform's dwc3 controller. Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Support up to max stream idThinh Nguyen1-2/+2
DWC3 IPs can use the maximum stream id (up to 2^16) specified by the USB 3.x specs. Don't limit to stream id 2^15 only. Note that this does not reflect the number of concurrent streams the controller handles internally. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Return early if no TRB updateThinh Nguyen1-0/+7
If the transfer had already started and there's no TRB to update, then there's no need to go through __dwc3_gadget_kick_transfer(). There is no problem reissuing UPDATE_TRANSFER command. This change just saves the driver from doing a few operations. This happens when we run out of TRB and function driver still queues for more requests. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Keep TRBs in request orderThinh Nguyen1-3/+6
If we couldn't finish preparing all the TRBs of a request, don't prepare the next request. Otherwise, the TRBs order will be mixed up and the controller will process the wrong TRB. This is a corner case where there's not enough TRBs for a request that needs the extra TRB but there's still 1 available TRB in the pool. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Revise setting IOC when no TRB leftThinh Nguyen1-8/+9
To keep the setting of interrupt-on-completion (IOC) when out of TRBs consistent and easier to read, the caller of dwc3_prepare_one_trb() will determine if the TRB must have IOC bit set. This also reduces the number of times we need to call dwc3_calc_trbs_left(). Note that we only care about setting IOC from insufficient number of TRBs for SG and not linear requests (because we don't need to split linear requests). Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Look ahead when setting IOCThinh Nguyen1-33/+39
Previously if we run out of TRBs for the last SG entry that requires an extra TRB, we set interrupt-on-completion (IOC) bit to an already prepared TRB (i.e. HWO=1). This logic is not clean, and it's not a typical way to prepare TRB. Also, this prevents showing IOC setup in tracepoint when __dwc3_prepare_one_trb() is executed. Instead, let's look ahead when preparing TRB to know whether to set the IOC bit before the last SG entry. This requires adding a new parameter "must_interrupt" to dwc3_prepare_one_trb(). Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Allow restarting a transferThinh Nguyen1-1/+6
It's possible that there's no new TRBs prepared when kicking a transfer. This happens when we need to stop and restart a transfer such as in the case of reinitiating a stream or retrying isoc transfer. For streams, sometime host may reject a stream and the device may need to reinitiate that stream by stopping and restarting a transfer. In this case, all the TRBs may have already been prepared. Allow the function __dwc3_gadget_kick_transfer() to go through even though there's no new TRB. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: Stop active transfers before halting the controllerWesley Cheng2-2/+66
In the DWC3 databook, for a device initiated disconnect or bus reset, the driver is required to send dependxfer commands for any pending transfers. In addition, before the controller can move to the halted state, the SW needs to acknowledge any pending events. If the controller is not halted properly, there is a chance the controller will continue accessing stale or freed TRBs and buffers. Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Reviewed-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: Add splitdisable quirk for Hisilicon Kirin SocYu Chen2-0/+32
SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core of Hisilicon Kirin Soc when dwc3 core act as host. [mchehab: dropped a dev_dbg() as only traces are now allowwed on this driver] Signed-off-by: Yu Chen <chenyu56@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Rename misleading function namesThinh Nguyen1-5/+5
The functions dwc3_prepare_one_trb_sg and dwc3_prepare_one_trb_linear are not necessarily preparing "one" TRB, it can prepare multiple TRBs. Rename these functions as follow: dwc3_prepare_one_trb_sg -> dwc3_prepare_trbs_sg dwc3_prepare_one_trb_linear -> dwc3_prepare_trbs_linear Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Refactor preparing last TRBsThinh Nguyen1-81/+48
There are a lot of common codes for preparing SG and linear TRBs. Refactor them for easier read. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Set IOC if not enough for extra TRBsThinh Nguyen1-0/+20
If we run out of TRBs because we need extra TRBs, make sure to set the IOC bit for the previously prepared TRB to get completion notification to free up TRBs to resume later. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Check for number of TRBs preparedThinh Nguyen1-15/+22
By returning the number of TRBs prepared, we know whether to execute __dwc3_gadget_kick_transfer(). This allows us to check if we ran out of TRBs when extra TRBs are needed for OUT transfers. It also allows us to properly handle usb_gadget_map_request_by_dev() error. Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Return the number of prepared TRBsThinh Nguyen1-2/+33
In preparation for fixing the check for number of remaining TRBs, revise dwc3_prepare_one_trb_linear() and dwc3_prepare_one_trb_sg() to return the number of prepared TRBs. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: ep0: Fix ZLP for OUT ep0 requestsThinh Nguyen1-2/+9
The current ZLP handling for ep0 requests is only for control IN requests. For OUT direction, DWC3 needs to check and setup for MPS alignment. Usually, control OUT requests can indicate its transfer size via the wLength field of the control message. So usb_request->zero is usually not needed for OUT direction. To handle ZLP OUT for control endpoint, make sure the TRB is MPS size. Cc: stable@vger.kernel.org Fixes: c7fcdeb2627c ("usb: dwc3: ep0: simplify EP0 state machine") Fixes: d6e5a549cc4d ("usb: dwc3: simplify ZLP handling") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Improve TRB ZLP setupThinh Nguyen1-32/+18
For OUT requests that requires extra TRBs for ZLP. We don't need to prepare the 0-length TRB and simply prepare the MPS size TRB. This reduces 1 TRB needed to prepare for ZLP. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Refactor preparing extra TRBThinh Nguyen1-68/+25
When the driver prepares the extra TRB, it uses bounce buffer. If we just add a new parameter to dwc3_prepare_one_trb() to indicate this, then we can refactor and simplify the driver quite a bit. dwc3_prepare_one_trb() also checks if a request had been moved to the started list. This is a prerequisite to subsequence patches improving the handling of extra TRBs. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Reclaim extra TRBs after request completionThinh Nguyen1-5/+5
An SG request may be partially completed (due to no available TRBs). Don't reclaim extra TRBs and clear the needs_extra_trb flag until the request is fully completed. Otherwise, the driver will reclaim the wrong TRB. Cc: stable@vger.kernel.org Fixes: 1f512119a08c ("usb: dwc3: gadget: add remaining sg entries to ring") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Check MPS of the request lengthThinh Nguyen1-2/+2
When preparing for SG, not all the entries are prepared at once. When resume, don't use the remaining request length to calculate for MPS alignment. Use the entire request->length to do that. Cc: stable@vger.kernel.org Fixes: 5d187c0454ef ("usb: dwc3: gadget: Don't setup more than requested") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: Refactor ep command completionThinh Nguyen1-33/+38
Refactor END_TRANSFER command completion handling and move it outside of the switch statement to its own function. This makes it cleaner and consistent with other event handler functions. No functional change here. Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: debugfs: do not queue work if try to change mode on non-drdLi Jun1-0/+3
Do not try to queue a drd work for change mode if the port is not a drd, this is to avoid below kernel dump: [ 60.115529] ------------[ cut here ]------------ [ 60.120166] WARNING: CPU: 1 PID: 627 at kernel/workqueue.c:1473 __queue_work+0x46c/0x520 [ 60.128254] Modules linked in: [ 60.131313] CPU: 1 PID: 627 Comm: sh Not tainted 5.7.0-rc4-00022-g914a586-dirty #135 [ 60.139054] Hardware name: NXP i.MX8MQ EVK (DT) [ 60.143585] pstate: a0000085 (NzCv daIf -PAN -UAO) [ 60.148376] pc : __queue_work+0x46c/0x520 [ 60.152385] lr : __queue_work+0x314/0x520 [ 60.156393] sp : ffff8000124ebc40 [ 60.159705] x29: ffff8000124ebc40 x28: ffff800011808018 [ 60.165018] x27: ffff800011819ef8 x26: ffff800011d39980 [ 60.170331] x25: ffff800011808018 x24: 0000000000000100 [ 60.175643] x23: 0000000000000013 x22: 0000000000000001 [ 60.180955] x21: ffff0000b7c08e00 x20: ffff0000b6c31080 [ 60.186267] x19: ffff0000bb99bc00 x18: 0000000000000000 [ 60.191579] x17: 0000000000000000 x16: 0000000000000000 [ 60.196891] x15: 0000000000000000 x14: 0000000000000000 [ 60.202202] x13: 0000000000000000 x12: 0000000000000000 [ 60.207515] x11: 0000000000000000 x10: 0000000000000040 [ 60.212827] x9 : ffff800011d55460 x8 : ffff800011d55458 [ 60.218138] x7 : ffff0000b7800028 x6 : 0000000000000000 [ 60.223450] x5 : ffff0000b7800000 x4 : 0000000000000000 [ 60.228762] x3 : ffff0000bb997cc0 x2 : 0000000000000001 [ 60.234074] x1 : 0000000000000000 x0 : ffff0000b6c31088 [ 60.239386] Call trace: [ 60.241834] __queue_work+0x46c/0x520 [ 60.245496] queue_work_on+0x6c/0x90 [ 60.249075] dwc3_set_mode+0x48/0x58 [ 60.252651] dwc3_mode_write+0xf8/0x150 [ 60.256489] full_proxy_write+0x5c/0xa8 [ 60.260327] __vfs_write+0x18/0x40 [ 60.263729] vfs_write+0xdc/0x1c8 [ 60.267045] ksys_write+0x68/0xf0 [ 60.270360] __arm64_sys_write+0x18/0x20 [ 60.274286] el0_svc_common.constprop.0+0x68/0x160 [ 60.279077] do_el0_svc+0x20/0x80 [ 60.282394] el0_sync_handler+0x10c/0x178 [ 60.286403] el0_sync+0x140/0x180 [ 60.289716] ---[ end trace 70b155582e2b7988 ]--- Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: core: add phy cleanup for probe error handlingLi Jun1-0/+11
Add the phy cleanup if dwc3 mode init fail, which is the missing part of de-init for dwc3 core init. Fixes: c499ff71ff2a ("usb: dwc3: core: re-factor init and exit paths") Cc: <stable@vger.kernel.org> Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: core: don't trigger runtime pm when remove driverLi Jun1-2/+2
No need to trigger runtime pm in driver removal, otherwise if user disable auto suspend via sys file, runtime suspend may be entered, which will call dwc3_core_exit() again and there will be clock disable not balance warning: [ 2026.820154] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 2026.825268] usb usb2: USB disconnect, device number 1 [ 2026.831017] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered [ 2026.836806] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 2026.842029] usb usb1: USB disconnect, device number 1 [ 2026.848029] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered [ 2026.865889] ------------[ cut here ]------------ [ 2026.870506] usb2_ctrl_root_clk already disabled [ 2026.875082] WARNING: CPU: 0 PID: 731 at drivers/clk/clk.c:958 clk_core_disable+0xa0/0xa8 [ 2026.883170] Modules linked in: dwc3(-) phy_fsl_imx8mq_usb [last unloaded: dwc3] [ 2026.890488] CPU: 0 PID: 731 Comm: rmmod Not tainted 5.8.0-rc7-00280-g9d08cca-dirty #245 [ 2026.898489] Hardware name: NXP i.MX8MQ EVK (DT) [ 2026.903020] pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--) [ 2026.908594] pc : clk_core_disable+0xa0/0xa8 [ 2026.912777] lr : clk_core_disable+0xa0/0xa8 [ 2026.916958] sp : ffff8000121b39a0 [ 2026.920271] x29: ffff8000121b39a0 x28: ffff0000b11f3700 [ 2026.925583] x27: 0000000000000000 x26: ffff0000b539c700 [ 2026.930895] x25: 000001d7e44e1232 x24: ffff0000b76fa800 [ 2026.936208] x23: ffff0000b76fa6f8 x22: ffff800008d01040 [ 2026.941520] x21: ffff0000b539ce00 x20: ffff0000b7105000 [ 2026.946832] x19: ffff0000b7105000 x18: 0000000000000010 [ 2026.952144] x17: 0000000000000001 x16: 0000000000000000 [ 2026.957456] x15: ffff0000b11f3b70 x14: ffffffffffffffff [ 2026.962768] x13: ffff8000921b36f7 x12: ffff8000121b36ff [ 2026.968080] x11: ffff8000119e1000 x10: ffff800011bf26d0 [ 2026.973392] x9 : 0000000000000000 x8 : ffff800011bf3000 [ 2026.978704] x7 : ffff800010695d68 x6 : 0000000000000252 [ 2026.984016] x5 : ffff0000bb9881f0 x4 : 0000000000000000 [ 2026.989327] x3 : 0000000000000027 x2 : 0000000000000023 [ 2026.994639] x1 : ac2fa471aa7cab00 x0 : 0000000000000000 [ 2026.999951] Call trace: [ 2027.002401] clk_core_disable+0xa0/0xa8 [ 2027.006238] clk_core_disable_lock+0x20/0x38 [ 2027.010508] clk_disable+0x1c/0x28 [ 2027.013911] clk_bulk_disable+0x34/0x50 [ 2027.017758] dwc3_core_exit+0xec/0x110 [dwc3] [ 2027.022122] dwc3_suspend_common+0x84/0x188 [dwc3] [ 2027.026919] dwc3_runtime_suspend+0x74/0x9c [dwc3] [ 2027.031712] pm_generic_runtime_suspend+0x28/0x40 [ 2027.036419] genpd_runtime_suspend+0xa0/0x258 [ 2027.040777] __rpm_callback+0x88/0x140 [ 2027.044526] rpm_callback+0x20/0x80 [ 2027.048015] rpm_suspend+0xd0/0x418 [ 2027.051503] __pm_runtime_suspend+0x58/0xa0 [ 2027.055693] dwc3_runtime_idle+0x7c/0x90 [dwc3] [ 2027.060224] __rpm_callback+0x88/0x140 [ 2027.063973] rpm_idle+0x78/0x150 [ 2027.067201] __pm_runtime_idle+0x58/0xa0 [ 2027.071130] dwc3_remove+0x64/0xc0 [dwc3] [ 2027.075140] platform_drv_remove+0x28/0x48 [ 2027.079239] device_release_driver_internal+0xf4/0x1c0 [ 2027.084377] driver_detach+0x4c/0xd8 [ 2027.087954] bus_remove_driver+0x54/0xa8 [ 2027.091877] driver_unregister+0x2c/0x58 [ 2027.095799] platform_driver_unregister+0x10/0x18 [ 2027.100509] dwc3_driver_exit+0x14/0x1408 [dwc3] [ 2027.105129] __arm64_sys_delete_module+0x178/0x218 [ 2027.109922] el0_svc_common.constprop.0+0x68/0x160 [ 2027.114714] do_el0_svc+0x20/0x80 [ 2027.118031] el0_sync_handler+0x88/0x190 [ 2027.121953] el0_sync+0x140/0x180 [ 2027.125267] ---[ end trace 027f4f8189958f1f ]--- [ 2027.129976] ------------[ cut here ]------------ Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Cc: <stable@vger.kernel.org> Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: allocate gadget structure dynamicallyPeter Chen4-60/+78
The current code uses commit fac323471df6 ("usb: udc: allow adding and removing the same gadget device") as the workaround to let the gadget device is re-used, but it is not allowed from driver core point. In this commit, we allocate gadget structure dynamically, and free it at its release function. Since the gadget device's driver_data has already occupied by usb_composite_dev structure, we have to use gadget device's platform data to store dwc3 structure. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: pci: Allow Elkhart Lake to utilize DSM method for PM functionalityRaymond Tan1-1/+2
Similar to some other IA platforms, Elkhart Lake too depends on the PMU register write to request transition of Dx power state. Thus, we add the PCI_DEVICE_ID_INTEL_EHLLP to the list of devices that shall execute the ACPI _DSM method during D0/D3 sequence. [heikki.krogerus@linux.intel.com: included Fixes tag] Fixes: dbb0569de852 ("usb: dwc3: pci: Add Support for Intel Elkhart Lake Devices") Cc: stable@vger.kernel.org Signed-off-by: Raymond Tan <raymond.tan@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc-meson-g12a: Add support for USB on AXG SoCsNeil Armstrong1-0/+18
The Amlogic AXG is close to the GXL Glue but with a single OTG PHY. It needs the same init sequence as GXL & GXM, but it seems it doesn't need the host disconnect bit. Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: core: do not queue work if dr_mode is not USB_DR_MODE_OTGLi Jun1-3/+3
Do not try to queue a drd work if dr_mode is not USB_DR_MODE_OTG because the work is not inited, this may be triggered by user try to change mode file of debugfs on a single role port, which will cause below kernel dump: [ 60.115529] ------------[ cut here ]------------ [ 60.120166] WARNING: CPU: 1 PID: 627 at kernel/workqueue.c:1473 __queue_work+0x46c/0x520 [ 60.128254] Modules linked in: [ 60.131313] CPU: 1 PID: 627 Comm: sh Not tainted 5.7.0-rc4-00022-g914a586-dirty #135 [ 60.139054] Hardware name: NXP i.MX8MQ EVK (DT) [ 60.143585] pstate: a0000085 (NzCv daIf -PAN -UAO) [ 60.148376] pc : __queue_work+0x46c/0x520 [ 60.152385] lr : __queue_work+0x314/0x520 [ 60.156393] sp : ffff8000124ebc40 [ 60.159705] x29: ffff8000124ebc40 x28: ffff800011808018 [ 60.165018] x27: ffff800011819ef8 x26: ffff800011d39980 [ 60.170331] x25: ffff800011808018 x24: 0000000000000100 [ 60.175643] x23: 0000000000000013 x22: 0000000000000001 [ 60.180955] x21: ffff0000b7c08e00 x20: ffff0000b6c31080 [ 60.186267] x19: ffff0000bb99bc00 x18: 0000000000000000 [ 60.191579] x17: 0000000000000000 x16: 0000000000000000 [ 60.196891] x15: 0000000000000000 x14: 0000000000000000 [ 60.202202] x13: 0000000000000000 x12: 0000000000000000 [ 60.207515] x11: 0000000000000000 x10: 0000000000000040 [ 60.212827] x9 : ffff800011d55460 x8 : ffff800011d55458 [ 60.218138] x7 : ffff0000b7800028 x6 : 0000000000000000 [ 60.223450] x5 : ffff0000b7800000 x4 : 0000000000000000 [ 60.228762] x3 : ffff0000bb997cc0 x2 : 0000000000000001 [ 60.234074] x1 : 0000000000000000 x0 : ffff0000b6c31088 [ 60.239386] Call trace: [ 60.241834] __queue_work+0x46c/0x520 [ 60.245496] queue_work_on+0x6c/0x90 [ 60.249075] dwc3_set_mode+0x48/0x58 [ 60.252651] dwc3_mode_write+0xf8/0x150 [ 60.256489] full_proxy_write+0x5c/0xa8 [ 60.260327] __vfs_write+0x18/0x40 [ 60.263729] vfs_write+0xdc/0x1c8 [ 60.267045] ksys_write+0x68/0xf0 [ 60.270360] __arm64_sys_write+0x18/0x20 [ 60.274286] el0_svc_common.constprop.0+0x68/0x160 [ 60.279077] do_el0_svc+0x20/0x80 [ 60.282394] el0_sync_handler+0x10c/0x178 [ 60.286403] el0_sync+0x140/0x180 [ 60.289716] ---[ end trace 70b155582e2b7988 ]--- Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: gadget: fix checkpatch warningsFelipe Balbi1-15/+17
no functional changes Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: core: fix checkpatch warningsFelipe Balbi1-18/+19
no functional changes Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: debugfs: fix checkpatch warningsFelipe Balbi1-30/+26
no functional changes Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: qcom: fix checkpatch warningsFelipe Balbi1-3/+5
no functional changes Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: ep0: fix checkpatch warningsFelipe Balbi1-3/+3
no functional changes Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: debug: fix checkpatch warningFelipe Balbi1-2/+2
no functional changes Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: trace: fix checkpatch warningsFelipe Balbi1-8/+9
no functional changes Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: ulpi: fix checkpatch warningFelipe Balbi1-1/+1
no functional changes. Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: meson: fix checkpatch errors and warningsFelipe Balbi1-11/+7
no functional changes. Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: debug: fix sparse warningFelipe Balbi1-1/+3
Fix the following sparse warning: drivers/usb/dwc3/trace.c: note: in included file (through drivers/usb/dwc3/trace.h): drivers/usb/dwc3/debug.h:374:39: warning: cast to non-scalar Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: meson: fix coccinelle WARNINGFelipe Balbi1-4/+1
Coccinelle suggests using PTR_ERR_OR_ZERO(). Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-10-02usb: dwc3: qcom: Add interconnect support in dwc3 driverSandeep Maheswaram1-2/+118
Add interconnect support in dwc3-qcom driver to vote for bus bandwidth. This requires for two different paths - from USB to DDR. The other is from APPS to USB. Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org> Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-09-24usb: dwc3: core: Print warning on unsupported speedThinh Nguyen1-0/+9
The user may have more information to override the HW parameter to specify the maximum_speed. However, if the user specifies a maximum_speed that the controller doesn't support, print out a warning. Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-15 23:43:14 +0000