BMC/Intel-BMC/linux.git/drivers/usb/dwc3/core.c, branch dev-5.2

usb: dwc3: Fix core validation in probe, move after clocks are enabled

2019-07-31T05:24:41+00:00

[ Upstream commit dc1b5d9aed1794b5a1c6b0da46e372cc09974cbc ] The required clocks needs to be enabled before the first register access. After commit fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3 core"), this happens when the dwc3_core_is_valid function is called, but the mentioned commit adds that call in the wrong place, before the clocks are enabled. So, move that call after the clk_bulk_enable() to ensure the clocks are enabled and the reset deasserted. I detected this while, as experiment, I tried to move the clocks and resets from the glue layer to the DWC3 core on a Samsung Chromebook Plus. That was not detected before because, in most cases, the glue layer initializes SoC-specific things and then populates the child "snps,dwc3" with those clocks already enabled. Fixes: b873e2d0ea1ef ("usb: dwc3: Do core validation early on probe") Signed-off-by: Enric Balletbo i Serra Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: dwc3: Fix default lpm_nyet_threshold value

2019-05-03T06:13:49+00:00

The max possible value for DCTL.LPM_NYET_THRES is 15 and not 255. Change the default value to 15. Cc: stable@vger.kernel.org Fixes: 80caf7d21adc ("usb: dwc3: add lpm erratum support") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi

usb: dwc3: Do core validation early on probe

2019-05-03T06:13:49+00:00

The setting of the dr_mode may need to check the controller's revision. The revision is set in the dwc3_core_is_valid(), which comes after dr_mode setting. Let's move it closer to the start of the dwc3_probe() function and before calling dwc3_get_dr_mode(). Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi

usb: dwc3: move synchronize_irq() out of the spinlock protected block

2019-05-03T06:13:48+00:00

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): [] _raw_spin_unlock_irqrestore+0x6c/0x74 hardirqs last disabled at (11252): [] _raw_spin_lock_irqsave+0x1c/0x5c softirqs last enabled at (9744): [] __do_softirq+0x3a4/0x66c softirqs last disabled at (9737): [] 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) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x90/0xc8) [] (dump_stack) from [] (___might_sleep+0x22c/0x2c8) [] (___might_sleep) from [] (synchronize_irq+0x28/0x84) [] (synchronize_irq) from [] (dwc3_gadget_suspend+0x34/0x3c) [] (dwc3_gadget_suspend) from [] (dwc3_suspend_common+0x154/0x410) [] (dwc3_suspend_common) from [] (dwc3_suspend+0x14/0x2c) [] (dwc3_suspend) from [] (platform_pm_suspend+0x2c/0x54) [] (platform_pm_suspend) from [] (dpm_run_callback+0xa4/0x3dc) [] (dpm_run_callback) from [] (__device_suspend+0x134/0x74c) [] (__device_suspend) from [] (dpm_suspend+0x174/0x588) [] (dpm_suspend) from [] (suspend_devices_and_enter+0xc0/0xe74) [] (suspend_devices_and_enter) from [] (pm_suspend+0x770/0xc04) [] (pm_suspend) from [] (state_store+0x6c/0xcc) [] (state_store) from [] (kobj_attr_store+0x14/0x20) [] (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50) [] (sysfs_kf_write) from [] (kernfs_fop_write+0xfc/0x1e4) [] (kernfs_fop_write) from [] (__vfs_write+0x2c/0x160) [] (__vfs_write) from [] (vfs_write+0xa4/0x16c) [] (vfs_write) from [] (ksys_write+0x40/0x8c) [] (ksys_write) from [] (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 Signed-off-by: Felipe Balbi

usb: dwc3: Free resource immediately after use

2019-05-03T06:13:48+00:00

When we read an array of integers from device properties, the temporary buffer is allocated. However, in case of dwc3_set_incr_burst_type() it's not freed. Free allocated buffer immediately after use. Signed-off-by: Andy Shevchenko Signed-off-by: Felipe Balbi

usb: dwc3: Add workaround for isoc start transfer failure

2018-11-26T07:06:32+00:00

In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed isochronous IN, BIT[15:14] of the 16-bit microframe number reported by the XferNotReady event are invalid. The driver uses this number to schedule the isochronous transfer and passes it to the START TRANSFER command. Because this number is invalid, the command may fail. If BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER command will pass and the transfer will start at the scheduled time, if it is off by 1, the command will still pass, but the transfer will start 2 seconds in the future. For all other conditions, the START TRANSFER command will fail with bus-expiry. In order to workaround this issue, we can test for the correct combination of BIT[15:14] by sending START TRANSFER commands with different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11. Each combination is 2^14 uframe apart (or 2 seconds). 4 seconds into the future will result in a bus-expiry status. As the result, within the 4 possible combinations for BIT[15:14], there will be 2 successful and 2 failure START COMMAND status. One of the 2 successful command status will result in a 2-second delay start. The smaller BIT[15:14] value is the correct combination. Since there are only 4 outcomes and the results are ordered, we can simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00 and 'b01 to deduce the smaller successful combination. Let test0 = test status for combination 'b00 and test1 = test status for 'b01 of BIT[15:14]. The correct combination is as follow: if test0 fails and test1 passes, BIT[15:14] is 'b01 if test0 fails and test1 fails, BIT[15:14] is 'b10 if test0 passes and test1 fails, BIT[15:14] is 'b11 if test0 passes and test1 passes, BIT[15:14] is 'b00 Synopsys STAR 9001202023: Wrong microframe number for isochronous IN endpoints. Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi

usb: dwc3: Track DWC_usb31 VERSIONTYPE

2018-11-26T07:06:32+00:00

Add a new field to dwc3 structure to track VERSIONTYPE. The VERSIONTYPE is represented in ASCII in the 32-bit VERSIONTYPE register. In DWC_usb31, sub releases for each version are tracked with VERSIONTYPE such as "ea01" and "ea02". Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi

usb: dwc3: Set default mode for DWC_usb3 v3.30a and higher

2018-11-26T07:06:32+00:00

DWC_usb31 and DWC_usb3 v3.30a and higher do not support OTG mode. If the controller supports DRD but the dr_mode is not specified or set to OTG, then set the mode to peripheral. Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi

usb: dwc3: don't log probe deferrals; but do log other error codes

2018-11-26T07:06:31+00:00

It's not very useful to repeat a bunch of probe deferral errors. And it's also not very useful to log "failed" without telling the error code. Signed-off-by: Brian Norris Signed-off-by: Felipe Balbi

usb: dwc3: Support option to disable USB2 LPM

2018-11-26T07:06:31+00:00

Support the option to disable USB2 LPM. Set xhci "usb2-lpm-disable" property via "snps,usb2-lpm-disable" property. Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi