>> >> True. It is a requirenment that a HCD work with >> any kmalloced buffer. > > Not what I said at all ... there's a whole bunch > of generic "is this DMA-safe" constraints which > apply to USB just like the rest of Linux, and > none of them include alignment. > > Passing a pointer to a few bytes inside of a > kmalloc'd block has always been legit, even if > that pointer isn't aligned to N!=1 bytes. > > The problem here is that the hardware can't handle that. The first part PIO + rest DMA trick that Russell King suggested in the discussion about this a few weeks back won't work either as the hardware only supports PIO or DMA not both. Now of course the bounce buffer could be done in the HCD rather than the usb core but: 1) That would mean the mapping being done twice (by the usb core and then again after the copy by the HCD) 2) It would only fix it for this HCD - others have shown interest in these threads. I really don't want to go the only other route I see and use PIO if the buffer is not aligned because that will require servicing an interrupt for every 64 bytes transferred. This patch hides the alignment issues from the drivers (at least for the case when the core does the mapping) If we do publish the information to drivers (which my patch currently does not) it would only really be for optimisation purposes (such as network drivers wishing to use memmove) not as a requirement to work. Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
