Re: powerpc/iommu: Support "hybrid" iommu/direct DMA ops for coherent_mask < dma_mask

On Mon, 2015-18-05 at 03:56:51 UTC, Benjamin Herrenschmidt wrote: > This patch adds the ability to the DMA direct ops to fallback to the IOMMU > ops for coherent alloc/free if the coherent mask of the device isn't > suitable for accessing the direct DMA space and the device also happens > to have a

Re: [PATCH V3 09/13] selftests, powerpc: Add test for DSCR value inheritence across fork

Hi Anshuman, Thanks for getting these testcases into the kernel. > This patch adds a test to verify that the changed DSCR value inside > any process would be inherited to it's child process across the fork > system call. One issue I do notice (a bug in my original test cases too), is that we don

Re: [PATCH 1/6] crypto: md5: add MD5 initial vectors

On Sun, May 17, 2015 at 12:54:12PM +0200, LABBE Corentin wrote: > This patch simply adds the MD5 IV in the md5 header. > > Signed-off-by: LABBE Corentin All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubke

[PATCH] powerpc/iommu: Support "hybrid" iommu/direct DMA ops for coherent_mask < dma_mask

This patch adds the ability to the DMA direct ops to fallback to the IOMMU ops for coherent alloc/free if the coherent mask of the device isn't suitable for accessing the direct DMA space and the device also happens to have an active IOMMU table. Signed-off-by: Benjamin Herrenschmidt Tested-by: B

[PATCH 6/6] crypto: octeon: use md5 IV MD5_HX instead of their raw value

Since MD5 IV are now available in crypto/md5.h, use them. Signed-off-by: LABBE Corentin --- arch/mips/cavium-octeon/crypto/octeon-md5.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/mips/cavium-octeon/crypto/octeon-md5.c b/arch/mips/cavium-octeon/crypto/octeon

[PATCH 5/6] crypto: n2: use md5 IV MD5_HX instead of their raw value

Since MD5 IV are now available in crypto/md5.h, use them. Signed-off-by: LABBE Corentin --- drivers/crypto/n2_core.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c index 10a9aef..2e8dab9 100644 --- a/drivers/crypto/

[PATCH 4/6] crypto: sparc/md5: use md5 IV MD5_HX instead of their raw value

Since MD5 IV are now available in crypto/md5.h, use them. Signed-off-by: LABBE Corentin --- arch/sparc/crypto/md5_glue.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/sparc/crypto/md5_glue.c b/arch/sparc/crypto/md5_glue.c index b688731..c9d2b92 100644 --- a/arc

[PATCH 3/6] crypto: powerpc/md5: use md5 IV MD5_HX instead of their raw value

Since MD5 IV are now available in crypto/md5.h, use them. Signed-off-by: LABBE Corentin --- arch/powerpc/crypto/md5-glue.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/crypto/md5-glue.c b/arch/powerpc/crypto/md5-glue.c index 452fb4d..9228967 100644 ---

[PATCH 2/6] crypto: md5: use md5 IV MD5_HX instead of their raw value

Since MD5 IV are now available in crypto/md5.h, use them. Signed-off-by: LABBE Corentin --- crypto/md5.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/crypto/md5.c b/crypto/md5.c index 36f5e5b..33d17e9 100644 --- a/crypto/md5.c +++ b/crypto/md5.c @@ -51,10 +51,10 @@

[PATCH 1/6] crypto: md5: add MD5 initial vectors

This patch simply adds the MD5 IV in the md5 header. Signed-off-by: LABBE Corentin --- include/crypto/md5.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/crypto/md5.h b/include/crypto/md5.h index 65f299b..146af82 100644 --- a/include/crypto/md5.h +++ b/include/crypto/md5.h @@

Re: [PATCH] i2c: powermac: don't workaround for keywest

Hi, Sorry for the delay, I found this message in my spam folder. Anyway, for my machine model, cat /proc/device-tree/compatible returns: PowerBook4,3MacRISC2MacRISCPower Macintosh It's a 14 in. iBook G3 700 MHz. Regards, Dan On Mon, 5/11/15, Benja

[PATCH] powerpc: mpc85xx: flush the l1 cache before cpu down in kexec

We observe a "Zero PT_NOTE entries found" warning when vmcore_init() is running on the dump-capture kernel. Actually the PT_NOTE segments is not empty, but the entries generated by crash_save_cpu() are not flushed to the memory before we reset these cores. So we should flush the l1 cache as what we