linux-kernel - Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support

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: <20160912205017.GA12187@Asurada-Nvidia>
Date:   Mon, 12 Sep 2016 13:50:18 -0700
From:   Nicolin Chen <nicoleotsuka@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     vinod.koul@...el.com, linux-kernel@...r.kernel.org,
        linux-tegra@...r.kernel.org, dmaengine@...r.kernel.org,
        gnurou@...il.com, thierry.reding@...il.com, swarren@...dotorg.org,
        ldewangan@...dia.com
Subject: Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support

On Mon, Sep 12, 2016 at 03:34:08PM +0100, Jon Hunter wrote:

> > Sorry. I forgot to mention that the TEGRA210_CLK_APE_SLCG_OVR
> > clock is required for the tests. So I cherry-picked 2 patches
> > from your audio branch to the linux-next:
> > 	clk: tegra210: Add SLCG override gate clocks
> > 	ARM64: tegra: DT: Add SLCG clock for AUD

> > And it seems that you've submitted that patch once but it got
> > hold because it wasn't so useful at that time?

> Yes it was not being used at the time. It is on my list of things to do
> and we need to revisit it. There was some discussion on the best way to
> handle these clocks from a client perspective. I am not sure we came to
> a conclusion on this. I need to find some time to look at this.

I may also take a look to speed it up. Yet, putting that clock
aside, how about this patch then? I think we don't need to wait
for that clock patch in order to announce that we support this
now on a specific SoC but can just treat it as a new feature of
a DMA controller, which sounds quite plausible to me since the
ADMA module is now being disabled in all dts files of existing
SoCs -- There have to be some local changes in any way so as to
test it with the mainline code.

Thanks
Nic