On Thu, 4 Mar 2010, Albert Herranz wrote:
> >This is a little fragile. I think it would be better to move the test
> >for HCD_NO_COHERENT_MEM into the submission path, by combining it with
> >the URB_NO_SETUP_DMA_MAP test. Evidently this case has to be covered
> >either during submission or during giveback, and doing it during
> >submission would be cleaner.
> >
> >The same goes for URB_NO_TRANSFER_DMA_SETUP, of course.
> >
>
> Why exactly is this a little fragile?
Because it relies on people in the future understanding the reason for
this strange manipulation and not messing it up. Yes, it will work,
but I'd prefer to do it differently.
> Doing the reset of {transfer,setup}_dma on unmap time has benefits from doing it on map time.
Maybe, but that's not what I was proposing. I didn't say transfer_dma
should be reset at map time; I said that the submission test should be
changed.
> In this case we will have a different transfer_dma value visible for the USB driver depending on if we are doing the first transfer of the URB after its allocation or a subsequent transfer.
> Also it is hard (and may fail to do it right) for the USB stack to determine for the subsequent transfers if the transfer_dma value is then a real mapping or not.
The test shouldn't be too hard: If URB_NO_TRANSFER_DMA_MAP is set and
the hcd uses DMA (or the DMA address isn't ~0) and HCD_NO_COHERENT_MEM
isn't set, then the mapping is already okay.
You're concerned that transfer_dma might contain a valid DMA address
for an existing mapping. How could it? usb_buffer_alloc() won't
return a valid address if HCD_NO_COHERENT_MEM is set. And even if it
did, you would overwrite that valid address at unmap time anyway.
Alan Stern
--
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
