public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Richard Curnow <Richard.Curnow@superh.com>
Cc: Greg KH <greg@kroah.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Handling of bounce buffers by rh_call_control
Date: Wed, 17 Dec 2003 08:29:36 -0800	[thread overview]
Message-ID: <3FE08470.5040801@pacbell.net> (raw)
In-Reply-To: <20031217114125.GA20057@malvern.uk.w2k.superh.com>

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().


> 	}
> 
> in the case where bounce buffers are being used to implement PCI DMA
> operations.  Without the patch, the subsequent pci_unmap_single copies
> the contents of the bounce buffer over the top of urb->transfer_buffer,
> destroying what the memcpy() put there.

A similar bug was fixed in 2.6 by a patch from Russell King.  I think
the 2.4 version has lingered since it only affect EHCI, and most folk
using EHCI won't use bounce buffers.

Could you look at that patch (bk revtool or bkweb will show it, early
September 2002) and provide a 2.4 version?


> My USB knowledge is pretty limited, so I've no idea whether this patch
> adversely affects anything else in rh_call_control.
> 
> The patch is against 2.4.23-pre-something, but I see the code's the same
> in 2.6.

What changed in 2.6 was that hcd_submit_urb() has a special case for
the root hub.  That's always PIO, so the code now bypasses all the
DMA mapping code when an URB is destined for a root hub.  The original
code accidentally assumed no bounce buffering would go on.

- Dave



  reply	other threads:[~2003-12-17 16:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-17 11:41 Handling of bounce buffers by rh_call_control Richard Curnow
2003-12-17 16:29 ` David Brownell [this message]
2003-12-17 22:47   ` bill davidsen
     [not found]   ` <200312172247.RAA08325@gatekeeper.tmr.com>
2003-12-18  2:40     ` David Brownell
2003-12-18 14:32   ` Richard Curnow
2003-12-18 14:53     ` iproute2 and 2.6.0 kernel Remus
2003-12-22 19:07       ` bill davidsen
2003-12-30 11:31       ` Remus
2003-12-18 15:36     ` Handling of bounce buffers by rh_call_control David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FE08470.5040801@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=Richard.Curnow@superh.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox