<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/usb/host, branch v2.6.39</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>xHCI: Clear PLC in xhci_bus_resume()</title>
<updated>2011-05-03T18:14:32+00:00</updated>
<author>
<name>Andiry Xu</name>
<email>andiry.xu@amd.com</email>
</author>
<published>2011-04-19T09:17:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4f0871a6c7811a433513c3788a7cce27033bb8b8'/>
<id>4f0871a6c7811a433513c3788a7cce27033bb8b8</id>
<content type='text'>
This patch clears PORT_PLC if xhci_bus_resume() resumes a previous suspended
port, because if a port transition from U3 to U0 state, it will report a
port link state change, and software should clear the corresponding PLC bit.

It also uses hcd-&gt;speed to check if a port is a USB2 protocol port.

The patch fixes the issue that USB keyboard can not wakeup system from
hibernation.

Signed-off-by: Andiry Xu &lt;andiry.xu@amd.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch clears PORT_PLC if xhci_bus_resume() resumes a previous suspended
port, because if a port transition from U3 to U0 state, it will report a
port link state change, and software should clear the corresponding PLC bit.

It also uses hcd-&gt;speed to check if a port is a USB2 protocol port.

The patch fixes the issue that USB keyboard can not wakeup system from
hibernation.

Signed-off-by: Andiry Xu &lt;andiry.xu@amd.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb/isp1760: Report correct urb status after unlink</title>
<updated>2011-05-03T00:07:49+00:00</updated>
<author>
<name>Arvid Brodin</name>
<email>arvid.brodin@enea.com</email>
</author>
<published>2011-04-26T19:46:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d93da492d9a8840a0bdda88e74df8d0f593f1977'/>
<id>d93da492d9a8840a0bdda88e74df8d0f593f1977</id>
<content type='text'>
This fixes a bug in my previous (2.6.38) patch series which caused
urb-&gt;status value to be wrong after unlink (broke usbtest 11, 12).

Signed-off-by: Arvid Brodin &lt;arvid.brodin@enea.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a bug in my previous (2.6.38) patch series which caused
urb-&gt;status value to be wrong after unlink (broke usbtest 11, 12).

Signed-off-by: Arvid Brodin &lt;arvid.brodin@enea.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>omap:usb: add regulator support for EHCI</title>
<updated>2011-05-02T12:29:26+00:00</updated>
<author>
<name>Keshava Munegowda</name>
<email>Keshava_mgowda@ti.com</email>
</author>
<published>2011-04-21T14:22:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6e3d4bec6b1e0829ed8b23be750762255f225019'/>
<id>6e3d4bec6b1e0829ed8b23be750762255f225019</id>
<content type='text'>
in case of ehci phy mode; regulator of phy
should be enabled before initializing the
usbhs core driver.

Signed-off-by: Keshava Munegowda &lt;keshava_mgowda@ti.com&gt;
Tested-by: Steve Calfee &lt;stevecalfee@gmail.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
in case of ehci phy mode; regulator of phy
should be enabled before initializing the
usbhs core driver.

Signed-off-by: Keshava Munegowda &lt;keshava_mgowda@ti.com&gt;
Tested-by: Steve Calfee &lt;stevecalfee@gmail.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "USB: isp1760-hcd: move imask clear after pending work is done"</title>
<updated>2011-04-14T20:37:07+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2011-04-14T20:37:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=753d8534cc190ed144caebc2ea49ab7a43dca662'/>
<id>753d8534cc190ed144caebc2ea49ab7a43dca662</id>
<content type='text'>
This reverts commit 5808544690300071f09eef9ab83a0fb1f60cf1cd.

To quote Richard:
	I don't think this should be mainlined. It was a
	misunderstanding on my part.  If you see all the other hdc
	drivers in the same location, they all do the same thing (i.e.
	clear the interrupt status first, then do the work) that
	"glitch" I think I saw was actually two back-to-back
	interrupts.

	Sebastian (the original author of isp1760) explained it to me a
	few days after my submission.

	sorry for the confusion

Cc: Richard Retanubun &lt;RichardRetanubun@ruggedcom.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 5808544690300071f09eef9ab83a0fb1f60cf1cd.

To quote Richard:
	I don't think this should be mainlined. It was a
	misunderstanding on my part.  If you see all the other hdc
	drivers in the same location, they all do the same thing (i.e.
	clear the interrupt status first, then do the work) that
	"glitch" I think I saw was actually two back-to-back
	interrupts.

	Sebastian (the original author of isp1760) explained it to me a
	few days after my submission.

	sorry for the confusion

