<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/usb/host, branch v3.19.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>xhci: Workaround for PME stuck issues in Intel xhci</title>
<updated>2015-03-18T13:11:02+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2015-03-06T15:23:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f51b8a1bd956b9d0edc995a33c2ced44217643d1'/>
<id>f51b8a1bd956b9d0edc995a33c2ced44217643d1</id>
<content type='text'>
commit b8cb91e058cd0c0f02059c1207293c5b31d350fa upstream.

The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
workaround for a Stuck PME that might either block PME events in suspend,
or create spurious PME events preventing runtime suspend.

Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
PMCTRL register at offset 0x80a4, in both suspend resume callbacks

Without this, xhci connected usb devices might never be able to wake up the
system from suspend, or prevent device from going to suspend (xhci d3)

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>
commit b8cb91e058cd0c0f02059c1207293c5b31d350fa upstream.

The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
workaround for a Stuck PME that might either block PME events in suspend,
or create spurious PME events preventing runtime suspend.

Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
PMCTRL register at offset 0x80a4, in both suspend resume callbacks

Without this, xhci connected usb devices might never be able to wake up the
system from suspend, or prevent device from going to suspend (xhci d3)

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 reporting of 0-sized URBs in control endpoint</title>
<updated>2015-03-18T13:11:02+00:00</updated>
<author>
<name>Aleksander Morgado</name>
<email>aleksander@aleksander.es</email>
</author>
<published>2015-03-06T15:14:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=19584ca9b13815ee7e565b8f8ec4bf32a2c2c472'/>
<id>19584ca9b13815ee7e565b8f8ec4bf32a2c2c472</id>
<content type='text'>
commit 45ba2154d12fc43b70312198ec47085f10be801a upstream.

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-&gt;actual_length to
urb-&gt;transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb-&gt;actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb-&gt;actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb-&gt;actual_length = 0.

This patch changes the xhci driver to rely on a new td-&gt;urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb-&gt;actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado &lt;aleksander@aleksander.es&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>
commit 45ba2154d12fc43b70312198ec47085f10be801a upstream.

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-&gt;actual_length to
urb-&gt;transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb-&gt;actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb-&gt;actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb-&gt;actual_length = 0.

This patch changes the xhci driver to rely on a new td-&gt;urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb-&gt;actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado &lt;aleksander@aleksander.es&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: Allocate correct amount of scratchpad buffers</title>
<updated>2015-03-18T13:11:01+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2015-02-24T16:27:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7f88b0324fa3b93dd80f2f931ddee1d556d6781a'/>
<id>7f88b0324fa3b93dd80f2f931ddee1d556d6781a</id>
<content type='text'>
commit 6596a926b0b6c80b730a1dd2fa91908e0a539c37 upstream.

Include the high order bit fields for Max scratchpad buffers when
calculating how many scratchpad buffers are needed.

I'm suprised this hasn't caused more issues, we never allocated more than
32 buffers even if xhci needed more. Either we got lucky and xhci never
really used past that area, or then we got enough zeroed dma memory anyway.

Should be backported as far back as possible

Reported-by: Tim Chen &lt;tim.c.chen@linux.intel.com&gt;
Tested-by: Tim Chen &lt;tim.c.chen@linux.intel.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>
commit 6596a926b0b6c80b730a1dd2fa91908e0a539c37 upstream.

Include the high order bit fields for Max scratchpad buffers when
calculating how many scratchpad buffers are needed.

I'm suprised this hasn't caused more issues, we never allocated more than
32 buffers even if xhci needed more. Either we got lucky and xhci never
really used past that area, or then we got enough zeroed dma memory anyway.

Should be backported as far back as possible

Reported-by: Tim Chen &lt;tim.c.chen@linux.intel.com&gt;
Tested-by: Tim Chen &lt;tim.c.chen@linux.intel.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: platform: Move the Marvell quirks after the enabling the clocks</title>
<updated>2015-03-18T13:11:01+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime.ripard@free-electrons.com</email>
</author>
<published>2015-02-24T16:27:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6ae021266fd88e9e1a7394a255e0c28b17e88b7d'/>
<id>6ae021266fd88e9e1a7394a255e0c28b17e88b7d</id>
<content type='text'>
commit 1e7e4fb66489cc84366656ca5318f1cb61afd4ba upstream.

