lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D2C8DF24C22DB24BA948A8B0D097284002F277E9@SJEXCHMB05.corp.ad.broadcom.com>
Date:	Thu, 10 Sep 2015 02:24:57 +0000
From:	Roman Bacik <rbacik@...adcom.com>
To:	John Youn <John.Youn@...opsys.com>,
	Scott Branden <sbranden@...adcom.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>
Subject: RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

> -----Original Message-----
> From: Roman Bacik
> Sent: September-09-15 7:17 PM
> To: 'John Youn'; Scott Branden; Greg Kroah-Hartman; linux-
> usb@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org; bcm-kernel-feedback-list
> Subject: RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> 
> > -----Original Message-----
> > From: John Youn [mailto:John.Youn@...opsys.com]
> > Sent: September-09-15 7:11 PM
> > To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> > usb@...r.kernel.org
> > Cc: linux-kernel@...r.kernel.org; bcm-kernel-feedback-list
> > Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > isochronous mode
> >
> > On 9/9/2015 11:16 AM, Roman Bacik wrote:
> > >> -----Original Message-----
> > >> From: John Youn [mailto:John.Youn@...opsys.com]
> > >> Sent: September-03-15 11:53 PM
> > >> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> > >> usb@...r.kernel.org; Roman Bacik
> > >> Cc: linux-kernel@...r.kernel.org; bcm-kernel-feedback-list
> > >> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > >> isochronous mode
> > >>
> > >> On 8/31/2015 9:17 AM, Scott Branden wrote:
> > >>> From: Roman Bacik <rbacik@...adcom.com>
> > >>>
> > >>> USB OTG driver in isochronous mode has to set the parity of the
> > >>> receiving microframe. The parity is set to even by default. This
> > >>> causes problems for an audio gadget, if the host starts
> > >>> transmitting on odd
> > >> microframes.
> > >>>
> > >>> This fix uses Incomplete Periodic Transfer interrupt to toggle
> > >>> between even and odd parity until the Transfer Complete interrupt
> > >>> is
> > received.
> > >>>
> > >>> Signed-off-by: Roman Bacik <rbacik@...adcom.com>
> > >>> Reviewed-by: Abhinav Ratna <aratna@...adcom.com>
> > >>> Reviewed-by: Srinath Mannam <srinath.mannam@...adcom.com>
> > >>> Signed-off-by: Scott Branden <sbranden@...adcom.com>
> > >>> ---
> > >>>  drivers/usb/dwc2/core.h   |  1 +
> > >>>  drivers/usb/dwc2/gadget.c | 51
> > >> ++++++++++++++++++++++++++++++++++++++++++++++-
> > >>>  drivers/usb/dwc2/hw.h     |  1 +
> > >>>  3 files changed, 52 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > >>> index 0ed87620..a5634fd 100644
> > >>> --- a/drivers/usb/dwc2/core.h
> > >>> +++ b/drivers/usb/dwc2/core.h
> > >>> @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> > >>>  	unsigned int            periodic:1;
> > >>>  	unsigned int            isochronous:1;
> > >>>  	unsigned int            send_zlp:1;
> > >>> +	unsigned int            has_correct_parity:1;
> > >>>
> > >>>  	char                    name[10];
> > >>>  };
> > >>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > >>> index 4d47b7c..fac3e2f 100644
> > >>> --- a/drivers/usb/dwc2/gadget.c
> > >>> +++ b/drivers/usb/dwc2/gadget.c
> > >>> @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct
> > >>> dwc2_hsotg
> > >> *hsotg, unsigned int idx,
> > >>>  		ints &= ~DXEPINT_XFERCOMPL;
> > >>>
> > >>>  	if (ints & DXEPINT_XFERCOMPL) {
> > >>> +		hs_ep->has_correct_parity = 1;
> > >>>  		if (hs_ep->isochronous && hs_ep->interval == 1) {
> > >>>  			if (ctrl & DXEPCTL_EOFRNUM)
> > >>>  				ctrl |= DXEPCTL_SETEVENFR;
> > >>> @@ -2316,7 +2317,8 @@ void
> s3c_hsotg_core_init_disconnected(struct
> > >> dwc2_hsotg *hsotg,
> > >>>  		GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> > >>>  		GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> > >>>  		GINTSTS_OTGINT | GINTSTS_USBSUSP |
> > >>> -		GINTSTS_WKUPINT,
> > >>> +		GINTSTS_WKUPINT |
> > >>> +		GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
> > >>>  		hsotg->regs + GINTMSK);
> > >>>
> > >>>  	if (using_dma(hsotg))
> > >>> @@ -2581,6 +2583,52 @@ irq_retry:
> > >>>  		s3c_hsotg_dump(hsotg);
> > >>>  	}
> > >>>
> > >>> +	if (gintsts & GINTSTS_INCOMPL_SOIN) {
> > >>> +		u32 idx, epctl_reg, ctrl;
> > >>> +		struct s3c_hsotg_ep *hs_ep;
> > >>> +
> > >>> +		dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
> > >> __func__);
> > >>> +		for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> > >>
> > >> Valid endpoints are only up to hsotg->num_of_eps so this might
> > >> crash on certain configurations.
> > >>
> > >> Also, have you tried to find the endpoint which caused the
> > >> incomplete interrupt by reading the control registers as described in the
> databook?
> > >>
> > >
> > > We are using procedure based on description from this source:
> > >
> > > Synopsys, Inc. SolvNet 527
> > > DesignWare.com
> > > 3.00a
> > > April 2012
> > > USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in
> > > DWC_otg Slave Mode
> > >
> > > Synopsys databook is not in a public domain to quote the exact
> > > paragraph
> > here. You can find it in Chapter E, pp 526-527. There is no register
> > in this databook, which would provide information about the source
> > endpoint of the incomplete interrupt, as you have described.
> > >
> > > Please, provide an exact reference and possibly enough information
> > > that
> > we can turn it into a working code.
> > >
> >
> > You can check the source of the interrupt by reading the DSTS and ep
> > control registers as described in the databook page 526, last bullet,
> > and 527 first bullet.
> >
> > John
> >
> 
> Yes, that is exactly what we are doing what is described in the last bullet of
> 526 and the first two bullets of page 527. So what is the problem?

In order to avoid any further confusion, here is the quote of the three bullets:

"- GINTSTS.incompISOIN is a global interrupt. Therefore, when more than one isochronous
endpoints is active, then the application must determine which isochronous IN endpoints
have incomplete data.
- To accomplish this, read DSTS and DIEPCTLn for all isochronous endpoints. If
DSTS.SOFFN[0] =DIEPCTLn.EO_FrNum (Bit 16), then that endpoint has an incomplete
transfer.
- When there is an incomplete transfer for an endpoint, then toggle the Even/Odd bit."

We believe that this is exactly what we coded in this patch.

Regards,

Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