linux-kernel - Re: [PATCH] dma: Add Keystone Packet DMA Engine 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]

Date:	Tue, 18 Mar 2014 20:54:44 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Santosh Shilimkar <santosh.shilimkar@...com>
Cc:	dmaengine@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	Sandeep Nair <sandeep_n@...com>,
	Russell King <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] dma: Add Keystone Packet DMA Engine driver

On Mon, Mar 17, 2014 at 03:37:47PM -0400, Santosh Shilimkar wrote:
> >> To simplify this bit more, you can think of this as DMA channels, flows
> >> are allocated and DMA channels are enabled by DMA engine and they remains
> >> enabled always as long as the channel in use. Enablling dma channel
> >> actually don't start the DMA transfer but just sets up the connection/pipe
> >> with peripheral and memory and vice a versa.
> >>
> >> All the descriptor management, triggering, sending completion interrupt or
> >> hardware signal to DMAEngine all managed by centralised QMSS.
> >>
> >> Actual copy of data is still done by DMA hardware but its completely
> >> transparent to software. DMAEngine hardware takes care of that in the
> >> backyard.
> > So you will use the dmaengine just for setting up the controller. Not for actual
> > transfers. Those would be governed by the QMSS, right?
> >
> Correct.
>  
> > This means that someone expecting to use dmaengine API will get confused about
> > this and doing part (alloc) thru dmaengine and rest (transfers) using some other
> > API. This brings to me the design approach, does it really make sense creating
> > dmaengine driver for this when we are not fully complying to the API
> > 
> Thats fair. The rationale behind usage of DMEngine was that its the closest
> available subsystem which can be leveraged for this hardware. We can
> pretty much use all the standard DMAEngine device tree parsing as well as
> the config API to setup DMAs. 
> 
> I think you made your stand clear, just to confirm, you don't prefer this
> driver to be a DMAEngine driver considering it doesn't fully complying to
> the APIs. We could document the deviation of 'transfer' handling to avoid
> any confusion.
Yup, a user will just get confused as the driver doenst conform the dmaengine
API. Unless someone comes up witha  strong argument on why it should be
dmaengine driver and what befits we see form such a model, i would like a
damengine driver to comply to standard API and usage.

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/