Hi Mathias
The kernel version is 3.8.2, but patches of 3.17 are back ported into it.
> Event ring dequeue is increased either in handle_tx_event(), cleanup:
> if (trb_comp_code == COMP_MISSED_INT || !ep->skip) {
> inc_deq(xhci, xhci->event_ring);
Event ring dequeue should be incremented for "stop,-invalid length” transfer event as well (as described in the patch below):
Signed-off-by: Saurov Shyam <saurov.s@xxxxxxxxxxx>
---
drivers/usb/host/xhci-ring.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7d34cbf..4d2817d 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2500,7 +2500,9 @@ cleanup:
* Do not update event ring dequeue pointer if ep->skip is set.
* Will roll back to continue process missed tds.
*/
- if (trb_comp_code == COMP_MISSED_INT || !ep->skip) {
+ if (trb_comp_code == COMP_MISSED_INT ||
+ trb_comp_code == COMP_STOP_INVAL ||
+ !ep->skip) {
inc_deq(xhci, xhci->event_ring);
}
--
1.7.9.5
> Or then in xhci_handle_event() if handle_tx_event() returns error.
> For example in handle_tx_event() if event->buffer is null, then
> ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer)); is NULL
> and the check immediately after would return with -ENODEV
If event-> buffer is valid for "stop,-invalid length” transfer event, hence error condition will not happen.
So the above patch is applicable in this sense.
> P.S. The potion of code was not a suggestion, it was copypasted from the upstream xhci driver, and has
> looked like that since 3.17 kernel
By the phrase “code you suggested” I meant is “code what you referred”. Sorry for miscommunication!
------- Original Message -------
Sender : Mathias Nyman<mathias.nyman@xxxxxxxxxxxxxxx>
Date : Jul 02, 2015 17:59 (GMT+05:30)
Title : Re: [PATCH] xHCI: FSE handled cleanly by incrementing event dequeue pointer
Hi
On 02.07.2015 13:45, SAUROV KANTI SHYAM wrote:
> Some undefined values, mostly null are coming in event->buffer in my case for "stop,-invalid length” transfer event.
That doesn't sound good, what xhci vendor and version are you using?
Have you seen/tried this on other xhci hw as well?
What kernel version are you using? are there any custom xhci driver modification in it?
> However, in the portion of the code you suggested does not increment the dequeue pointer of transfer event ring, for trb_comp_code = COMP_STOP_INVAL.
> In handle_tx_event() cleanup: does not increment the dequeue pointer of transfer event ring.
> In xhci_handle_event():
> …
> case TRB_TYPE(TRB_TRANSFER):
> ret = handle_tx_event(xhci, &event->trans_event);
> if (ret < 0)
> xhci->error_bitmask |= 1 << 9;
> else
> update_ptrs = 0;
> …
> if (update_ptrs)
> /* Update SW event ring dequeue pointer */
> inc_deq(xhci, xhci->event_ring);
> …
> As update_ptrs=0, inc_deq(xhci, xhci->event_ring) won't run.
> Regards,
Event ring dequeue is increased either in handle_tx_event(), cleanup:
if (trb_comp_code == COMP_MISSED_INT || !ep->skip) {
inc_deq(xhci, xhci->event_ring);
Or then in xhci_handle_event() if handle_tx_event() returns error.
For example in handle_tx_event() if event->buffer is null, then
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer)); is NULL
and the check immediately after would return with -ENODEV
-Mathias
P.S. The potion of code was not a suggestion, it was copypasted from the upstream xhci driver, and has
looked like that since 3.17 kernel��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
