From: Vignesh R <vigneshr@ti.com>
To: David Laight <David.Laight@ACULAB.COM>,
"'Wolfram Sang'" <wsa@the-dreams.de>,
Florian Fainelli <f.fainelli@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Felipe Balbi" <balbi@kernel.org>,
"Peter Chen" <peter.chen@nxp.com>,
"Roger Quadros" <rogerq@ti.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Mathias Nyman" <mathias.nyman@linux.intel.com>,
"Javier Martinez Canillas" <javier@osg.samsung.com>,
"Baoyou Xie" <baoyou.xie@linaro.org>,
"Sekhar Nori" <nsekhar@ti.com>,
"William wu" <wulf@rock-chips.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Chris Bainbridge" <chris.bainbridge@gmail.com>,
"Wolfram Sang" <wsa-dev@sang-engineering.com>,
"Krzysztof Opasiak" <k.opasiak@samsung.com>,
"Felix Hädicke" <felixhaedicke@web.de>,
"Colin Ian King" <colin.king@canonical.com>,
"open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
"clemens@ladisch.de" <clemens@ladisch.de>,
"maksim.salau@gmail.com" <maksim.salau@gmail.com>
Subject: Re: RE: [PATCH v3 0/2] usb: Check for DMA capable buffer sanity
Date: Wed, 31 May 2017 17:25:48 +0530 [thread overview]
Message-ID: <3619ab73-b9f0-89b8-a8e8-b6600a0bf73d@ti.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD0005BB4@AcuExch.aculab.com>
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
next prev parent reply other threads:[~2017-05-31 11:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-26 0:56 Florian Fainelli
2017-04-26 0:56 ` [PATCH v3 1/2] usb: core: Check URB setup_packet and transfer_buffer sanity Florian Fainelli
2017-04-26 0:56 ` [PATCH v3 2/2] usb: udc: core: Error if req->buf is either from vmalloc or stack Florian Fainelli
2017-05-05 21:08 ` [PATCH v3 0/2] usb: Check for DMA capable buffer sanity Florian Fainelli
2017-05-28 16:03 ` Wolfram Sang
2017-05-31 11:04 ` David Laight
2017-05-31 11:55 ` Vignesh R [this message]
2017-05-31 15:50 ` Wolfram Sang
2017-05-31 19:23 ` Wolfram Sang
2017-05-31 11:56 ` Vignesh R
2017-05-31 15:12 ` Wolfram Sang
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=3619ab73-b9f0-89b8-a8e8-b6600a0bf73d@ti.com \
--to=vigneshr@ti.com \
--cc=David.Laight@ACULAB.COM \
--cc=arnd@arndb.de \
--cc=balbi@kernel.org \
--cc=baoyou.xie@linaro.org \
--cc=chris.bainbridge@gmail.com \
--cc=clemens@ladisch.de \
--cc=colin.king@canonical.com \
--cc=f.fainelli@gmail.com \
--cc=felixhaedicke@web.de \
--cc=gregkh@linuxfoundation.org \
--cc=javier@osg.samsung.com \
--cc=k.opasiak@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=maksim.salau@gmail.com \
--cc=mathias.nyman@linux.intel.com \
--cc=nsekhar@ti.com \
--cc=peter.chen@nxp.com \
--cc=rogerq@ti.com \
--cc=stern@rowland.harvard.edu \
--cc=wsa-dev@sang-engineering.com \
--cc=wsa@the-dreams.de \
--cc=wulf@rock-chips.com \
/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
Powered by JetHome