All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] usb: gadget: eem: fix echo command packet response issue
@ 2021-06-16 11:51 Linyu Yuan
  2021-06-17 13:22 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 3+ messages in thread
From: Linyu Yuan @ 2021-06-16 11:51 UTC (permalink / raw)
  To: Felipe Balbi, Greg Kroah-Hartman, linux-usb; +Cc: linux-kernel, Linyu Yuan

From: Linyu Yuan <linyyuan@codeaurora.com>

when receive eem echo command, it will send a response,
but queue this response to the usb request which allocate
from gadget device endpoint zero,
and transmit the request to IN endpoint of eem interface.

on dwc3 gadget, it will trigger following warning in function
__dwc3_gadget_ep_queue(),

	if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
				&req->request, req->dep->name))
		return -EINVAL;

fix it by allocating a usb request from IN endpoint of eem interface,
and transmit the usb request to same IN endpoint of eem interface.

Signed-off-by: Linyu Yuan <linyyuan@codeaurora.com>
---

v3: use exist goto label 'next'
v2: fix mail format and expand commit message

 drivers/usb/gadget/function/f_eem.c | 43 ++++++++++++++++++++++++++---
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_eem.c b/drivers/usb/gadget/function/f_eem.c
index 2cd9942707b4..5d38f29bda72 100644
--- a/drivers/usb/gadget/function/f_eem.c
+++ b/drivers/usb/gadget/function/f_eem.c
@@ -30,6 +30,11 @@ struct f_eem {
 	u8				ctrl_id;
 };
 