The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.

However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.

Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.

Fix this by running the quirks after the clock has been enabled by the driver.

Signed-off-by: Maxime Ripard &lt;maxime.ripard@free-electrons.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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1e7e4fb66489cc84366656ca5318f1cb61afd4ba upstream.

The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.

However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.

Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.

Fix this by running the quirks after the clock has been enabled by the driver.

Signed-off-by: Maxime Ripard &lt;maxime.ripard@free-electrons.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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)</title>
<updated>2015-03-06T22:57:34+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2015-01-29T20:05:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e4af42b63db9f258a76c515def75e4463c138d4b'/>
<id>e4af42b63db9f258a76c515def75e4463c138d4b</id>
<content type='text'>
commit 074f9dd55f9cab1b82690ed7e44bcf38b9616ce0 upstream.

Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.

This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd.  The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;greg@kroah.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>
commit 074f9dd55f9cab1b82690ed7e44bcf38b9616ce0 upstream.

Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.

This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd.  The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;greg@kroah.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>OHCI: add a quirk for ULi M5237 blocking on reset</title>
<updated>2015-01-09T20:40:37+00:00</updated>
<author>
<name>Arseny Solokha</name>
<email>asolokha@kb.kras.ru</email>
</author>
<published>2014-12-06T02:54:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=56abcab833fafcfaeb2f5b25e0364c1dec45f53e'/>
<id>56abcab833fafcfaeb2f5b25e0364c1dec45f53e</id>
<content type='text'>
Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
board. The code path that was previously specific to NVIDIA controllers
had then become taken for all chips.

However, the M5237 installed on the board wedges solid when accessing
its base+OHCI_FMINTERVAL register, making it impossible to boot any
kernel newer than 3.1.8 on this particular and apparently other similar
machines.

Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.

The patch is suitable for the -next tree as well as all maintained
kernels up to 3.2 inclusive.

Signed-off-by: Arseny Solokha &lt;asolokha@kb.kras.ru&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: stable &lt;stable@vger.kernel.org&gt; # 3.2
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
board. The code path that was previously specific to NVIDIA controllers
had then become taken for all chips.

However, the M5237 installed on the board wedges solid when accessing
its base+OHCI_FMINTERVAL register, making it impossible to boot any
kernel newer than 3.1.8 on this particular and apparently other similar
machines.

Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.

The patch is suitable for the -next tree as well as all maintained
kernels up to 3.2 inclusive.

Signed-off-by: Arseny Solokha &lt;asolokha@kb.kras.ru&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: stable &lt;stable@vger.kernel.org&gt; # 3.2
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: host: ehci-tegra: request deferred probe when failing to get phy</title>
<updated>2015-01-09T18:01:45+00:00</updated>
<author>
<name>Vince Hsu</name>
<email>vinceh@nvidia.com</email>
</author>
<published>2014-12-24T10:16:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f56e67f0a880a5b795cdb5f62614aafe264c5304'/>
<id>f56e67f0a880a5b795cdb5f62614aafe264c5304</id>
<content type='text'>
The commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
failure") changed the condition to return -EPROBE_DEFER to host driver.
Originally the Tegra host driver depended on the returned -EPROBE_DEFER to
get the phy device later when booting. Now we have to do that explicitly.

Signed-off-by: Vince Hsu &lt;vinceh@nvidia.com&gt;
Tested-by: Tomeu Vizoso &lt;tomeu.vizoso@collabora.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>
The commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
failure") changed the condition to return -EPROBE_DEFER to host driver.
Originally the Tegra host driver depended on the returned -EPROBE_DEFER to
get the phy device later when booting. Now we have to do that explicitly.

Signed-off-by: Vince Hsu &lt;vinceh@nvidia.com&gt;
Tested-by: Tomeu Vizoso &lt;tomeu.vizoso@collabora.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Add broken-streams quirk for Fresco Logic FL1000G xhci controllers</title>
<updated>2015-01-09T17:58:49+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2014-12-05T10:11:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7f5c4d631aed243ca89c6673427954210b1628ec'/>
<id>7f5c4d631aed243ca89c6673427954210b1628ec</id>
<content type='text'>
Streams do not work reliabe on Fresco Logic FL1000G xhci controllers,
trying to use them results in errors like this:

