linux-kernel - Re: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support

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: <Pine.LNX.4.44L0.1404211228190.1201-100000@iolanthe.rowland.org>
Date:	Mon, 21 Apr 2014 12:39:15 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Felipe Balbi <balbi@...com>
cc:	sundeep subbaraya <sundeep.lkml@...il.com>,
	Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@...inx.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Michal Simek <michals@...inx.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Subbaraya Sundeep Bhatta <sbhatta@...inx.com>
Subject: Re: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support

On Mon, 21 Apr 2014, Felipe Balbi wrote:

> Hi,
> 
> On Fri, Apr 18, 2014 at 07:34:08PM +0530, sundeep subbaraya wrote:
> 
> <snip>
> 
> > >> in ep_queue driver starts dma transfer from/to IP buffer to/from req->buf.
> > >> If transfer is completed then request is not added to ep request queue
> > >> and returns from ep_queue.
> > >> If transfer is not completed (actual < length) then request is added
> > >> to queue and returns from ep_queue.
> > >
> > > This is wrong. Why wouldn't you give gadget driver the chance to decide
> > > if it needs to queue the request again or not ?
> > 
> > When does gadget driver decides to queue the same request again?
> > if -EBUSY is returned from ep_queue or req.status != 0 in completion
> > routine?
> 
> whenever it so decides. Different gadget drivers might have different
> requirements. The code is open and sits under drivers/usb/gadget/ why
> don't you have a read ?

I get the impression that the two of you are arguing past each other.
It appears that Sundeep is talking about transferring data from the 
gadget driver's buffer to an internal buffer in the UDC hardware, but 
Felipe is talking about transferring data from the UDC to the host.

As I understand it, Sundeep said that when the gadget driver queues a
data-IN request, the UDC driver copies as much of the data buffer as
possible into a hardware FIFO.  If it succeeds in copying all the data
into the FIFO then the request's completion routine gets called
immediately, even though the data doesn't get sent from the FIFO to the
host until the host asks for it.

If only part of the data can be copied into the FIFO then the request
is added to the ep's request queue before the usb_ep_queue() call
returns.  When space becomes available in the FIFO, the data will be
copied and eventually sent to the host.  When all the data has been
copied to the FIFO, the request's completion routine will be called.

Thus there never is any need for the gadget driver to queue the request
again.  An incomplete transfer means the FIFO didn't have enough room
when the request was submitted; it doesn't mean that the data didn't
eventually get sent to the host.

HTH,

Alan Stern

--
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/