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]
Message-ID: <Pine.LNX.4.44L0.1404151345580.1310-100000@iolanthe.rowland.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