Cc: Richard Retanubun &lt;RichardRetanubun@ruggedcom.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xHCI: Implement AMD PLL quirk</title>
<updated>2011-04-13T23:57:37+00:00</updated>
<author>
<name>Andiry Xu</name>
<email>andiry.xu@amd.com</email>
</author>
<published>2011-03-22T09:08:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c41136b05d3fb213a192f76a5688ff83687c1136'/>
<id>c41136b05d3fb213a192f76a5688ff83687c1136</id>
<content type='text'>
This patch disable the optional PM feature inside the Hudson3 platform under
the following conditions:

1. If an isochronous device is connected to xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

The PM feature needs to be disabled to eliminate PLL startup delays when the
link comes out of low power state. The performance of DMA data transfer could
be impacted if system delay were encountered and in addition to the PLL start
up delays. Disabling the PM would leave room for unpredictable system delays
in order to guarantee uninterrupted data transfer to isochronous audio or
video stream devices that require time sensitive information. If data in an
audio/video stream was interrupted then erratic audio or video performance
may be encountered.

AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
quirk code to pci-quirks.c and export them, xHCI driver can call it directly
without having the quirk implementation in itself.

Signed-off-by: Andiry Xu &lt;andiry.xu@amd.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch disable the optional PM feature inside the Hudson3 platform under
the following conditions:

1. If an isochronous device is connected to xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

The PM feature needs to be disabled to eliminate PLL startup delays when the
link comes out of low power state. The performance of DMA data transfer could
be impacted if system delay were encountered and in addition to the PLL start
up delays. Disabling the PM would leave room for unpredictable system delays
in order to guarantee uninterrupted data transfer to isochronous audio or
video stream devices that require time sensitive information. If data in an
audio/video stream was interrupted then erratic audio or video performance
may be encountered.

AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
quirk code to pci-quirks.c and export them, xHCI driver can call it directly
without having the quirk implementation in itself.

Signed-off-by: Andiry Xu &lt;andiry.xu@amd.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Tell USB core both roothubs lost power.</title>
<updated>2011-04-13T23:57:36+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2011-04-13T00:43:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fedd383e33f9ba9b91626f72c593ea327403bf59'/>
<id>fedd383e33f9ba9b91626f72c593ea327403bf59</id>
<content type='text'>
On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:

