<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/usb/dwc3/core.c, branch dev-5.3</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.3</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2019-11-12T18:27:59+00:00</updated>
<entry>
<title>usb: dwc3: remove the call trace of USBx_GFLADJ</title>
<updated>2019-11-12T18:27:59+00:00</updated>
<author>
<name>Yinbo Zhu</name>
<email>yinbo.zhu@nxp.com</email>
</author>
<published>2019-07-29T06:46:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4111c2641e54fd2772cf71422dacd4c2deee4ff0'/>
<id>urn:sha1:4111c2641e54fd2772cf71422dacd4c2deee4ff0</id>
<content type='text'>
[ Upstream commit a7d9874c6f3fbc8d25cd9ceba35b6822612c4ebf ]

layerscape board sometimes reported some usb call trace, that is due to
kernel sent LPM tokerns automatically when it has no pending transfers
and think that the link is idle enough to enter L1, which procedure will
ask usb register has a recovery,then kernel will compare USBx_GFLADJ and
set GFLADJ_30MHZ, GFLADJ_30MHZ_REG until GFLADJ_30MHZ is equal 0x20, if
the conditions were met then issue occur, but whatever the conditions
whether were met that usb is all need keep GFLADJ_30MHZ of value is 0x20
(xhci spec ask use GFLADJ_30MHZ to adjust any offset from clock source
that generates the clock that drives the SOF counter, 0x20 is default
value of it)That is normal logic, so need remove the call trace.

Signed-off-by: Yinbo Zhu &lt;yinbo.zhu@nxp.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: gadget: Add support for disabling U1 and U2 entries</title>
<updated>2019-06-18T08:58:30+00:00</updated>
<author>
<name>Anurag Kumar Vulisha</name>
<email>anurag.kumar.vulisha@xilinx.com</email>
</author>
<published>2019-05-10T07:07:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=729dcffd1ed319c9738456543f382d0801e768b8'/>
<id>urn:sha1:729dcffd1ed319c9738456543f382d0801e768b8</id>
<content type='text'>
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 &lt;anurag.kumar.vulisha@xilinx.com&gt;
Signed-off-by: Claus H. Stovgaard &lt;cst@phaseone.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: Fix core validation in probe, move after clocks are enabled</title>
<updated>2019-06-18T08:58:29+00:00</updated>
<author>
<name>Enric Balletbo i Serra</name>
<email>enric.balletbo@collabora.com</email>
</author>
<published>2019-06-13T15:01:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dc1b5d9aed1794b5a1c6b0da46e372cc09974cbc'/>
<id>urn:sha1:dc1b5d9aed1794b5a1c6b0da46e372cc09974cbc</id>
<content type='text'>
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 &lt;enric.balletbo@collabora.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: Fix default lpm_nyet_threshold value</title>
<updated>2019-05-03T06:13:49+00:00</updated>
<author>
<name>Thinh Nguyen</name>
<email>Thinh.Nguyen@synopsys.com</email>
</author>
<published>2019-04-25T20:55:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=8d791929b2fbdf7734c1596d808e55cb457f4562'/>
<id>urn:sha1:8d791929b2fbdf7734c1596d808e55cb457f4562</id>
<content type='text'>
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 &lt;thinhn@synopsys.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: Do core validation early on probe</title>
<updated>2019-05-03T06:13:49+00:00</updated>
<author>
<name>Thinh Nguyen</name>
<email>Thinh.Nguyen@synopsys.com</email>
</author>
<published>2019-04-25T21:19:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b873e2d0ea1efc91fb603b727733525f07419f2b'/>
<id>urn:sha1:b873e2d0ea1efc91fb603b727733525f07419f2b</id>
<content type='text'>
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 &lt;thinhn@synopsys.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: move synchronize_irq() out of the spinlock protected block</title>
<updated>2019-05-03T06:13:48+00:00</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2019-03-27T09:56:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=41a91c606e7d2b74358a944525267cc451c271e8'/>
<id>urn:sha1:41a91c606e7d2b74358a944525267cc451c271e8</id>
<content type='text'>
dwc3_gadget_suspend() is called under dwc-&gt;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 (&amp;of-&gt;mutex){+.+.}, at: kernfs_fop_write+0xc0/0x1e4
 #2: 7e597705 (kn-&gt;count#60){.+.+}, at: kernfs_fop_write+0xc8/0x1e4
 #3: 8b3527d0 (system_transition_mutex){+.+.}, at: pm_suspend+0xc4/0xc04
 #4: fc7f1c42 (&amp;dev-&gt;mutex){....}, at: __device_suspend+0xd8/0x74c
 #5: 4b36507e (&amp;(&amp;dwc-&gt;lock)-&gt;rlock){....}, at: dwc3_gadget_suspend+0x24/0x3c
