linux-kernel - RE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers

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] [day] [month] [year] [list]

Message-ID: <0CE8B6BE3C4AD74AB97D9D29BD24E55202322024@CORPEXCH1.na.ads.idt.com>
Date:	Mon, 17 Oct 2011 12:39:45 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Vinod Koul <vinod.koul@...el.com>,
	Jassi Brar <jaswinder.singh@...aro.org>
CC:	Dan <dan.j.williams@...el.com>, <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	Matt Porter <mporter@...nel.crashing.org>,
	Li Yang <leoli@...escale.com>
Subject: RE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers

On Mon, Oct 17, 2011 at 1:01 PM, Vinod Koul <vinod.koul@...el.com> wrote:
> 
> On Mon, 2011-10-17 at 21:22 +0530, Jassi Brar wrote:
> > On 15 October 2011 23:05, Vinod Koul <vinod.koul@...el.com> wrote:
> >
> > > Another alternate approach could be to add one more argument to
> > > prep_slave_sg API which allows us to pass additional runtime
> specific
> > > parameters. This can be NULL and unused for existing drivers and
> used in
> > > RIO and any future subsystems which want to use dmaengine.
> > > Thoughts...?
> > >
> > That doesn't sound much different than passing the data via
> > dma_chan.private during prep_slave_sg. Only now we add to
> > the number of arguments.
> Yes agreed, but we already decided and marked it as depreciated.
> 
> > And then either this argument would be RapidIO specific (unfair
> > to other users) or generic. In latter case what would it look like ?
> My initial thoughts were to add an argument which only the specific
> dmac
> knows howto decode and is filled by its client. As i said for existing
> users and people who don't require dynamic information wouldn't bother.
> The pros
>  - allows us to support RIO kind of subsystems where one needs to pass
> subsystem specific information for programing the dmac
>  - doesn't require us to add subsystem specific stuff in dmaengine,
> today its RIO tomorrow some other folks may want to add. We want to
> maintain dmaengine as a generic framework, while also trying to support
> multiple audiences.
> Cons:
>  - there is no guarantee;  dmac expects foo and clients pass bar
> 
This was my concern that I mentioned in the beginning of this thread:
how to differentiate between different types of slave channels. At that
time we decided that channel filtering routines should be sufficient
to properly identify a suitable channel. And this is true - if RIO filter
detects registered RapidIO capable DMA channel it should be safe to pass
a parameter specific to RIO client implementation.   

If we want to protect pure slave channels from mixing with some specific
implementations we may consider adding new values for dma_transaction_type
as it done for RapidIO (DMA_RAPIDIO, DMA_FOO, DMA_BAR etc.).
This way we may keep single API with extra argument and differentiate
between "flavors" of DMA_SLAVE to make decisions about use of that
extra parameter. E.g. channels registered as DMA_SLAVE will ignore
the new parameter (pure slave mode), DMA_RAPIDIO and DMA_FOO use it
according to the "flavor".  

Yes, I am planning to drop that flag from the current RIO implementation but
It may have a new meaning if prep_slave_sg() gets the extra argument.  

> I am okay if we have alternate way to support this with above goal :)
> 
> --
> ~Vinod