linux-kernel - Re: [PATCH RFC] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Apr 2014 13:55:38 -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>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Michal Simek <michals@...inx.com>,
	Subbaraya Sundeep Bhatta <sbhatta@...inx.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH RFC] usb: gadget: Add xilinx axi usb2 device support

On Tue, 15 Apr 2014, Felipe Balbi wrote:

> > 2. Does device need to know OUT transactions before hand so that OUT
> > requests are queued for endpoint before packets are received
> > from host?
> 
> well, no. Gadget driver shouldn't depend on that. That's UDC driver's
> responsability to manage that. I mean, if host sends OUT token and
> there's nothing in the out queue, then UDC need to start transfer as
> soon as gadget driver queues the request. If, on the other hand, gadget
> driver queues packet before host has sent OUT token then you have two
> choices:
> 
> 1) start the transfer - most HW will wait for OUT token
> 2) wait for out token

I'm not familiar with the variations in all the different UDC hardware.  
Nevertheless, I wouldn't describe the situation in those terms.

If an OUT transaction occurs and the gadget driver hasn't queued a
request, the UDC hardware could store the incoming data in an internal
buffer or it could NAK the transaction.  There aren't any other
choices.  If there isn't enough space available in an internal buffer,
the only possible action is NAK.

Regardless, gadget drivers do not need to queue requests for OUT
endpoints before the host starts sending data.  When the request does
get queued, the UDC driver will make sure that the transfer takes
place.

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/