On Wednesday 31 May 2017 04:34 PM, David Laight wrote:
> From: Wolfram Sang
>> Sent: 28 May 2017 17:04
>>
>> On Fri, May 05, 2017 at 02:08:31PM -0700, Florian Fainelli wrote:
>>> On 04/25/2017 05:56 PM, Florian Fainelli wrote:
>>>> Changes in v3:
>>>>
>>>> - added check in usb_gadget_map_request_by_dev (Felipe), new patch
>>>> - improved commit message description (Clemens)
>>>> - added additiona checks for urb->setup_packet (Alan)
>>>>
>>>> Changes in v2:
>>>>
>>>> - moved the check from usb_start_wait_urb() to usb_hcd_map_urb_for_dma()
>>>
>>> Is this version looking good now? Thanks!
>>
>> So, it seems I am in a similar situation with the I2C subsystem right
>> now. I need to check the message buffers if they are DMA capable.
>>
>> Because you have basically the same checks in 3 different places, and I
>> need something similar for I2C, I wondered about a generic place to put
>> these checks. Especially since we want future improvements to these
>> checks applied everywhere immediately. Here is a small diff on what I
>> have now:
> ...
>> + } else if (!is_dma_capable_addr(urb->transfer_buffer)) {
>
> For a generic function I'd pass the length as well.
> It might be that buffers that don't cross page boundaries might be
> deemed 'dma-able'.
>
> Possibly more useful would be a variant of (IIRC) dma_map_for_device()
> that will allocate a suitable bounce buffer for non-dma memory.
> I think it can already do so for memory that is outside the address
> range that the device can address (eg for a 32bit PCIe master in 64bit
> system).
>
Such generic DMA API would be greatly useful!
I tried adding bounce buffers support to handle vmalloc'd buffers in
MTD/SPI subsystem. But, there was a need felt for generic DMA API that
can allocate bounce buffer for non-dma'able buffers that all drivers can
make use of[1][2]
[1] https://lkml.org/lkml/2017/3/1/488
[2] https://lkml.org/lkml/2017/4/25/278
--
Regards
Vignesh
--
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
