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]

Date:	Wed, 12 Oct 2011 00:12:05 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	"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>, Alexandre.Bounine@....com
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

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.

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