All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Chen <peter.chen@nxp.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Cc: dl-linux-imx <linux-imx@nxp.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Jun Li <jun.li@nxp.com>
Subject: RE: [PATCH 1/1] usb: chipidea: udc: workaround for endpoint conflict issue
Date: Thu, 30 May 2019 08:48:26 +0000	[thread overview]
Message-ID: <VI1PR04MB53274A6AA3D9F1DD613102858B180@VI1PR04MB5327.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <2036f4d4-1d5d-f0b3-f0cb-5df59cc91be9@cogentembedded.com>

 
> On 30.05.2019 9:45, Peter Chen wrote:
> 
> > An endpoint conflict occurs when the USB is working in device mode
> > during an isochronous communication. When the endpointA IN direction
> > is an isochronous IN endpoint, and the host sends an IN token to
> > endpointA on another device, then the OUT transaction may be missed
> > regardless the OUT endpoint number. Generally, this occurs when the
> > device is connected to the host through a hub and other devices are
> > connected to the same hub.
> >
> > The affected OUT endpoint can be either control, bulk, isochronous, or
> > an interrupt endpoint. After the OUT endpoint is primed, if an IN
> > token to the same endpoint number on another device is received, then
> > the OUT endpoint may be unprimed (cannot be detected by software),
> > which causes this endpoint to no longer respond to the host OUT token,
> > and thus, no corresponding interrupt occurs.
> >
> > There is no good workaround for this issue, the only thing the
> > software could do is numbering isochronous IN from the highest
> > endpoint since we have observed most of device number endpoint from the
> lowest.
> >
> > Cc: <stable@vger.kernel.org> #v3.14+
> > Cc: Jun Li <jun.li@nxp.com>
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > ---
> > Changes for v2:
> > - Some coding style improvements
> 
>     Nothing really changed in the patch... :-/
> 
> >   drivers/usb/chipidea/udc.c | 24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 829e947cabf5..411d387a45c9 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1622,6 +1622,29 @@ static int ci_udc_pullup(struct usb_gadget *_gadget,
> int is_on)
> >   static int ci_udc_start(struct usb_gadget *gadget,
> >   			 struct usb_gadget_driver *driver);
> >   static int ci_udc_stop(struct usb_gadget *gadget);
> > +
> > +
> > +/* Match ISOC IN from the highest endpoint */ static struct usb_ep
> > +*ci_udc_match_ep(struct usb_gadget *gadget,
> 
>     Here...
> 
> > +			      struct usb_endpoint_descriptor *desc,
> > +			      struct usb_ss_ep_comp_descriptor *comp_desc) {
> > +	struct ci_hdrc *ci = container_of(gadget, struct ci_hdrc, gadget);
> > +	struct usb_ep *ep;
> > +	u8 type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
> > +
> > +	if ((type == USB_ENDPOINT_XFER_ISOC) &&
> > +		(desc->bEndpointAddress & USB_DIR_IN)) {
> 
>     ... and here.
> 
> > +		list_for_each_entry_reverse(ep, &ci->gadget.ep_list, ep_list) {
> > +			if (ep->caps.dir_in && !ep->claimed)
> > +				return ep;
> > +		}
> > +	}
> > +
> > +	return NULL;
> > +}
> > +
> >   /**
> >    * Device operations part of the API to the USB controller hardware,
> >    * which don't involve endpoints (or i/o)
> [...]
> 

Oops. I used the former patch file. sorry about that.

Peter

  reply	other threads:[~2019-05-30  8:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30  6:45 [PATCH 1/1] usb: chipidea: udc: workaround for endpoint conflict issue Peter Chen
2019-05-30  8:22 ` Sergei Shtylyov
2019-05-30  8:48   ` Peter Chen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-06-17  1:49 [PATCH 0/1] usb: chipidea: fixes for v5.2 Peter Chen
2019-06-17  1:49 ` [PATCH 1/1] usb: chipidea: udc: workaround for endpoint conflict issue Peter Chen
2019-05-27  7:42 Peter Chen
2019-05-27  9:02 ` Sergei Shtylyov
2019-05-27  9:44   ` Peter Chen
2019-05-27 11:49     ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR04MB53274A6AA3D9F1DD613102858B180@VI1PR04MB5327.eurprd04.prod.outlook.com \
    --to=peter.chen@nxp.com \
    --cc=jun.li@nxp.com \
    --cc=linux-imx@nxp.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.