linux-kernel - Re: [RFC 0/2] staging: ion: of_ion_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAtXAHf7UKRyCpK9VXjrkZ02fk2e9P_up2NP39Sf_Auozhp5XA@mail.gmail.com>
Date:	Tue, 22 Mar 2016 16:38:47 -0700
From:	Moritz Fischer <moritz.fischer@...us.com>
To:	Laura Abbott <labbott@...hat.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Greg KH <gregkh@...uxfoundation.org>, arve@...roid.com,
	riandrews@...roid.com, Sumit Semwal <sumit.semwal@...aro.org>,
	dan.carpenter@...cle.com, sriram@...irs.net.in,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	devel@...verdev.osuosl.org
Subject: Re: [RFC 0/2] staging: ion: of_ion_device_get

On Tue, Mar 22, 2016 at 4:20 PM, Laura Abbott <labbott@...hat.com> wrote:
> On 03/22/2016 04:08 PM, Moritz Fischer wrote:
>>
>> Hi Laura,
>>
>> On Tue, Mar 22, 2016 at 3:51 PM, Laura Abbott <labbott@...hat.com> wrote:
>>
>>> In the past what drivers have done is a foo_ion_client_create which has
>>> the
>>> reference
>>> to the ion_device created from ion_device_create. Drivers then call the
>>> foo_ion_client_create function.
>>
>>
>> Oh, so you mean you add a function to create a client to the platform
>> device implementing
>> the heap and the export this function?
>>
>> heap implements:
>>
>> foo_create_client();
>>
>> driver calls:
>>
>> foo_create_client() ?
>>
>
> Yes, exactly
>
>>> Can you elaborate more on your sharing and allocation flow? This might
>>> suggest
>>> another idea.
>>
>>
>> Well I'll have a bunch of DMA streams to / from an FPGA that contains
>> DMA engines & accelerators. To that end
>> my userland software would allocate say 64 buffers, hand them over to
>> driver A to queue/deque them.
>>
>> In future I might want to share these buffers between streams and with
>> other peripherals on the same bus,
>> which is why I looked at ION.
>>
>
> If allocation is coming from userspace and drivers are only importing
> you should be using the dma_buf APIs instead of Ion APIs directly.
> Ion is a dma_buf exporter and dma_buf APIs are the preferred API.
>
>> Thanks,
>>
>> Moritz
>>
>
> Thanks,
> Laura