+struct in_context {
+	struct sk_buff	*skb;
+	struct usb_ep	*ep;
+};
+
 static inline struct f_eem *func_to_eem(struct usb_function *f)
 {
 	return container_of(f, struct f_eem, port.func);
@@ -320,9 +325,12 @@ static int eem_bind(struct usb_configuration *c, struct usb_function *f)
 
 static void eem_cmd_complete(struct usb_ep *ep, struct usb_request *req)
 {
-	struct sk_buff *skb = (struct sk_buff *)req->context;
+	struct in_context *ctx = req->context;
 
-	dev_kfree_skb_any(skb);
+	dev_kfree_skb_any(ctx->skb);
+	kfree(req->buf);
+	usb_ep_free_request(ctx->ep, req);
+	kfree(ctx);
 }
 
 /*
@@ -410,7 +418,9 @@ static int eem_unwrap(struct gether *port,
 		 * b15:		bmType (0 == data, 1 == command)
 		 */
 		if (header & BIT(15)) {
-			struct usb_request	*req = cdev->req;
+			struct usb_request	*req;
+			struct in_context	*ctx;
+			struct usb_ep		*ep;
 			u16			bmEEMCmd;
 
 			/* EEM command packet format:
@@ -439,11 +449,36 @@ static int eem_unwrap(struct gether *port,
 				skb_trim(skb2, len);
 				put_unaligned_le16(BIT(15) | BIT(11) | len,
 							skb_push(skb2, 2));
+
+				ep = port->in_ep;
+				req = usb_ep_alloc_request(ep, GFP_ATOMIC);
+				if (!req) {
+					dev_kfree_skb_any(skb2);
+					goto next;
+				}
+
+				req->buf = kmalloc(skb2->len, GFP_KERNEL);
+				if (!req->buf) {
+					usb_ep_free_request(ep, req);
+					dev_kfree_skb_any(skb2);
+					goto next;
+				}
+
+				ctx = kmalloc(sizeof(*ctx), GFP_KERNEL);
+				if (!ctx) {
+					kfree(req->buf);
+					usb_ep_free_request(ep, req);
+					dev_kfree_skb_any(skb2);
+					goto next;
+				}
+				ctx->skb = skb2;
+				ctx->ep = ep;
+
 				skb_copy_bits(skb2, 0, req->buf, skb2->len);
 				req->length = skb2->len;
 				req->complete = eem_cmd_complete;
 				req->zero = 1;
-				req->context = skb2;
+				req->context = ctx;
 				if (usb_ep_queue(port->in_ep, req, GFP_ATOMIC))
 					DBG(cdev, "echo response queue fail\n");
 				break;
-- 
2.25.1


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v3] usb: gadget: eem: fix echo command packet response issue
  2021-06-16 11:51 [PATCH v3] usb: gadget: eem: fix echo command packet response issue Linyu Yuan
@ 2021-06-17 13:22 ` Greg Kroah-Hartman
  2021-06-18  1:19   ` linyyuan
  0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2021-06-17 13:22 UTC (permalink / raw)
  To: Linyu Yuan; +Cc: Felipe Balbi, linux-usb, linux-kernel, Linyu Yuan

On Wed, Jun 16, 2021 at 07:51:42PM +0800, Linyu Yuan wrote:
> From: Linyu Yuan <linyyuan@codeaurora.com>
> 
> when receive eem echo command, it will send a response,
> but queue this response to the usb request which allocate
> from gadget device endpoint zero,
> and transmit the request to IN endpoint of eem interface.
> 
> on dwc3 gadget, it will trigger following warning in function
> __dwc3_gadget_ep_queue(),
> 
> 	if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
> 				&req->request, req->dep->name))
> 		return -EINVAL;

Is this really a problem?  I am guessing the request will not work at
all?  Or just warn and continue with it?

How was this ever working?

> 
> fix it by allocating a usb request from IN endpoint of eem interface,
> and transmit the usb request to same IN endpoint of eem interface.
> 
> Signed-off-by: Linyu Yuan <linyyuan@codeaurora.com>
> ---

What commit does this fix?  Should it be backported to older stable
kernels?  If so, how far back?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v3] usb: gadget: eem: fix echo command packet response issue
  2021-06-17 13:22 ` Greg Kroah-Hartman
@ 2021-06-18  1:19   ` linyyuan
  0 siblings, 0 replies; 3+ messages in thread
From: linyyuan @ 2021-06-18  1:19 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: Felipe Balbi, linux-usb, linux-kernel, Linyu Yuan

On 2021-06-17 21:22, Greg Kroah-Hartman wrote:
> On Wed, Jun 16, 2021 at 07:51:42PM +0800, Linyu Yuan wrote:
>> From: Linyu Yuan <linyyuan@codeaurora.com>
>> 
>> when receive eem echo command, it will send a response,
>> but queue this response to the usb request which allocate
>> from gadget device endpoint zero,
>> and transmit the request to IN endpoint of eem interface.
>> 
>> on dwc3 gadget, it will trigger following warning in function
>> __dwc3_gadget_ep_queue(),
>> 
>> 	if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
>> 				&req->request, req->dep->name))
>> 		return -EINVAL;
> 
> Is this really a problem?  I am guessing the request will not work at
> all?  Or just warn and continue with it?
yes, it is a real problem of f_eem driver which request from it will 
queue fail,
which means following error happen.
       if (usb_ep_queue(port->in_ep, req, GFP_ATOMIC))
		DBG(cdev, "echo response queue fail\n");
> 
> How was this ever working?
i think for eem link command packet, normally we will never seen it if 
both side arelinux system.
as eem driver will add data header and send it to peer.

only it is eem driver bug which read network data as link command packet 
(this issue fixed in my last change).
> 
>> 
>> fix it by allocating a usb request from IN endpoint of eem interface,
>> and transmit the usb request to same IN endpoint of eem interface.
>> 
>> Signed-off-by: Linyu Yuan <linyyuan@codeaurora.com>
>> ---
> 
> What commit does this fix?  Should it be backported to older stable
> kernels?  If so, how far back?
yes, we can backport to all active LTS kernel.
> 
> thanks,
> 
> greg k-h

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-06-18  1:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-16 11:51 [PATCH v3] usb: gadget: eem: fix echo command packet response issue Linyu Yuan
2021-06-17 13:22 ` Greg Kroah-Hartman
2021-06-18  1:19   ` linyyuan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.