linux-kernel - Re: [Patch v2 2/4] dmaengine: tegra: Add Tegra GPC DMA driver

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: <a1b9f491-39c4-253e-ba89-f29ab8184cfe@nvidia.com>
Date:   Fri, 7 Aug 2020 17:03:00 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Rajesh Gumasta <rgumasta@...dia.com>, <ldewangan@...dia.com>,
        <vkoul@...nel.org>, <dan.j.williams@...el.com>,
        <thierry.reding@...il.com>, <p.zabel@...gutronix.de>,
        <dmaengine@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
CC:     <kyarlagadda@...dia.com>, Pavan Kunapuli <pkunapuli@...dia.com>
Subject: Re: [Patch v2 2/4] dmaengine: tegra: Add Tegra GPC DMA driver


On 06/08/2020 08:30, Rajesh Gumasta wrote:
> Adding GPC DMA controller driver for Tegra186 and Tegra194. The driver
> supports dma transfers between memory to memory, IO peripheral to memory
> and memory to IO peripheral.
> 
> Signed-off-by: Pavan Kunapuli <pkunapuli@...dia.com>
> Signed-off-by: Rajesh Gumasta <rgumasta@...dia.com>
> ---
>  drivers/dma/Kconfig         |   12 +
>  drivers/dma/Makefile        |    1 +
>  drivers/dma/tegra-gpc-dma.c | 1472 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1485 insertions(+)
>  create mode 100644 drivers/dma/tegra-gpc-dma.c

...

> +static void tdc_start_head_req(struct tegra_dma_channel *tdc)
> +{
> +	struct tegra_dma_sg_req *sg_req;
> +	struct virt_dma_desc *vdesc;
> +
> +	if (list_empty(&tdc->pending_sg_req))
> +		return;
> +
> +	if (tdc->is_pending)
> +		return;
> +
> +	vdesc = vchan_next_desc(&tdc->vc);
> +	if (!vdesc)
> +		return;
> +	list_del(&vdesc->node);
> +	tdc->dma_desc = vd_to_tegra_dma_desc(vdesc);
> +	tdc->is_pending = true;
> +	tdc->dma_desc->tdc = tdc;
> +	sg_req = list_first_entry(&tdc->pending_sg_req,
> +				  typeof(*sg_req), node);
> +	tegra_dma_start(tdc, sg_req);
> +	sg_req->configured = true;
> +	tdc->busy = true;
> +}


I really don't understand this. First we get a descriptor for the
vchan_next_desc and then we get a sg_req from another list. I really
don't see why we need to have two lists here. Seems overly complicated.

Jon

-- 
nvpublic