linux-kernel - Re: [PATCH 0/3] add ION driver for STIh4xx SoC

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAO_48GH548VTvSUSc5qmQy+sJBxCUsYss_y2zZAQj2zMFcKyCA@mail.gmail.com>
Date:   Wed, 26 Oct 2016 20:14:28 +0530
From:   Sumit Semwal <sumit.semwal@...aro.org>
To:     Benjamin Gaignard <benjamin.gaignard@...aro.org>
Cc:     Laura Abbott <labbott@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        yudongbin@...ilicon.com, Chen Feng <puck.chen@...ilicon.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
        kernel@...inux.com
Subject: Re: [PATCH 0/3] add ION driver for STIh4xx SoC

On 26 October 2016 at 20:11, Benjamin Gaignard
<benjamin.gaignard@...aro.org> wrote:
> 2016-10-26 15:51 GMT+02:00 Sumit Semwal <sumit.semwal@...aro.org>:
>> Hello Benjamin,
>>
>> On 26 October 2016 at 19:02, Benjamin Gaignard
>> <benjamin.gaignard@...aro.org> wrote:
>>> It is more or less a copy of Hisilicon driver but with a heap definition
>>> fitting with STIH4xx SoC needs.
>>> I have just chnage the some function prefix from "hi6220" to "sti".
>>>
>> Thanks for your patches!
>>
>> I was just wondering if you couldn't convert the HiSilicon driver into
>> something like a 'simple-ion' driver, and have just the DT definitions
>> as specifics? This would save a lot of code duplication, and keep it
>> as a simple interface for common heaps like cma.
>
> Create a simple-ion driver is a good idea but it means that heaps
> (configuration, name, etc..)
> will have to be describe into devicetree. I'm not sure if that will is
> acceptable.
>
>>
>> If there are any ST-specific requirements that are incompatible with
>> the existing driver, it should be clearly documented out here I think.
>
> heaps names and Ids aren't the same so I can't reuse hisilicon driver.
>
But I'd suspect both these are solvable with using something like
'generic,cma' instead of 'hisi,cma' or 'st,cma'?
>
Best,
Sumit.