linux-kernel - Re: [PATCH v2 32/32] dmaengine: at_hdmac: Convert driver to use virt-dma

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: <61e54c48-6347-f0ab-e843-ae48d5374903@microchip.com>
Date:   Fri, 28 Oct 2022 14:55:37 +0200
From:   Nicolas Ferre <nicolas.ferre@...rochip.com>
To:     Tudor Ambarus <tudor.ambarus@...rochip.com>, <vkoul@...nel.org>,
        <peda@...ntia.se>, <du@...ntia.se>
CC:     <maciej.sosnowski@...el.com>, <mripard@...nel.org>,
        <torfl6749@...il.com>, <linux-kernel@...r.kernel.org>,
        <dmaengine@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 32/32] dmaengine: at_hdmac: Convert driver to use
 virt-dma

On 25/10/2022 at 11:03, Tudor Ambarus wrote:
> Convert the driver to use the core virt-dma. The driver will be easier to
> maintain as it uses the list handling and the tasklet from virt-dma.
> 
> With the conversion replace the election of a new transfer in the tasklet
> with the election of the new transfer in the interrupt handler. With this
> we have a shorter idle window as we remove the scheduling latency of the
> tasklet. I chose to do this while doing the conversion to virt-dma,
> because if I made a prerequisite patch with the new transfer election in
> the irq handler, I would have to duplicate some virt-dma code in the
> at_hdmac driver that would end up being removed at the virt-dma conversion
> anyway. So do this in a single step.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus@...rochip.com>

Even if it's difficult to review, I support the transition:
Acked-by: Nicolas Ferre <nicolas.ferre@...rochip.com>

Thanks Tudor, regards,
   Nicolas

[..]

-- 
Nicolas Ferre