<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/usb, branch v4.13-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>xhci: fix memleak in xhci_run()</title>
<updated>2017-07-20T12:40:36+00:00</updated>
<author>
<name>Shu Wang</name>
<email>shuwang@redhat.com</email>
</author>
<published>2017-07-20T11:48:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d6f5f071f1e13cadecf8aef1faa7e5d6fbc9f33b'/>
<id>d6f5f071f1e13cadecf8aef1faa7e5d6fbc9f33b</id>
<content type='text'>
Found this issue by kmemleak.
xhci_run() did not check return val and free command for
xhci_queue_vendor_command()

unreferenced object 0xffff88011c0be500 (size 64):
  comm "kworker/0:1", pid 58, jiffies 4294670908 (age 50.420s)
  hex dump (first 32 bytes):
  backtrace:
    [&lt;ffffffff8176166a&gt;] kmemleak_alloc+0x4a/0xa0
    [&lt;ffffffff8121801a&gt;] kmem_cache_alloc_trace+0xca/0x1d0
    [&lt;ffffffff81576bf4&gt;] xhci_alloc_command+0x44/0x130
    [&lt;ffffffff8156f1cc&gt;] xhci_run+0x4cc/0x630
    [&lt;ffffffff8153b84b&gt;] usb_add_hcd+0x3bb/0x950
    [&lt;ffffffff8154eac8&gt;] usb_hcd_pci_probe+0x188/0x500
    [&lt;ffffffff815851ac&gt;] xhci_pci_probe+0x2c/0x220
    [&lt;ffffffff813d2ca5&gt;] local_pci_probe+0x45/0xa0
    [&lt;ffffffff810a54e4&gt;] work_for_cpu_fn+0x14/0x20
    [&lt;ffffffff810a8409&gt;] process_one_work+0x149/0x360
    [&lt;ffffffff810a8d08&gt;] worker_thread+0x1d8/0x3c0
    [&lt;ffffffff810ae7d9&gt;] kthread+0x109/0x140
    [&lt;ffffffff8176d585&gt;] ret_from_fork+0x25/0x30
    [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Shu Wang &lt;shuwang@redhat.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Found this issue by kmemleak.
xhci_run() did not check return val and free command for
xhci_queue_vendor_command()

unreferenced object 0xffff88011c0be500 (size 64):
  comm "kworker/0:1", pid 58, jiffies 4294670908 (age 50.420s)
  hex dump (first 32 bytes):
  backtrace:
    [&lt;ffffffff8176166a&gt;] kmemleak_alloc+0x4a/0xa0
    [&lt;ffffffff8121801a&gt;] kmem_cache_alloc_trace+0xca/0x1d0
    [&lt;ffffffff81576bf4&gt;] xhci_alloc_command+0x44/0x130
    [&lt;ffffffff8156f1cc&gt;] xhci_run+0x4cc/0x630
    [&lt;ffffffff8153b84b&gt;] usb_add_hcd+0x3bb/0x950
    [&lt;ffffffff8154eac8&gt;] usb_hcd_pci_probe+0x188/0x500
    [&lt;ffffffff815851ac&gt;] xhci_pci_probe+0x2c/0x220
    [&lt;ffffffff813d2ca5&gt;] local_pci_probe+0x45/0xa0
    [&lt;ffffffff810a54e4&gt;] work_for_cpu_fn+0x14/0x20
    [&lt;ffffffff810a8409&gt;] process_one_work+0x149/0x360
    [&lt;ffffffff810a8d08&gt;] worker_thread+0x1d8/0x3c0
    [&lt;ffffffff810ae7d9&gt;] kthread+0x109/0x140
    [&lt;ffffffff8176d585&gt;] ret_from_fork+0x25/0x30
    [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Shu Wang &lt;shuwang@redhat.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: xhci: fix spinlock recursion for USB2 test mode</title>
<updated>2017-07-20T12:40:36+00:00</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@nxp.com</email>
</author>
<published>2017-07-20T11:48:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=576d55460e7f209139545a348746c2fcadf61bc3'/>
<id>576d55460e7f209139545a348746c2fcadf61bc3</id>
<content type='text'>
Both xhci_hub_control and xhci_disable_slot tries to hold spinlock, the
spinlock recursion occurs when enters USB2 test mode. Fix it by unlock
spinlock before calling xhci_disable_slot.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 0f1d832ed1fb ("usb: xhci: Add port test modes support for usb2")
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Both xhci_hub_control and xhci_disable_slot tries to hold spinlock, the
spinlock recursion occurs when enters USB2 test mode. Fix it by unlock
spinlock before calling xhci_disable_slot.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 0f1d832ed1fb ("usb: xhci: Add port test modes support for usb2")
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: fix 20000ms port resume timeout</title>
<updated>2017-07-20T12:40:36+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-07-20T11:48:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a54408d0a004757789863d74e29c2297edae0b4d'/>
<id>a54408d0a004757789863d74e29c2297edae0b4d</id>
<content type='text'>
A uncleared PLC (port link change) bit will prevent furuther port event
interrupts for that port. Leaving it uncleared caused get_port_status()
to timeout after 20000ms while waiting to get the final port event
interrupt for resume -&gt; U0 state change.

This is a targeted fix for a specific case where we get a port resume event
racing with xhci resume. The port event interrupt handler notices xHC is
not yet running and bails out early, leaving PLC uncleared.

The whole xhci port resuming needs more attention, but while working on it
it anyways makes sense to always ensure PLC is cleared in get_port_status
before setting a new link state and waiting for its completion.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A uncleared PLC (port link change) bit will prevent furuther port event
interrupts for that port. Leaving it uncleared caused get_port_status()
to timeout after 20000ms while waiting to get the final port event
interrupt for resume -&gt; U0 state change.

This is a targeted fix for a specific case where we get a port resume event
racing with xhci resume. The port event interrupt handler notices xHC is
not yet running and bails out early, leaving PLC uncleared.

The whole xhci port resuming needs more attention, but while working on it
it anyways makes sense to always ensure PLC is cleared in get_port_status
before setting a new link state and waiting for its completion.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: xhci: Issue stop EP command only when the EP state is running</title>
<updated>2017-07-20T12:40:35+00:00</updated>
<author>
<name>Shyam Sundar S K</name>
<email>Shyam-sundar.S-k@amd.com</email>
</author>
<published>2017-07-20T11:48:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=28a2369f7d72ece55089f33e7d7b9c1223673cc3'/>
<id>28a2369f7d72ece55089f33e7d7b9c1223673cc3</id>
<content type='text'>
on AMD platforms with SNPS 3.1 USB controller if stop endpoint command is
issued the controller does not respond, when the EP is not in running
state. HW completes the command execution and reports
"Context State Error" completion code. This is as per the spec. However
HW on receiving the second command additionally marks EP to Flow control
state in HW which is RTL bug. This bug causes the HW not to respond
to any further doorbells that are rung by the driver. This makes the EP
to not functional anymore and causes gross functional failures.

As a workaround, not to hit this problem, it's better to check the EP state
and issue a stop EP command only when the EP is in running state.

As a sidenote, even with this patch there is still a possibility of
triggering the RTL bug if the context state races with the stop endpoint
command as described in xHCI spec 4.6.9

[code simplification and reworded sidenote in commit message -Mathias]
Signed-off-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt;
Signed-off-by: Nehal Shah &lt;Nehal-bakulchandra.Shah@amd.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
on AMD platforms with SNPS 3.1 USB controller if stop endpoint command is
issued the controller does not respond, when the EP is not in running
state. HW completes the command execution and reports
"Context State Error" completion code. This is as per the spec. However
HW on receiving the second command additionally marks EP to Flow control
state in HW which is RTL bug. This bug causes the HW not to respond
to any further doorbells that are rung by the driver. This makes the EP
to not functional anymore and causes gross functional failures.

As a workaround, not to hit this problem, it's better to check the EP state
and issue a stop EP command only when the EP is in running state.

As a sidenote, even with this patch there is still a possibility of
triggering the RTL bug if the context state races with the stop endpoint
command as described in xHCI spec 4.6.9

[code simplification and reworded sidenote in commit message -Mathias]
Signed-off-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt;
Signed-off-by: Nehal Shah &lt;Nehal-bakulchandra.Shah@amd.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Bad Ethernet performance plugged in ASM1042A host</title>
<updated>2017-07-20T12:40:35+00:00</updated>
<author>
<name>Jiahau Chang</name>
<email>jiahau@gmail.com</email>
</author>
<published>2017-07-20T11:48:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9da5a1092b13468839b1a864b126cacfb72ad016'/>
<id>9da5a1092b13468839b1a864b126cacfb72ad016</id>
<content type='text'>
When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow control handling of ASM1042A.
The register we modify is changes the behavior

[use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias]
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Jiahau Chang &lt;Lars_chang@asmedia.com.tw&gt;
Signed-off-by: Ian Pilcher &lt;arequipeno@gmail.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow control handling of ASM1042A.
The register we modify is changes the behavior

[use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias]
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Jiahau Chang &lt;Lars_chang@asmedia.com.tw&gt;
Signed-off-by: Ian Pilcher &lt;arequipeno@gmail.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Fix NULL pointer dereference when cleaning up streams for removed host</title>
<updated>2017-07-20T12:40:35+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-07-20T11:48:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4b895868bb2da60a386a17cde3bf9ecbc70c79f4'/>
<id>4b895868bb2da60a386a17cde3bf9ecbc70c79f4</id>
<content type='text'>
This off by one in stream_id indexing caused NULL pointer dereference and
soft lockup on machines with USB attached SCSI devices connected to a
hotpluggable xhci controller.

The code that cleans up pending URBs for dead hosts tried to dereference
a stream ring at the invalid stream_id 0.
ep-&gt;stream_info-&gt;stream_rings[0] doesn't point to a ring.

Start looping stream_id from 1 like in all the other places in the driver,
and check that the ring exists before trying to kill URBs on it.

Reported-by: rocko r &lt;rockorequin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This off by one in stream_id indexing caused NULL pointer dereference and
soft lockup on machines with USB attached SCSI devices connected to a
hotpluggable xhci controller.

The code that cleans up pending URBs for dead hosts tried to dereference
a stream ring at the invalid stream_id 0.
ep-&gt;stream_info-&gt;stream_rings[0] doesn't point to a ring.

Start looping stream_id from 1 like in all the other places in the driver,
and check that the ring exists before trying to kill URBs on it.

Reported-by: rocko r &lt;rockorequin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'fixes-for-v4.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus</title>
<updated>2017-07-19T11:15:30+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2017-07-19T11:15:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3d69f3a8c2ed1c7f322d23145bc0c3d980ebbacb'/>
<id>3d69f3a8c2ed1c7f322d23145bc0c3d980ebbacb</id>
<content type='text'>
Felipe writes:

usb: fixes for v4.13-rc2

First set of fixes for the current -rc cycle. Only three fixes on dwc3
this time around (proper order for getting a PHY reference, fix for
unmapping DMA and a fix for requesting IRQ on the OMAP glue layer).

Most fixes are on the renesas USB controller, fixing several old bugs
with most going to stable.

dwc2 also learned that it *must* reset USB Address to zero on Reset
interrupts.

Apart from these, some drivers needed HAS_DMA dependency and there's a
sparse warning fix for bdc udc.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Felipe writes:

usb: fixes for v4.13-rc2

First set of fixes for the current -rc cycle. Only three fixes on dwc3
this time around (proper order for getting a PHY reference, fix for
unmapping DMA and a fix for requesting IRQ on the OMAP glue layer).

Most fixes are on the renesas USB controller, fixing several old bugs
with most going to stable.

dwc2 also learned that it *must* reset USB Address to zero on Reset
interrupts.

Apart from these, some drivers needed HAS_DMA dependency and there's a
sparse warning fix for bdc udc.
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: renesas_usbhs: gadget: disable all eps when the driver stops</title>
<updated>2017-07-19T07:38:22+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2017-07-19T07:16:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b8b9c974afee685789fcbb191b52d1790be3608c'/>
<id>b8b9c974afee685789fcbb191b52d1790be3608c</id>
<content type='text'>
A gadget driver will not disable eps immediately when -&gt;disconnect()
is called. But, since this driver assumes all eps stop after
the -&gt;disconnect(), unexpected behavior happens (especially in system
suspend).
So, this patch disables all eps in usbhsg_try_stop(). After disabling
eps by renesas_usbhs driver, since some functions will be called by
both a gadget and renesas_usbhs driver, renesas_usbhs driver should
protect uep-&gt;pipe. To protect uep-&gt;pipe easily, this patch adds a new
lock in struct usbhsg_uep.

Fixes: 2f98382dc ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
Cc: &lt;stable@vger.kernel.org&gt; # v3.0+
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A gadget driver will not disable eps immediately when -&gt;disconnect()
is called. But, since this driver assumes all eps stop after
the -&gt;disconnect(), unexpected behavior happens (especially in system
suspend).
So, this patch disables all eps in usbhsg_try_stop(). After disabling
eps by renesas_usbhs driver, since some functions will be called by
both a gadget and renesas_usbhs driver, renesas_usbhs driver should
protect uep-&gt;pipe. To protect uep-&gt;pipe easily, this patch adds a new
lock in struct usbhsg_uep.

Fixes: 2f98382dc ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
Cc: &lt;stable@vger.kernel.org&gt; # v3.0+
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: renesas_usbhs: fix usbhsc_resume() for !USBHSF_RUNTIME_PWCTRL</title>
<updated>2017-07-19T07:38:16+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2017-07-19T07:16:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=59a0879a0e17b2e43ecdc5e3299da85b8410d7ce'/>
<id>59a0879a0e17b2e43ecdc5e3299da85b8410d7ce</id>
<content type='text'>
This patch fixes an issue that some registers may be not initialized
after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise,
if a cable is not connected, the driver will not enable INTENB0.VBSE
after resume. And then, the driver cannot detect the VBUS.

Fixes: ca8a282a5373 ("usb: gadget: renesas_usbhs: add suspend/resume support")
Cc: &lt;stable@vger.kernel.org&gt; # v3.2+
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes an issue that some registers may be not initialized
after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise,
if a cable is not connected, the driver will not enable INTENB0.VBSE
after resume. And then, the driver cannot detect the VBUS.

Fixes: ca8a282a5373 ("usb: gadget: renesas_usbhs: add suspend/resume support")
Cc: &lt;stable@vger.kernel.org&gt; # v3.2+
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: udc: renesas_usb3: protect usb3_ep-&gt;started in usb3_start_pipen()</title>
<updated>2017-07-18T13:20:31+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2017-07-18T12:26:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=781001ff9678e5df048cca3d4290c1638a28cafa'/>
<id>781001ff9678e5df048cca3d4290c1638a28cafa</id>
<content type='text'>
This patch fixes an issue that unexpected behavior happens when
both the interrupt handler and renesas_usb3_ep_enable() are called.
In this case, since usb3_start_pipen() checked the usb3_ep-&gt;started,
but the flags was not protected. So, this patch protects the flag
by usb3-&gt;lock. Since renesas_usb3_ep_enable() for EP0 will be not called,
this patch doesn't take care of usb3_start_pipe0().

Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes an issue that unexpected behavior happens when
both the interrupt handler and renesas_usb3_ep_enable() are called.
In this case, since usb3_start_pipen() checked the usb3_ep-&gt;started,
but the flags was not protected. So, this patch protects the flag
by usb3-&gt;lock. Since renesas_usb3_ep_enable() for EP0 will be not called,
this patch doesn't take care of usb3_start_pipe0().

Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
