Messages in this thread | | | From | (bill davidsen) | Subject | Re: Handling of bounce buffers by rh_call_control | Date | 17 Dec 2003 22:47:14 GMT |
| |
In article <3FE08470.5040801@pacbell.net>, David Brownell <david-b@pacbell.net> wrote: | Hi, | | Richard Curnow wrote: | > The following patch | > | > ===== drivers/usb/hcd.c 1.10 vs edited ===== | > --- 1.10/drivers/usb/hcd.c Mon Mar 31 14:22:42 2003 | > +++ edited/drivers/usb/hcd.c Wed Dec 17 11:26:53 2003 | > @@ -323,7 +323,7 @@ | > struct usb_ctrlrequest *cmd = (struct usb_ctrlrequest *) urb->setup_packet; | > u16 typeReq, wValue, wIndex, wLength; | > const u8 *bufp = 0; | > - u8 *ubuf = urb->transfer_buffer; | > + u8 *ubuf = (u8 *) urb->transfer_dma; | > int len = 0; | > | > typeReq = (cmd->bRequestType << 8) | cmd->bRequest; | > | > seems to be needed to make the following code later in the function work | > | > if (bufp) { | > if (urb->transfer_buffer_length < len) | > len = urb->transfer_buffer_length; | > urb->actual_length = len; | > // always USB_DIR_IN, toward host | > memcpy (ubuf, bufp, len); | | Which is why that particular patch is wrong: "ubuf" is a dma address, | not expected to work for memcpy().
But the existing code most certainly does use it with memcpy. I'm looking at test11-mm1 source, but the last memcpy line he noted is most definitely in the existing source.
Or did I misunderstand what you meant by "not expected to work for memcpy()?" It may be that the code around the memcpy is wrong and should be using ubuf, and that no diddling with fix it, but someone clearly DID expect it to work ;-) -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |