On Thu, Jul 6, 2017 at 11:27 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 4:06 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
>>> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>>>
> On the o
On Thu, Jul 6, 2017 at 4:06 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>>
On the other hand, if it's strictly about base/dma-mapping, we might
>
On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>
>>> On the other hand, if it's strictly about base/dma-mapping, we might
>>> not need it indeed. The driver could call iommu-dma hel
On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>> On the other hand, if it's strictly about base/dma-mapping, we might
>> not need it indeed. The driver could call iommu-dma helpers directly,
>> without the need to provide its own DMA ops
On Thu, Jul 6, 2017 at 3:31 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>>>
>>> Sorry, I intended to mean:
>>>
>>> IMHO re-implementing the code that's
On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
> On Thu, Jul 6
On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>
>>>
>>> I'd say th
On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>>
>> I'd say that this is something that has been consistently tried to be
>>
On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>>
On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
>>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>
>>> In general I think moving dma
>>> ops and iommu implementat
On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>> In general I think moving dma
>> ops and iommu implementations into modules is a bad idea
>
> Could you elaborate on th
On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig wrote:
> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>> Generally the user is a work in progress that should be posted in a
>> very near future. You can find a reference to our downstream tree at
>> chromium.org in the cover letter
On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
> Generally the user is a work in progress that should be posted in a
> very near future. You can find a reference to our downstream tree at
> chromium.org in the cover letter. Obviously I don't mind including
> patches from this series i
Hi Christoph,
Thanks for comments!
On Thu, Jul 6, 2017 at 12:17 AM, Christoph Hellwig wrote:
> Please use EXPORT_SYMBOL_GPL for any of these exports, as they are
> internal linux implementration details by any definition of it.
Right. I typically lean towards EXPORT_SYMBOL_GPL(), but was misled
Please use EXPORT_SYMBOL_GPL for any of these exports, as they are
internal linux implementration details by any definition of it.
On Wed, Jul 05, 2017 at 04:12:11PM +0900, Tomasz Figa wrote:
> There is nothing wrong in having a loadable module implementing DMA API,
> for example to be used for su
There is nothing wrong in having a loadable module implementing DMA API,
for example to be used for sub-devices registered by the module.
However, most of the functions from dma-mapping do not have their
symbols exported, making it impossible to use them from loadable modules.
Export the remaining
16 matches
Mail list logo