[  164.748310] usb usb1: root hub lost power or was reset
[  164.748353] usb usb2: root hub lost power or was reset
[  164.748487] usb usb3: root hub lost power or was reset
[  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[  164.870039] hub 4-0:1.0: hub_resume
...
[  164.870054] hub 3-0:1.0: hub_reset_resume

This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active.  It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:

[  164.980044] hub 4-1:1.0: hub_resume
[  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
[  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
[  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980094] hub 4-1:1.0: activate --&gt; -22
[  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980123] hub 4-1:1.0: can't resume port 4, status -22
[  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[  164.980129] usb 4-1.4: can't resume, status -22
[  164.980131] hub 4-1:1.0: logical disconnect on port 4

This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:

[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760

Make sure to inform the USB core that *both* xHCI roothubs lost power.

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:

[  164.748310] usb usb1: root hub lost power or was reset
[  164.748353] usb usb2: root hub lost power or was reset
[  164.748487] usb usb3: root hub lost power or was reset
[  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[  164.870039] hub 4-0:1.0: hub_resume
...
[  164.870054] hub 3-0:1.0: hub_reset_resume

This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active.  It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:

[  164.980044] hub 4-1:1.0: hub_resume
[  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
[  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
[  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980094] hub 4-1:1.0: activate --&gt; -22
[  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980123] hub 4-1:1.0: can't resume port 4, status -22
[  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[  164.980129] usb 4-1.4: can't resume, status -22
[  164.980131] hub 4-1:1.0: logical disconnect on port 4

This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:

[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760

Make sure to inform the USB core that *both* xHCI roothubs lost power.

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: xhci - also free streams when resetting devices</title>
<updated>2011-04-13T23:57:31+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dtor@vmware.com</email>
</author>
<published>2011-04-13T06:06:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2dea75d96ade3c7cd2bfe73f99c7b3291dc3d03a'/>
<id>2dea75d96ade3c7cd2bfe73f99c7b3291dc3d03a</id>
<content type='text'>
Currently, when resetting a device, xHCI driver disables all but one
endpoints and frees their rings, but leaves alone any streams that
might have been allocated. Later, when users try to free allocated
streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
ep-&gt;ring is NULL.

Let's free not only rings but also stream data as well, so that
calling free_streams() on a device that was reset will be safe.

This should be queued for stable trees back to 2.6.35.

Reviewed-by: Micah Elizabeth Scott &lt;micah@vmware.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dtor@vmware.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Cc: stable@kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, when resetting a device, xHCI driver disables all but one
endpoints and frees their rings, but leaves alone any streams that
might have been allocated. Later, when users try to free allocated
streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
ep-&gt;ring is NULL.

Let's free not only rings but also stream data as well, so that
calling free_streams() on a device that was reset will be safe.

This should be queued for stable trees back to 2.6.35.

Reviewed-by: Micah Elizabeth Scott &lt;micah@vmware.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dtor@vmware.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Cc: stable@kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Fix NULL pointer deref in handle_port_status()</title>
<updated>2011-04-13T23:19:49+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2011-03-24T15:02:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=386139d7c8f22d4983ca89de35d339cc41bb0996'/>
<id>386139d7c8f22d4983ca89de35d339cc41bb0996</id>
<content type='text'>
When we get a port status change event, we need to figure out what type of
port it came from: a USB 3.0 port, or a USB 2.0/1.1 port.  We can't know
which usb_hcd to use until that point, so hcd will be NULL for part of the
function.  Unfortunately, if any of the sanity checks fail, we'll jump to
the cleanup label before hcd is set to a valid pointer, and then we'll
attempt to tell the USB core to kick the hcd, which is NULL.

Skip kicking the roothub if the sanity checks fail.

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we get a port status change event, we need to figure out what type of
port it came from: a USB 3.0 port, or a USB 2.0/1.1 port.  We can't know
which usb_hcd to use until that point, so hcd will be NULL for part of the
function.  Unfortunately, if any of the sanity checks fail, we'll jump to
the cleanup label before hcd is set to a valid pointer, and then we'll
attempt to tell the USB core to kick the hcd, which is NULL.

Skip kicking the roothub if the sanity checks fail.

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: xhci - fix math in xhci_get_endpoint_interval()</title>
<updated>2011-04-13T23:19:48+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dtor@vmware.com</email>
</author>
<published>2011-03-24T05:41:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dfa49c4ad120a784ef1ff0717168aa79f55a483a'/>
<id>dfa49c4ad120a784ef1ff0717168aa79f55a483a</id>
<content type='text'>
When parsing exponent-expressed intervals we subtract 1 from the
value and then expect it to match with original + 1, which is
highly unlikely, and we end with frequent spew:

	usb 3-4: ep 0x83 - rounding interval to 512 microframes

Also, parsing interval for fullspeed isochronous endpoints was
incorrect - according to USB spec they use exponent-based
intervals (but xHCI spec claims frame-based intervals). I trust
USB spec more, especially since USB core agrees with it.

This should be queued for stable kernels back to 2.6.31.

Reviewed-by: Micah Elizabeth Scott &lt;micah@vmware.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dtor@vmware.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Cc: stable@kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When parsing exponent-expressed intervals we subtract 1 from the
value and then expect it to match with original + 1, which is
highly unlikely, and we end with frequent spew:

	usb 3-4: ep 0x83 - rounding interval to 512 microframes

Also, parsing interval for fullspeed isochronous endpoints was
incorrect - according to USB spec they use exponent-based
intervals (but xHCI spec claims frame-based intervals). I trust
USB spec more, especially since USB core agrees with it.

This should be queued for stable kernels back to 2.6.31.

Reviewed-by: Micah Elizabeth Scott &lt;micah@vmware.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dtor@vmware.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Cc: stable@kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: xhci: simplify logic of skipping missed isoc TDs</title>
<updated>2011-04-13T23:19:48+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dtor@vmware.com</email>
</author>
<published>2011-03-24T03:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=926008c9386dde09b015753b6681c502177baa30'/>
<id>926008c9386dde09b015753b6681c502177baa30</id>
<content type='text'>
The logic of the handling Missed Service Error Events was pretty
confusing as we were checking the same condition several times.
In addition, it caused compiler warning since the compiler could
not figure out that event_trb is actually unused in case we are
skipping current TD.

Fix that by rearranging "skip" condition checks, and factor out
skip_isoc_td() so that it is called explicitly.

Signed-off-by: Dmitry Torokhov &lt;dtor@vmware.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The logic of the handling Missed Service Error Events was pretty
confusing as we were checking the same condition several times.
In addition, it caused compiler warning since the compiler could
not figure out that event_trb is actually unused in case we are
skipping current TD.

Fix that by rearranging "skip" condition checks, and factor out
skip_isoc_td() so that it is called explicitly.

Signed-off-by: Dmitry Torokhov &lt;dtor@vmware.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
