linux-kernel - RE: [PATCHv4] DMAEngine: Define interleaved transfer request api

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: <0CE8B6BE3C4AD74AB97D9D29BD24E55202321BB4@CORPEXCH1.na.ads.idt.com>
Date:	Fri, 14 Oct 2011 11:11:11 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Jassi Brar <jaswinder.singh@...aro.org>,
	"Williams, Dan J" <dan.j.williams@...el.com>
CC:	Vinod Koul <vinod.koul@...el.com>,
	Russell King <rmk@....linux.org.uk>,
	Barry Song <21cnbao@...il.com>, <linux-kernel@...r.kernel.org>,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>,
	Dave Jiang <dave.jiang@...el.com>
Subject: RE: [PATCHv4] DMAEngine: Define interleaved transfer request api

On Tue, Oct 11, 2011 at 2:42 PM, Jassi Brar <jaswinder.singh@...aro.org> wrote:

> 
> On 11 October 2011 22:14, Williams, Dan J <dan.j.williams@...el.com>
> wrote:
> > [ Adding Alexandre ]
> >
> > This is a tangent, but it would be nice if this API extension also
> > covered the needs of the incoming RapidIO case which wants to specify
> > new device context information per operation (and not once at
> > configuration time, like slave case).  Would it be enough if the
> > transfer template included a (struct device *context) member at the
> > end?  Most dma users could ignore it, but RapidIO could use it to do
> > something like:
> >
> >   struct rio_dev *rdev = container_of(context, typeof(*rdev),
> device);
> >
> > That might not be enough, but I'm concerned that making the context a
> > (void *) is too flexible.  I'd rather have something like this than
> > acquiring a lock in rio_dma_prep_slave_sg() and holding it over
> > ->prep().  The alternative is to extend device_prep_slave_sg to take
> > an extra parameter, but that impacts all other slave implementations
> > with a dead parameter.
> >
> From what I read so far, the requirement is closer to prep_slave_sg
> than to this api.
Yes, it is a closest fit so far but with one deficiency - it does not give
me a (natural) way to pass target device parameters for every transaction
that should be initiated.   

> 
> IMO, there should be a virtual channel for each device that the real
> physical channel, at the backend, can transfer data to/from.
> 
> The client driver should request each virtual channel corresponding
> to each target device it wants to transfer data with.
> 
> In the dmac driver - transfers queued for all virtual channels that are
> backed by the same physical channel, could be added to the same
> list and executed in FIFO manner.
> 
> That way, there won't be any need to hook target device info per
> transfer
> and more importantly "struct dma_chan" would continue to mean
> link between fixed 'endpoints'.
Passing a 66-bit RIO address will require an extra parameter anyway.
This brings us back to the problem that I have with the physical slave channel.



--
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/