21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3570 9067b000 00000000 05000000 01078001
21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3580 9067b400 00000000 05000000 01038001

As always I've ordered a pci-e addon card with a Fresco Logic controller for
myself to see if I can come up with a better fix then the big hammer, in
the mean time this will make uas devices work again (in usb-storage mode)
for FL1000G users.

Reported-by: Marcin Zajączkowski &lt;mszpak@wp.pl&gt;
Cc: stable@vger.kernel.org # 3.15
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.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>
Streams do not work reliabe on Fresco Logic FL1000G xhci controllers,
trying to use them results in errors like this:

21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3570 9067b000 00000000 05000000 01078001
21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3580 9067b400 00000000 05000000 01038001

As always I've ordered a pci-e addon card with a Fresco Logic controller for
myself to see if I can come up with a better fix then the big hammer, in
the mean time this will make uas devices work again (in usb-storage mode)
for FL1000G users.

Reported-by: Marcin Zajączkowski &lt;mszpak@wp.pl&gt;
Cc: stable@vger.kernel.org # 3.15
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: EHCI: adjust error return code</title>
<updated>2015-01-09T17:58:49+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2014-12-04T15:22:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c401e7b4a808d50ab53ef45cb8d0b99b238bf2c9'/>
<id>c401e7b4a808d50ab53ef45cb8d0b99b238bf2c9</id>
<content type='text'>
The USB stack uses error code -ENOSPC to indicate that the periodic
schedule is too full, with insufficient bandwidth to accommodate a new
allocation.  It uses -EFBIG to indicate that an isochronous transfer
could not be linked into the schedule because it would exceed the
number of isochronous packets the host controller driver can handle
(generally because the new transfer would extend too far into the
future).

ehci-hcd uses the wrong error code at one point.  This patch fixes it,
along with a misleading comment and debugging message.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&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>
The USB stack uses error code -ENOSPC to indicate that the periodic
schedule is too full, with insufficient bandwidth to accommodate a new
allocation.  It uses -EFBIG to indicate that an isochronous transfer
could not be linked into the schedule because it would exceed the
number of isochronous packets the host controller driver can handle
(generally because the new transfer would extend too far into the
future).

ehci-hcd uses the wrong error code at one point.  This patch fixes it,
along with a misleading comment and debugging message.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: EHCI: fix initialization bug in iso_stream_schedule()</title>
<updated>2015-01-09T17:58:49+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2014-12-04T15:21:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6d89252a998a695ecb0348fc2d717dc33d90cae9'/>
<id>6d89252a998a695ecb0348fc2d717dc33d90cae9</id>
<content type='text'>
Commit c3ee9b76aa93 (EHCI: improved logic for isochronous scheduling)
introduced the idea of using ehci-&gt;last_iso_frame as the origin (or
base) for the circular calculations involved in modifying the
isochronous schedule.  However, the new code it added used
ehci-&gt;last_iso_frame before the value was properly initialized.  This
patch rectifies the mistake by moving the initialization lines earlier
in iso_stream_schedule().

This fixes Bugzilla #72891.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Fixes: c3ee9b76aa93
Reported-by: Joe Bryant &lt;tenminjoe@yahoo.com&gt;
Tested-by: Joe Bryant &lt;tenminjoe@yahoo.com&gt;
Tested-by: Martin Long &lt;martin@longhome.co.uk&gt;
CC: &lt;stable@vger.kernel.org&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>
Commit c3ee9b76aa93 (EHCI: improved logic for isochronous scheduling)
introduced the idea of using ehci-&gt;last_iso_frame as the origin (or
base) for the circular calculations involved in modifying the
isochronous schedule.  However, the new code it added used
ehci-&gt;last_iso_frame before the value was properly initialized.  This
patch rectifies the mistake by moving the initialization lines earlier
in iso_stream_schedule().

This fixes Bugzilla #72891.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Fixes: c3ee9b76aa93
Reported-by: Joe Bryant &lt;tenminjoe@yahoo.com&gt;
Tested-by: Joe Bryant &lt;tenminjoe@yahoo.com&gt;
Tested-by: Martin Long &lt;martin@longhome.co.uk&gt;
CC: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
