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]
Date:   Wed, 26 Oct 2016 17:05:33 +0200
From:   Benjamin Gaignard <benjamin.gaignard@...aro.org>
To:     Sumit Semwal <sumit.semwal@...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

2016-10-26 16:44 GMT+02:00 Sumit Semwal <sumit.semwal@...aro.org>:
> 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'?

yes, but it requires to describe the heaps in devicetree.
Hisilicon driver was doing like that until last month but Laura
convert it to common platform:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/android/ion/hisilicon?id=b6e336dbeda85585c3ba6d935753d8240e18baf1

I bet she got good reasons do to that so I have implemented sti ION
driver in this mindset.

>>
> Best,
> Sumit.



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