diff mbox series

[v2] usb: xhci: fix interrupt transfer error happened on MTK platforms

Message ID e8698cc5710a9d1f25e33e2201e2177bfbfec75c.1536305256.git.chunfeng.yun@mediatek.com (mailing list archive)
State New, archived
Headers show
Series [v2] usb: xhci: fix interrupt transfer error happened on MTK platforms | expand

Commit Message

Chunfeng Yun Sept. 7, 2018, 7:29 a.m. UTC
The MTK xHCI controller use some reserved bytes in endpoint context for
bandwidth scheduling, so need keep them in xhci_endpoint_copy();

The issue is introduced by:
commit f5249461b504 ("xhci: Clear the host side toggle manually when
endpoint is soft reset")
It resets endpoints and will drop bandwidth scheduling parameters used
by interrupt or isochronous endpoints on MTK xHCI controller.
Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when
endpoint is soft reset")

Cc: stable@vger.kernel.org
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Tested-by: Sean Wang <sean.wang@mediatek.com>
---
v2: add fix tag, Cc and Tested-by
---
 drivers/usb/host/xhci-mem.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Greg KH Sept. 7, 2018, 7:42 a.m. UTC | #1
On Fri, Sep 07, 2018 at 03:29:12PM +0800, Chunfeng Yun wrote:
> The MTK xHCI controller use some reserved bytes in endpoint context for
> bandwidth scheduling, so need keep them in xhci_endpoint_copy();

If they are "reserved" shouldn't they be properly named?  And by using
reserved bytes, isn't that a spec violation?

thanks,

greg k-h
Chunfeng Yun Sept. 7, 2018, 8:43 a.m. UTC | #2
Hi,

On Fri, 2018-09-07 at 09:42 +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 07, 2018 at 03:29:12PM +0800, Chunfeng Yun wrote:
> > The MTK xHCI controller use some reserved bytes in endpoint context for
> > bandwidth scheduling, so need keep them in xhci_endpoint_copy();
> 
> If they are "reserved" shouldn't they be properly named?  And by using
> reserved bytes, isn't that a spec violation?
It indeed violates the spec, "they shall be treated by system software
as Reserved and Opaque", and it's a quirk of the MTK xHCI controller.

> 
> thanks,
> 
> greg k-h
Greg KH Sept. 7, 2018, 8:56 a.m. UTC | #3
On Fri, Sep 07, 2018 at 04:43:46PM +0800, Chunfeng Yun wrote:
> Hi,
> 
> On Fri, 2018-09-07 at 09:42 +0200, Greg Kroah-Hartman wrote:
> > On Fri, Sep 07, 2018 at 03:29:12PM +0800, Chunfeng Yun wrote:
> > > The MTK xHCI controller use some reserved bytes in endpoint context for
> > > bandwidth scheduling, so need keep them in xhci_endpoint_copy();
> > 
> > If they are "reserved" shouldn't they be properly named?  And by using
> > reserved bytes, isn't that a spec violation?
> It indeed violates the spec, "they shall be treated by system software
> as Reserved and Opaque", and it's a quirk of the MTK xHCI controller.

So as the "system software" here, we should just ignore them otherwise
we violate the spec?  :)

Anyway, that's fine, no objection from me for the patch, thanks.

greg k-h
diff mbox series

Patch

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ef350c3..b1f27aa 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1613,6 +1613,10 @@  void xhci_endpoint_copy(struct xhci_hcd *xhci,
 	in_ep_ctx->ep_info2 = out_ep_ctx->ep_info2;
 	in_ep_ctx->deq = out_ep_ctx->deq;
 	in_ep_ctx->tx_info = out_ep_ctx->tx_info;
+	if (xhci->quirks & XHCI_MTK_HOST) {
+		in_ep_ctx->reserved[0] = out_ep_ctx->reserved[0];
+		in_ep_ctx->reserved[1] = out_ep_ctx->reserved[1];
+	}
 }
 
 /* Copy output xhci_slot_ctx to the input xhci_slot_ctx.