irq event stamp: 11252
hardirqs last  enabled at (11251): [&lt;c09c54a4&gt;] _raw_spin_unlock_irqrestore+0x6c/0x74
hardirqs last disabled at (11252): [&lt;c09c4d44&gt;] _raw_spin_lock_irqsave+0x1c/0x5c
softirqs last  enabled at (9744): [&lt;c0102564&gt;] __do_softirq+0x3a4/0x66c
softirqs last disabled at (9737): [&lt;c0128528&gt;] irq_exit+0x140/0x168
Preemption disabled at:
[&lt;00000000&gt;]   (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)
[&lt;c01110f0&gt;] (unwind_backtrace) from [&lt;c010d120&gt;] (show_stack+0x10/0x14)
[&lt;c010d120&gt;] (show_stack) from [&lt;c09a4d04&gt;] (dump_stack+0x90/0xc8)
[&lt;c09a4d04&gt;] (dump_stack) from [&lt;c014c700&gt;] (___might_sleep+0x22c/0x2c8)
[&lt;c014c700&gt;] (___might_sleep) from [&lt;c0189d68&gt;] (synchronize_irq+0x28/0x84)
[&lt;c0189d68&gt;] (synchronize_irq) from [&lt;c05cbbf8&gt;] (dwc3_gadget_suspend+0x34/0x3c)
[&lt;c05cbbf8&gt;] (dwc3_gadget_suspend) from [&lt;c05bd020&gt;] (dwc3_suspend_common+0x154/0x410)
[&lt;c05bd020&gt;] (dwc3_suspend_common) from [&lt;c05bd34c&gt;] (dwc3_suspend+0x14/0x2c)
[&lt;c05bd34c&gt;] (dwc3_suspend) from [&lt;c051c730&gt;] (platform_pm_suspend+0x2c/0x54)
[&lt;c051c730&gt;] (platform_pm_suspend) from [&lt;c05285d4&gt;] (dpm_run_callback+0xa4/0x3dc)
[&lt;c05285d4&gt;] (dpm_run_callback) from [&lt;c0528a40&gt;] (__device_suspend+0x134/0x74c)
[&lt;c0528a40&gt;] (__device_suspend) from [&lt;c052c508&gt;] (dpm_suspend+0x174/0x588)
[&lt;c052c508&gt;] (dpm_suspend) from [&lt;c0182134&gt;] (suspend_devices_and_enter+0xc0/0xe74)
[&lt;c0182134&gt;] (suspend_devices_and_enter) from [&lt;c0183658&gt;] (pm_suspend+0x770/0xc04)
[&lt;c0183658&gt;] (pm_suspend) from [&lt;c0180ddc&gt;] (state_store+0x6c/0xcc)
[&lt;c0180ddc&gt;] (state_store) from [&lt;c09a9a70&gt;] (kobj_attr_store+0x14/0x20)
[&lt;c09a9a70&gt;] (kobj_attr_store) from [&lt;c02d6800&gt;] (sysfs_kf_write+0x4c/0x50)
[&lt;c02d6800&gt;] (sysfs_kf_write) from [&lt;c02d594c&gt;] (kernfs_fop_write+0xfc/0x1e4)
[&lt;c02d594c&gt;] (kernfs_fop_write) from [&lt;c02593d8&gt;] (__vfs_write+0x2c/0x160)
[&lt;c02593d8&gt;] (__vfs_write) from [&lt;c0259694&gt;] (vfs_write+0xa4/0x16c)
[&lt;c0259694&gt;] (vfs_write) from [&lt;c0259870&gt;] (ksys_write+0x40/0x8c)
[&lt;c0259870&gt;] (ksys_write) from [&lt;c0101000&gt;] (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 &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: Free resource immediately after use</title>
<updated>2019-05-03T06:13:48+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2019-03-27T15:17:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=75ecb9dd56a7c360ed487ee809d8e4a026fd7152'/>
<id>urn:sha1:75ecb9dd56a7c360ed487ee809d8e4a026fd7152</id>
<content type='text'>
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 &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: Add workaround for isoc start transfer failure</title>
<updated>2018-11-26T07:06:32+00:00</updated>
<author>
<name>Thinh Nguyen</name>
<email>thinh.nguyen@synopsys.com</email>
</author>
<published>2018-11-15T06:56:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d92021f66063b30910255d70dc95e0d7b57f018f'/>
<id>urn:sha1:d92021f66063b30910255d70dc95e0d7b57f018f</id>
<content type='text'>
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 &lt;thinhn@synopsys.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: Track DWC_usb31 VERSIONTYPE</title>
<updated>2018-11-26T07:06:32+00:00</updated>
<author>
<name>Thinh Nguyen</name>
<email>thinh.nguyen@synopsys.com</email>
</author>
<published>2018-11-08T20:06:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=475d8e0197f1bcf4647041f46206ffc1a16d15dd'/>
<id>urn:sha1:475d8e0197f1bcf4647041f46206ffc1a16d15dd</id>
<content type='text'>
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 &lt;thinhn@synopsys.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: dwc3: Set default mode for DWC_usb3 v3.30a and higher</title>
<updated>2018-11-26T07:06:32+00:00</updated>
<author>
<name>Thinh Nguyen</name>
<email>thinh.nguyen@synopsys.com</email>
</author>
<published>2018-11-03T01:41:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=89a9cc47513e91bc91ba2c438d5e422a0c8d05e7'/>
<id>urn:sha1:89a9cc47513e91bc91ba2c438d5e422a0c8d05e7</id>
<content type='text'>
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 &lt;thinhn@synopsys.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
</feed>
