- 02 Oct, 2020 40 commits
-
-
Yu Chen authored
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>
-
Tang Bin authored
Delete unused initialized value of 'ret', because it will be assigned by the function clk_prepare_enable(). Signed-off-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Signed-off-by:
-
Zqiang authored
If an error occurred before calling the 'v4l2_device_register' func, and then goto error, but no need to call 'v4l2_device_unregister' func. Signed-off-by:
Zqiang <qiang.zhang@windriver.com> Signed-off-by:
-
Thinh Nguyen authored
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:
-
Thinh Nguyen authored
There are a lot of common codes for preparing SG and linear TRBs. Refactor them for easier read. Signed-off-by:
-
Thinh Nguyen authored
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 authored
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: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Signed-off-by:
-
Thinh Nguyen authored
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 authored
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: c7fcdeb2 ("usb: dwc3: ep0: simplify EP0 state machine") Fixes: d6e5a549 ("usb: dwc3: simplify ZLP handling") Signed-off-by:
-
Thinh Nguyen authored
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 authored
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 authored
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: 1f512119 ("usb: dwc3: gadget: add remaining sg entries to ring") Signed-off-by:
-
Thinh Nguyen authored
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: 5d187c04 ("usb: dwc3: gadget: Don't setup more than requested") Signed-off-by:
-
Chunfeng Yun authored
Fix up the build error caused by undeclared usb_debug_root Cc: stable <stable@vger.kernel.org> Fixes: a66ada4f ("usb: gadget: bcm63xx_udc: create debugfs directory under usb root") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
-
Thierry Reding authored
Probe deferral is an expected condition and can happen multiple times during boot. Make sure not to output an error message in that case because they are not useful. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Thierry Reding authored
Align parameters on subsequent lines with the parameters on the first line for consistency. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a literal string. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Thierry Reding authored
Make sure to use consistent spelling and formatting in error messages. Signed-off-by:
-
Christophe JAILLET authored
There is no need to use GFP_ATOMIC here. It is a probe function, no spinlock is taken. Reviewed-by:
JC Kuo <jckuo@nvidia.com> Acked-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Peter Chen authored
Current UDC core connects gadget during the loading gadget flow (udc_bind_to_driver->usb_udc_connect_control), but for platforms which do not connect gadget if the VBUS is not there, they call usb_gadget_disconnect, but the gadget is not connected at this time, notify disconnecton for the gadget driver is meaningless at this situation. Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Thinh Nguyen authored
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:
-
Krzysztof Kozlowski authored
Remove unused 'udc' variable to fix compile warnings: drivers/usb/gadget/udc/s3c2410_udc.c: In function 's3c2410_udc_dequeue': drivers/usb/gadget/udc/s3c2410_udc.c:1268:22: warning: variable 'udc' set but not used [-Wunused-but-set-variable] Reviewed-by:Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Li Jun authored
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:
-
Li Jun authored
Add the phy cleanup if dwc3 mode init fail, which is the missing part of de-init for dwc3 core init. Fixes: c499ff71 ("usb: dwc3: core: re-factor init and exit paths") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Li Jun authored
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: fc8bb91b ("usb: dwc3: implement runtime PM") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Peter Chen authored
We have already allocated gadget structure dynamically at UDC (dwc3) driver, so commit fac32347 ("usb: udc: allow adding and removing the same gadget device")could be reverted. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Peter Chen authored
The current code uses commit fac32347 ("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:
-
Peter Chen authored
If cdns3_gadget_start is failed, it never frees cdns3_device structure. Meanwhile, there is no release function for gadget device, it causes there is no sync with driver core. To fix this, we add release function for gadget device, and free cdns3_device structure at there. Meanwhile, With the new UDC core APIs, we could work with driver core better to handle memory leak issue. Reviewed-by:
-
Alan Stern authored
Like net2280 (on which it was based), the net2272 UDC driver has a problem with leaking memory along some of its failure pathways. It also has another problem, not previously noted, in that some of the failure pathways will call usb_del_gadget_udc() without first calling usb_add_gadget_udc_release(). And it leaks memory by calling kfree() when it should call put_device(). Until now it has been impossible to handle the memory leaks, because of lack of support in the UDC core for separately initializing and adding gadgets, or for separately deleting and freeing gadgets. An earlier patch in this series adds the necessary support, making it possible to fix the outstanding problems properly. This patch adds an "added" flag to the net2272 structure to indicate whether or not the gadget has been registered (and thus whether or not to call usb_del_gadget()), and it fixes the deallocation issues by calling usb_put_gadget() at the appropriate places. A similar memory leak issue, apparently never before recognized, stems from the fact that the driver never initializes the drvdata field in the gadget's embedded struct device! Evidently this wasn't noticed because the pointer is only ever used as an argument to kfree(), which doesn't mind getting called with a NULL pointer. In fact, the drvdata for gadget device will be written by usb_composite_dev structure if any gadget class is loaded, so it needs to use usb_gadget structure to get net2280 private data. CC: Anton Vasilyev <vasilyev@ispras.ru> CC: Evgeny Novikov <novikov@ispras.ru> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by:
-
Alan Stern authored
As Anton and Evgeny have noted, the net2280 UDC driver has a problem with leaking memory along some of its failure pathways. It also has another problem, not previously noted, in that some of the failure pathways will call usb_del_gadget_udc() without first calling usb_add_gadget_udc_release(). And it leaks memory by calling kfree() when it should call put_device(). Previous attempts to fix the problems have failed because of lack of support in the UDC core for separately initializing and adding gadgets, or for separately deleting and freeing gadgets. The previous patch in this series adds the necessary support, making it possible to fix the outstanding problems properly. This patch adds an "added" flag to the net2280 structure to indicate whether or not the gadget has been registered (and thus whether or not to call usb_del_gadget()), and it fixes the deallocation issues by calling usb_put_gadget() at the appropriate point. A similar memory leak issue, apparently never before recognized, stems from the fact that the driver never initializes the drvdata field in the gadget's embedded struct device! Evidently this wasn't noticed because the pointer is only ever used as an argument to kfree(), which doesn't mind getting called with a NULL pointer. In fact, the drvdata for gadget device will be written by usb_composite_dev structure if any gadget class is loaded, so it needs to use usb_gadget structure to get net2280 private data. CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by:
Anton Vasilyev <vasilyev@ispras.ru> Reported-by:
Evgeny Novikov <novikov@ispras.ru> Reviewed-by:
-
Alan Stern authored
The routines used by the UDC core to interface with the kernel's device model, namely usb_add_gadget_udc(), usb_add_gadget_udc_release(), and usb_del_gadget_udc(), provide access to only a subset of the device model's full API. They include functionality equivalent to device_register() and device_unregister() for gadgets, but they omit device_initialize(), device_add(), device_del(), get_device(), and put_device(). This patch expands the UDC API by adding usb_initialize_gadget(), usb_add_gadget(), usb_del_gadget(), usb_get_gadget(), and usb_put_gadget() to fill in the gap. It rewrites the existing routines to call the new ones. CC: Anton Vasilyev <vasilyev@ispras.ru> CC: Evgeny Novikov <novikov@ispras.ru> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by:
-
Peter Chen authored
It is found by sparse. Reported-by:
-
Ye Bin authored
udc_controller->irq is "unsigned int" always >= 0, but platform_get_irq may return little than zero. So "dc_controller->irq < 0" condition is never accessible. Acked-by:
Li Yang <leoyang.li@nxp.com> Signed-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
-
Lorenzo Colitti authored
The u_ether driver has a qmult setting that multiplies the transmit queue length (which by default is 2). The intent is that it should be enabled at high/super speed, but because the code does not explicitly check for USB_SUPER_PLUS, it is disabled at that speed. Fix this by ensuring that the queue multiplier is enabled for any wired link at high speed or above. Using >= for USB_SPEED_* constants seems correct because it is what the gadget_is_xxxspeed functions do. The queue multiplier substantially helps performance at higher speeds. On a direct SuperSpeed Plus link to a Linux laptop, iperf3 single TCP stream: Before (qmult=1): 1.3 Gbps After (qmult=5): 3.2 Gbps Fixes: 04617db7 ("usb: gadget: add SS descriptors to Ethernet gadget") Reviewed-by:
Maciej Żenczykowski <maze@google.com> Signed-off-by:
Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
-
Yoshihiro Shimoda authored
The commit aba3a8d0 ("usb: gadget: u_serial: add suspend resume callbacks") set/cleared the suspended flag in USB bus suspend/resume only. But, when a USB cable is disconnected in the suspend, since some controllers will not detect USB bus resume, the suspended flag is not cleared. After that, user cannot send any data. To fix the issue, clears the suspended flag in the gserial_disconnect(). Fixes: aba3a8d0 ("usb: gadget: u_serial: add suspend resume callbacks") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
Linh Phung <linh.phung.jy@renesas.com> Tested-by:
Tam Nguyen <tam.nguyen.xa@renesas.com> Signed-off-by:
-
Randy Dunlap authored
Fix typo/spello of "function". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: linux-usb@vger.kernel.org Cc: Jiri Kosina <trivial@kernel.org> Signed-off-by:
-
Lorenzo Colitti authored
Currently, enabling f_ncm at SuperSpeed Plus speeds results in an oops in config_ep_by_speed because ncm_set_alt passes in NULL ssp_descriptors. Fix this by re-using the SuperSpeed descriptors. This is safe because usb_assign_descriptors calls usb_copy_descriptors. Tested: enabled f_ncm on a dwc3 gadget and 10Gbps link, ran iperf Reviewed-by:
-
Lorenzo Colitti authored
This improves performance on fast connections. When directly connecting to a Linux laptop running 5.6, single-stream iperf3 goes from ~1.7Gbps to ~2.3Gbps out, and from ~620Mbps to ~720Mbps in. Reviewed-by:
-
Lorenzo Colitti authored
Currently, SuperSpeed NCM gadgets report a speed of 851 Mbps in USB_CDC_NOTIFY_SPEED_CHANGE. But the calculation appears to assume 16 packets per microframe, and USB 3 and above no longer use microframes. Maximum speed is actually much higher. On a direct connection, theoretical throughput is at most 3.86 Gbps for gen1x1 and 9.36 Gbps for gen2x1, and I have seen gadget->host iperf throughput of >2 Gbps for gen1x1 and >4 Gbps for gen2x1. Unfortunately the ConnectionSpeedChange defined in the CDC spec only uses 32-bit values, so we can't report accurate numbers for 10Gbps and above. So, report 3.75Gbps for SuperSpeed (which is roughly maximum theoretical performance) and 4.25Gbps for SuperSpeed Plus (which is close to the maximum that we can report in a 32-bit unsigned integer). This results in: [50879.191272] cdc_ncm 2-2:1.0 enx228b127e050c: renamed from usb0 [50879.234778] cdc_ncm 2-2:1.0 enx228b127e050c: 3750 mbit/s downlink 3750 mbit/s uplink on SuperSpeed and: [50798.434527] cdc_ncm 8-2:1.0 enx228b127e050c: renamed from usb0 [50798.524278] cdc_ncm 8-2:1.0 enx228b127e050c: 4250 mbit/s downlink 4250 mbit/s uplink on SuperSpeed Plus. Fixes: 16501138 ("usb: gadget: f_ncm: add SuperSpeed descriptors for CDC NCM") Reviewed-by:
-
Peter Chen authored
After commit f4cfe5ce ("usb: cdns3: gadget: improve the set_configuration handling"), the software will inform the hardware the request has finished at cdns3_ep0_complete_setup. The configuration set bit is only set after request has finished, so it needs to move waiting operation after that. Meanwhile, if it is timeout, it will show warning message and return error. Signed-off-by:
-
