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:	Mon, 17 Oct 2011 07:07:42 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
CC:	"Williams, Dan J" <dan.j.williams@...el.com>,
	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 Sat, Oct 15, 2011 at 7:26 AM, Jassi Brar <jaswinder.singh@...aro.org>
wrote:
> 
> On 15 October 2011 00:45, Bounine, Alexandre
> <Alexandre.Bounine@....com> wrote:
> 
> >> But doesn't the info, pointed to by this (void *), remain same for
> >> every
> >> transfer to a particular target/remote device ?
> > No. An address within the target may (and most likely will) be
changed for
> > every transfer. Target destination ID will be the same for given
virtual channel.
> >
> Thanks for the info.
> 
> > Virtual channel may bring the same challenge and I may need a
channel locking
> > if more than one requester try to read/write data to the same target
RIO device.
> >
> One can't avoid taking care of locking, but using virtual channels
> keeps the dma_chan usage consistent.
> 
Using virtual channels adds layers of complexity which may be avoided
with
simple API changes:
- virtual channel allocation: statically vs. dynamically
- linking virtual channel to the physical one


> RapidIO supports 34(32+2), 50(48+2) and 66(64+2) bit addressing
> which makes me wonder if the (upper or lower) 2 bits could be attached
> to
> the identity of the target device ?
> (tsi721 driver actually discards the upper 2 bits while claiming to
> support
> 66bit addressing so I couldn't make anything out of it and specs don't
> seem to say much about it)
> 
> If there is no user of 66bit addressing and isn't coming in very near
> future,
> we might as well drop that case for now(tsi721 already does) because
> that 'completeness' of support modifies the semantics of dmaengine
apis
> today for no real use.
This is marked to be fixed in tsi721 driver. Also, this is a local
deficiency
and changing it that does not affect other components of the RIO
subsystem.
Contrary to that, defining an upper layer affects all future development
and
may result in greater pain if it needs to be adjusted later. 

Alex.


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