On Wednesday 16 May 2007 18:00, David Brownell wrote: > On Wednesday 16 May 2007, Alan Stern wrote: > > On Wed, 16 May 2007, David Brownell wrote: > > > > I have never, ever, seen USB stack deplete the atomic pool completely > > > > either, if this is what you are talking about. So, you're quite right > > > > about that. > > > > > > I was referring to the dma_pool allocations ... those don't need > > > to be atomic. OHCI or EHCI tend to allocate a page or so for each > > > type of descriptor seen by the hardware, and usually won't need > > > more than that. UHCI uses more pages; TD-per-packet requirements > > > from the hardware, ISTR (instead of multiple-pages-per-TD). > > > > If dma_pool allocation isn't atomic, does that mean it could block for > > I/O? If yes, then it doesn't belong on the usb-storage I/O path. > > dma_pool_alloc() takes gfp_flags, and (looking at the code) > tests only for __GFP_WAIT. So if you don't pass that flag, > it won't wait...
It is very clear to me that non-blocking memory allocation at the point of starting an USB transfer will require extra error handling in the USB device driver code! My "usbd_transfer_start()" returns "void". Your "usb_submit_urb()" returns "int". Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. --HPS ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
