linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kim Phillips <kim.phillips@arm.com>
To: "Horia Geantă" <horia.geanta@nxp.com>
Cc: Radu Andrei Alexe <radu.alexe@nxp.com>,
	Vinod Koul <vinod.koul@intel.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Dan Douglass" <dan.douglass@nxp.com>,
	Shawn Guo <shawnguo@kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding
Date: Mon, 13 Nov 2017 09:21:32 -0600	[thread overview]
Message-ID: <20171113092132.55f13384cede1f283a53434b@arm.com> (raw)
In-Reply-To: <VI1PR0402MB3342C1736F492A323096541C982B0@VI1PR0402MB3342.eurprd04.prod.outlook.com>

On Mon, 13 Nov 2017 08:32:24 +0000
Horia Geantă <horia.geanta@nxp.com> wrote:

> On 11/10/2017 6:44 PM, Kim Phillips wrote:
> > On Fri, 10 Nov 2017 08:02:01 +0000
> > Radu Andrei Alexe <radu.alexe@nxp.com> wrote:
> [snip]>> 2. I wanted this driver to be tracked by the dma engine team.
> They have
> >> the right expertise to provide adequate feedback. If all the code was in 
> >> the crypto directory they wouldn't know about this driver or any 
> >> subsequent changes to it.
> > 
> > dma subsystem bits could still be put in the dma area if deemed
> > necessary but I don't think it is: I see
> > drivers/crypto/ccp/ccp-dmaengine.c calls dma_async_device_register for
> > example.
> > 
> Please see previous discussion with Vinod:
> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21468.html

Vinod says: "If the dma controller is internal to crypto, then it might
be okay to be inside the crypto driver."

Is that the case for the CCP driver?  Isn't it the case here?

In any case, I don't care that much about that, this all begat from new
*devices* coming out of nowhere.

> > What is the rationale for using the crypto h/w as a dma engine anyway?
> SoCs that don't have a system DMA, for e.g. LS1012A.

OK.

Kim

  reply	other threads:[~2017-11-13 15:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-30 13:46 [PATCH RESEND 0/4] add CAAM DMA memcpy driver Horia Geantă
2017-10-30 13:46 ` [PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding Horia Geantă
     [not found]   ` <20171030134654.13729-2-horia.geanta-3arQi8VN3Tc@public.gmane.org>
2017-10-30 14:24     ` Kim Phillips
2017-11-09 11:54       ` Radu Andrei Alexe
     [not found]         ` <VI1PR04MB1325BAD68A7CC8C7A302D9A48A570-mr6QIVyDiCGGEpojCloM0M9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-11-09 16:34           ` Kim Phillips
2017-11-10  8:02             ` Radu Andrei Alexe
2017-11-10 16:44               ` Kim Phillips
2017-11-13  8:32                 ` Horia Geantă
2017-11-13 15:21                   ` Kim Phillips [this message]
2017-11-13  9:44                 ` Radu Andrei Alexe
2017-11-13 15:22                   ` Kim Phillips
     [not found]                 ` <20171110104430.28b2f56f910b7514d778c4b2-5wv7dgnIgG8@public.gmane.org>
2017-11-16  6:24                   ` Vinod Koul
2017-11-16  6:18               ` Vinod Koul
2017-10-30 13:46 ` [PATCH RESEND 2/4] arm64: dts: ls1012a: add caam-dma node Horia Geantă
     [not found] ` <20171030134654.13729-1-horia.geanta-3arQi8VN3Tc@public.gmane.org>
2017-10-30 13:46   ` [PATCH RESEND 3/4] crypto: caam: add functionality used by the caam_dma driver Horia Geantă
2017-10-30 13:46   ` [PATCH RESEND 4/4] dma: caam: add dma memcpy driver Horia Geantă
2017-10-31 12:04     ` Vinod Koul
2017-11-08 14:36       ` Radu Andrei Alexe
     [not found]         ` <VI1PR04MB1325358D7898120FC0BCEBE88A560-mr6QIVyDiCGGEpojCloM0M9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-11-16  6:11           ` Vinod Koul
     [not found]     ` <20171030134654.13729-5-horia.geanta-3arQi8VN3Tc@public.gmane.org>
2017-11-02 10:16       ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171113092132.55f13384cede1f283a53434b@arm.com \
    --to=kim.phillips@arm.com \
    --cc=dan.douglass@nxp.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@nxp.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=radu.alexe@nxp.com \
    --cc=shawnguo@kernel.org \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).