[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180807071604.GA5576@hsj-Precision-5520>
Date: Tue, 7 Aug 2018 15:16:05 +0800
From: Huang Shijie <sjhuang@...vatar.ai>
To: Peter Ujfalusi <peter.ujfalusi@...com>
Cc: Alexandre Bailon <abailon@...libre.com>,
Tony Lindgren <tony@...mide.com>, vkoul@...nel.org,
dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
dave.jiang@...el.com, radhey.shyam.pandey@...inx.com,
appana.durga.rao@...inx.com, jmkrzyszt@...il.com,
gomonovych@...il.com, keescook@...omium.org,
horms+renesas@...ge.net.au, geert+renesas@...der.be,
shawnguo@...nel.org, michal.simek@...inx.com, baohua@...nel.org,
ludovic.desroches@...rochip.com, linus.walleij@...aro.org,
david.brown@...aro.org
Subject: Re: [PATCH 09/46] dmaengine: cppi41: use
dmaenginem_async_device_register to simplify the code
On Tue, Aug 07, 2018 at 10:01:47AM +0300, Peter Ujfalusi wrote:
> Hi,
>
> On 2018-08-06 06:28, Huang Shijie wrote:
> It might be only me, but I like to keep the resource teardown in a
> reverse order of their creation. If everything is devm then it is granted.
Yes.
If everything is devm then it is granted..
>
> In case of cppi4 it looks safe after reading in to the DMAengine core,
> module core and platform core code.
>
> But does the removed three lines worth over the clarity of how the
> module removal is proceeding?
Please keep the driver as it is if you like the traditional way. :)
The DMA driver's maintainer has the right to decide whether
to use the dmaenginem_async_device_register or not.
Thanks
Huang Shijie
Powered by blists - more mailing lists