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: <0CE8B6BE3C4AD74AB97D9D29BD24E55202322230@CORPEXCH1.na.ads.idt.com>
Date:	Tue, 18 Oct 2011 07:44:05 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Jassi Brar <jaswinder.singh@...aro.org>,
	Vinod Koul <vinod.koul@...el.com>
CC:	Russell King <rmk@....linux.org.uk>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	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 18, 2011 at 4:38 AM, Jassi Brar <jaswinder.singh@...aro.org>
wrote:
> 
> On 18 October 2011 13:56, Vinod Koul <vinod.koul@...el.com> wrote:
> > On Tue, 2011-10-18 at 14:00 +0530, Jassi Brar wrote:
> >> On 18 October 2011 13:12, Russell King <rmk@....linux.org.uk>
wrote:
> >> > On Tue, Oct 18, 2011 at 11:15:29AM +0530, Jassi Brar wrote:
> >> >> On 18 October 2011 02:37, Bounine, Alexandre
> <Alexandre.Bounine@....com> wrote:
> >> >> > With item #1 above being a separate topic, I may have a
problem
> with #2
> >> >> > as well: dma_addr_t is sized for the local platform and not
> guaranteed
> >> >> > to be a 64-bit value (which may be required by a target).
> >> >> > Agree with #3 (if #1 and #2 work).
> >> >> >
> >> >> Perhaps simply change dma_addr_t to u64 in dmaengine.h alone ?
> >> >
> >> > That's just an idiotic suggestion - there's no other way to put
> that.
> >> > Let's have some sanity here.
> >> >
> >> Yeah, I am not proud of the workaround, so I only probed the
option.
> >> I think I need to explain myself.
> >>
> >> The case here is that even a 32-bit RapidIO host could ask transfer
> against
> >> 64-bit address space on a remote device. And vice versa 64->32.
> > I thought RIO address were always 64 + 2 bits, irrespective of what
> the
> > host system is...
> >
> No, not always. RIO address could be 32, 48 or 64... with the role
> extra 2 bits
> not very clear.
RapidIO specification defines three possible address sizes for
Processing
Elements: 34, 50 and 66 bits.

There is no any special meaning for upper 2 bits that do not fit into
traditional 32- and 64-bit sizes and the best way to deal with them is
just forget this "+2" notion. 

Processing Elements report their ability to support (generate and
decode)
specified address field sizes (with 34-bit address support being
mandatory
for all PEs).

Even a platform with dma_size_t = 32 bit may be capable to generate RIO
requests with all RIO address ranges defined by RIO specification.
E.g., any platform that has PCI Express with one or more Tsi721.
Required RIO request address size will be defined by remote target
mapping/implementation.  

Using dma_memcopy API does not fit well into RIO system model because
one
of memory locations is outside of local memory map. This maybe a source
or
destination buffer.  

Within the existing DMA API only dma_slave fits well into RIO model but
it
is unable to pass additional information that does not fit into
MEM<->PORT model.

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/