[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ca11b6e-3afc-d55f-6df7-88a8a4a88873@metafoo.de>
Date: Fri, 3 Aug 2018 09:51:43 +0200
From: Lars-Peter Clausen <lars@...afoo.de>
To: Huang Shijie <sjhuang@...vatar.ai>, vkoul@...nel.org
Cc: 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, peter.ujfalusi@...com, keescook@...omium.org,
horms+renesas@...ge.net.au, geert+renesas@...der.be,
shawnguo@...nel.org, baoyou.xie@...aro.org,
michal.simek@...inx.com, baohua@...nel.org,
ludovic.desroches@...rochip.com, linus.walleij@...aro.org,
david.brown@...aro.org
Subject: Re: [PATCH 00/46] Use dmaenginem_async_device_register to simplify
code
On 08/03/2018 09:19 AM, Huang Shijie wrote:
> All the patches are using dmaenginem_async_device_register to simplify code
> except the last one:
> dmaengine: add COMPILE_TEST for the drivers
>
> I use the last one to do the compiler test.
> There are still 20 drivers which do not use the dmaenginem_async_device_register.
> Let me take a rest, if this patch set is accepted, I will do the rest.
Lots of race conditions in this series. The DMA device needs to be removed
before any of the resources it uses are disabled/released.
As a rule of thumb you can only convert something to a managed
allocation/reregistration if it is the last action in remove.
Powered by blists - more mailing lists