Hi,
On 04/15/2014 09:42 PM, Julius Werner wrote:
+hdegoede
I tried to apply this patch on top of 3.15-rc1, but it fails because of the
streams support added to xhci_find_new_dequeue_state()
After some manual editing the interesting parts of
xhci_find_new_dequeue_state() looks like this:
@@
+hdegoede
> I tried to apply this patch on top of 3.15-rc1, but it fails because of the
> streams support added to xhci_find_new_dequeue_state()
>
> After some manual editing the interesting parts of
> xhci_find_new_dequeue_state() looks like this:
>
> @@ -577,46 +568,57 @@ void
On 04/03/2014 12:29 AM, Julius Werner wrote:
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this up
On 04/03/2014 12:29 AM, Julius Werner wrote:
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this up
+hdegoede
I tried to apply this patch on top of 3.15-rc1, but it fails because of the
streams support added to xhci_find_new_dequeue_state()
After some manual editing the interesting parts of
xhci_find_new_dequeue_state() looks like this:
@@ -577,46 +568,57 @@ void
Hi,
On 04/15/2014 09:42 PM, Julius Werner wrote:
+hdegoede
I tried to apply this patch on top of 3.15-rc1, but it fails because of the
streams support added to xhci_find_new_dequeue_state()
After some manual editing the interesting parts of
xhci_find_new_dequeue_state() looks like this:
@@
Hi
On 04/03/2014 12:29 AM, Julius Werner wrote:
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this
Hi
On 04/03/2014 12:29 AM, Julius Werner wrote:
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this
Hi Mathias,
> The patch looks fine. Mathias is taking over for xHCI driver
> maintainership in 3.15. He's currently handling queuing bug fix patches
> for 3.14 while I finish queueing feature patches for 3.15. Mathias,
> will you test and queue this up for 3.14?
Did you pick this patch up
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this up for 3.14?
Did you pick this patch up
On Thu, Feb 20, 2014 at 09:12:15PM -0800, Julius Werner wrote:
> We have observed a rare cycle state desync bug after Set TR Dequeue
> Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
> doesn't fetch new TRBs and thus an unresponsive USB device). It always
> triggers when a
On Thu, Feb 20, 2014 at 09:12:15PM -0800, Julius Werner wrote:
We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a
We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the
We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the
14 matches
Mail list logo
