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

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

[Chunfeng Yun]

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(+)

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.
-- 
1.9.1

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

[Chunfeng Yun]

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(+)

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.
-- 
1.9.1

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

[Chunfeng Yun]

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(+)

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.

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

[Chunfeng Yun]

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 at 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(+)

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.
-- 
1.9.1

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

[Greg Kroah-Hartman]

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

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

[Greg Kroah-Hartman]

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

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

[Greg Kroah-Hartman]

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

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

[Chunfeng Yun]

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

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

[Chunfeng Yun]

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

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

[Chunfeng Yun]

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

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

[Chunfeng Yun]

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

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

[Greg Kroah-Hartman]

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

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

[Greg Kroah-Hartman]

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

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

[Greg Kroah-Hartman]

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