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: <CEE6BB42CAD6E947908279175AF8470A03A50F78@EXDCVYMBSTM006.EQ1STM.local>
Date:	Thu, 8 Apr 2010 08:35:08 +0200
From:	Linus WALLEIJ <linus.walleij@...ricsson.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...retlab.ca>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@...t.st.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 00/11] ARM: PrimeCell DMA Interface v5

[Dan]

> > I suggest putting these into Andrews tree now, since:
> >
> > A) 4 of the patches it touches MMCI code which is hanled
> >   by Andrew
> 
> Ok, but it looks like they do not have a build dependency on dma bits
> so they could be merged separately i.e. on top of the async_tx branch.

Well:

[PATCH 04/11] ARM: define the PrimeCell DMA API v5
Is independent. (One .h-file.)

[PATCH 05/11] ARM: add generic PrimeCell interface to COH 901 318 v5
[PATCH 06/11] ARM: add generic PrimeCell interface to DMA40 v1
Depends on 04 AND has a merge dependency on the recent patches for generic
channel control and status, and then the DMA40 driver which is now
Picked into Andrews -mm. So the whole thing does depend on async_tx
HEAD.

Is it possible to move the two DMA40 patches over from -mm to async_tx
to atleast lower the complexity a little bit? (Should be to just
apply them...)

If this is done, you could apply the above three patches to the
async_tx tree.

[PATCH 07/11] ARM: add PrimeCell generic DMA to MMCI/PL180 v5
This is where is starts to get complicated because this patch
Depends on 01, 02, 03, 04. So it has to be applied to a tree
which contains all of it.

[PATCH 08/11] ARM: add PrimeCell generic DMA to PL011 v5
Just depends on 04 (that's the idea, a generic PrimeCell interface)
so could be applied to the async_tx tree
if the others go in there.

[PATCH 09/11] ARM: add PrimeCell generic DMA to PL022 v5
Same thing, plus it is Acked-by: Grant and OK to merge into
async_tx if 04 is there.

[PATCH 10/11] ARM: config U300 PL180 PL011 PL022 for DMA v5
[PATCH 11/11] ARM: config Ux500 PL011 PL022 for DMA v1
These should go in through the ARM tree really, it's platform
data.

> > B) It extends the DMA40 driver which is now pending in
> >   his tree as well.
> >
> > C) Since there doesn't seem to be any consensus of whether
> >   this is the right way forward, it needs some wider
> >   testing I believe.
> 
> No consensus with respect to which pieces, the Primecell driver or
> something outside of drivers/dma?  Forgive me for missing recent
> conversations if this has been discussed to death already.

Well, I'd want Russell to comment on that, I think from the
PrimeCell point of view it is important that the file we put
in place in <linux/amba/dma.h> is something that will really
be likely to a good path forward for all PrimeCell and derivates.
And I really would like Russell to ACK that first, he historically
watches over the PrimeCell stuff.

But that said I think we're pretty solid:
- Implementation for three vastly different PrimeCells
- Implementation for two vastly different DMA engines
- It works in these combos (we've had lots of internal testing on these)

> I can go ahead and queue up the dma bits unless you would prefer, and
> Andrew agrees, to take this all through the -mm tree?

If it's OK with Russell, putting 04-06 plus 09 through async_tx 
tree is a good starter.

07 is problematic and require the entire series to be applied
in one go, 08 could be applied as well but needs Russells ACK.

Yours,
Linus Walleij

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