From: Albert Herranz <albert_herranz@yahoo.es>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag
Date: Mon, 01 Mar 2010 19:38:19 +0100 [thread overview]
Message-ID: <4B8C099B.30504@yahoo.es> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1003010943480.1645-100000@iolanthe.rowland.org>
Alan Stern wrote:
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -1260,6 +1260,34 @@ static void hcd_free_coherent(struct usb_bus *bus, dma_addr_t *dma_handle,
>> *dma_handle = 0;
>> }
>>
>> +static int urb_needs_setup_dma_map(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->setup_dma == ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_setup_dma_unmap(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->setup_dma && urb->setup_dma != ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_transfer_dma_map(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->transfer_dma == ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_transfer_dma_unmap(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->transfer_dma && urb->transfer_dma != ~(dma_addr_t)0);
>> +}
>> +
>
> These functions would be a lot easier to understand if they were
> expanded into multiple test and return statements, rather than
> squeezing all the Boolean manipulations into single expressions. (Not
> to mention the fact that other developement is going to make them even
> more complicated than they are now...)
>
Yes, agreed. I'll enhance that, thanks.
> Also, I can't help thinking that the corresponding *_map() and
> *_unmap() routines are so similar, it ought to be possible to combine
> them. The only difference is a check for a NULL DMA address, and it's
> not clear to me why it is present. It's also not clear why the test
> for a DMA address of all ones is present. Maybe they both can be
> removed.
>
I think too that I can simplify that logic.
I added those checks in a defensive way seeking robustness while I familiarize with the USB stack innards. So far, those cases are just avoiding mappings when urb_needs_transfer_dma_map()/urb_needs_transfer_dma_unmap() are called with urb->transfer_buffer == 0 and urb->transfer_dma == 0.
I guess that those cases are related to scatterlist-based urb requests.
What should be the correct way to check if a urb has already been scatter/gather-mapped?
The final logic would be something like:
- map if URB_NO_TRANSFER_DMA_MAP is cleared
- otherwise (URB_TRANSFER_NO_DMA_MAP is set so) map if HCD_NO_COHERENT_MEM is set _and_ it's not a scatter/gather request (as that should have been mapped already by usb_buffer_map_sg())
Am I on the right path?
> Alan Stern
>
Thanks,
Albert
WARNING: multiple messages have this Message-ID (diff)
From: albert_herranz@yahoo.es (Albert Herranz)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag
Date: Mon, 01 Mar 2010 19:38:19 +0100 [thread overview]
Message-ID: <4B8C099B.30504@yahoo.es> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1003010943480.1645-100000@iolanthe.rowland.org>
Alan Stern wrote:
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -1260,6 +1260,34 @@ static void hcd_free_coherent(struct usb_bus *bus, dma_addr_t *dma_handle,
>> *dma_handle = 0;
>> }
>>
>> +static int urb_needs_setup_dma_map(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->setup_dma == ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_setup_dma_unmap(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->setup_dma && urb->setup_dma != ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_transfer_dma_map(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->transfer_dma == ~(dma_addr_t)0);
>> +}
>> +
>> +static int urb_needs_transfer_dma_unmap(struct usb_hcd *hcd, struct urb *urb)
>> +{
>> + return !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
>> + ((hcd->driver->flags & HCD_NO_COHERENT_MEM) &&
>> + urb->transfer_dma && urb->transfer_dma != ~(dma_addr_t)0);
>> +}
>> +
>
> These functions would be a lot easier to understand if they were
> expanded into multiple test and return statements, rather than
> squeezing all the Boolean manipulations into single expressions. (Not
> to mention the fact that other developement is going to make them even
> more complicated than they are now...)
>
Yes, agreed. I'll enhance that, thanks.
> Also, I can't help thinking that the corresponding *_map() and
> *_unmap() routines are so similar, it ought to be possible to combine
> them. The only difference is a check for a NULL DMA address, and it's
> not clear to me why it is present. It's also not clear why the test
> for a DMA address of all ones is present. Maybe they both can be
> removed.
>
I think too that I can simplify that logic.
I added those checks in a defensive way seeking robustness while I familiarize with the USB stack innards. So far, those cases are just avoiding mappings when urb_needs_transfer_dma_map()/urb_needs_transfer_dma_unmap() are called with urb->transfer_buffer == 0 and urb->transfer_dma == 0.
I guess that those cases are related to scatterlist-based urb requests.
What should be the correct way to check if a urb has already been scatter/gather-mapped?
The final logic would be something like:
- map if URB_NO_TRANSFER_DMA_MAP is cleared
- otherwise (URB_TRANSFER_NO_DMA_MAP is set so) map if HCD_NO_COHERENT_MEM is set _and_ it's not a scatter/gather request (as that should have been mapped already by usb_buffer_map_sg())
Am I on the right path?
> Alan Stern
>
Thanks,
Albert
next prev parent reply other threads:[~2010-03-01 18:38 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-28 14:07 [RFC PATCH v2 0/9] wii: add usb 2.0 support Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 1/9] powerpc: add per-device dma coherent support Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 2/9] wii: have generic dma coherent Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 3/9] dma-coherent: fix bitmap access races Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 4/9] add generic dmabounce support Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:20 ` Russell King - ARM Linux
2010-02-28 14:20 ` Russell King - ARM Linux
2010-02-28 16:37 ` Albert Herranz
2010-02-28 16:37 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 5/9] arm: use " Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 6/9] powerpc: add optional per-device " Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:08 ` [RFC PATCH v2 7/9] wii: add mem2 dma mapping ops Albert Herranz
2010-02-28 14:08 ` Albert Herranz
2010-02-28 14:08 ` [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag Albert Herranz
2010-02-28 14:08 ` Albert Herranz
2010-03-01 14:49 ` Alan Stern
2010-03-01 14:49 ` Alan Stern
2010-03-01 18:38 ` Albert Herranz [this message]
2010-03-01 18:38 ` Albert Herranz
2010-03-01 19:23 ` Alan Stern
2010-03-01 19:23 ` Alan Stern
2010-03-01 20:11 ` Albert Herranz
2010-03-01 20:11 ` Albert Herranz
2010-03-01 20:45 ` Alan Stern
2010-03-01 20:45 ` Alan Stern
2010-03-01 22:55 ` Albert Herranz
2010-03-01 22:55 ` Albert Herranz
2010-03-02 15:50 ` Alan Stern
2010-03-02 15:50 ` Alan Stern
2010-03-02 17:02 ` Albert Herranz
2010-03-02 17:02 ` Albert Herranz
2010-03-02 17:43 ` Alan Stern
2010-03-02 17:43 ` Alan Stern
2010-02-28 14:08 ` [RFC PATCH v2 9/9] wii: hollywood ehci controller support Albert Herranz
2010-02-28 14:08 ` Albert Herranz
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=4B8C099B.30504@yahoo.es \
--to=albert_herranz@yahoo.es \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.