* Alan Stern <[EMAIL PROTECTED]> [2005-11-27 09:14]:
> There's no mechanism to report back that an URB is too large,
> and no driver tries to break URBs up into smaller pieces.

Most drivers won't submit URBs larger than 8KB, so usb-storage
was my primary focus.  With a better understanding of how scatter
gather lists map to URBs, however, I don't think drivers using sg
should worry about URB sizes.

> There are several other related properties of block request
> queues; you would interested in the one that controls the
> maximum size of a scatter_gather hardware segment.
> Unfortunately usb-storage doesn't provide any way to set that
> property.

Yes, I am interested in that.  Thanks for letting me know.

> > usb-storage doesn't check for dma mapping failures either.
> 
> Nonsense.  What about this code from usb_sg_init():

I apologize for incorrectly determining usb-storage was at fault.
The problem lies with a broken API, where dma_map_sg() can't
report errors.  usb_buffer_map_sg() notes this problem:

        // FIXME generic api broken like pci, can't report errors
        return dma_map_sg (controller, sg, nents,
                        usb_pipein (pipe) ? DMA_FROM_DEVICE : DMA_TO_DEVICE);

This is very problematic for my memory constrained HC, where
-ENOMEM is common.  Pretending to be a PIO controller and
handling DMA in-house is looking like a better solution.

> > This wouldn't require modification to the USB core if I
> > temporarily replace the USB completion handler, but this seems
> > like a hack.  Ideally, struct usb_operations would have a
> > 'complete_urb' or 'giveback_urb' function I would use to unmap
> > dma memory.
> 
> Why do you need to replace anything?  Can't you do the unmapping within 
> the HCD's URB-completion routine?

The problem is I'm not writing a HCD, but a bus glue for OHCI,
and the OHCI core doesn't let the bus glue know about URB
completions.  You're right, though, I should handle this with the
HCD's completion routine.  I just need a hook to use.

Thanks,
Chris Humbert


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to