Hi Gilad,
On Thu, May 24, 2018 at 3:20 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>> wrote:
Hi Gilad,
On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
>> does not d
mpiler into drbg_kcapi_seed().
Do you have a clue?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I ju
Hi Gilad,
On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>> wrote:
Hi Gilad,
On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> However, even with your clock patch, the signature checking fails for me,
>> on both R-C
On Thu, May 17, 2018 at 12:16 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef <gi...@benyossef.com>
> wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <ho...@verge.net.au> wrote:
>>> On Tue,
Hi Gilad,
On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <ho...@verge.net.au> wrote:
>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>>> On Tue, May 15, 2018 at
Hi Gilad,
On Thu, May 17, 2018 at 10:00 AM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>> wrote
};
The rest looks good, but I cannot verify the register block.
> +
> i2c3: i2c@e66d {
> #address-cells = <1>;
> #size-cells = <0>;
Gr{oetje,eeting}s,
Geert
--
Geert Uyt
nstances.
I also can't verify the parent clock.
> DEF_MOD("cmt3", 300, R8A7795_CLK_R),
> DEF_MOD("cmt2", 301, R8A7795_CLK_R),
> DEF_MOD("cmt1", 302, R8A7795_CLK_R),
Gr{oetje,eeti
ng too early, leading to "(ptrval)"
strings instead of actual hashed pointer values.
Sample timings on two platforms (arm / arm64) booting with lots of
debug ingo:
[ 28.521158] random: crng init done
[ 17.792705] random: crng init done
Gr{oetje,eeting}s,
G
Hi Gilad,
On Tue, Apr 24, 2018 at 10:31 AM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Mon, Apr 23, 2018 at 8:53 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Mon, Apr 23, 2018 at 3:22 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>> wrote:
Hi Gilad,
On Mon, Apr 23, 2018 at 3:22 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Mon, Apr 23, 2018 at 3:13 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Mon, Apr 23, 2018 at 1:48 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>> wrot
Hi Gilad,
On Mon, Apr 23, 2018 at 1:48 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> Limit option to compile ccree to plausible architectures.
Thanks for your patch!
> Suggested-by: Geert Uytterhoeven <ge...@linux-m68k.org>
> Signed-off-by: Gilad Ben-Yossef
Hi Gilad,
On Mon, Apr 23, 2018 at 9:45 AM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Wed, Apr 18, 2018 at 10:47 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Wed, Apr 18, 2018 at 6:32 AM, Gilad Ben-Yossef <gi...@benyossef.com>
>> wrote:
Hi Gilad,
On Wed, Apr 18, 2018 at 6:32 AM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Tue, Apr 17, 2018 at 9:14 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it
>> depend o
Hi Arnd,
On Tue, Apr 17, 2018 at 9:53 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Tue, Apr 17, 2018 at 8:14 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it
>> depend on ARM or
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
by several individual drivers.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v3:
- Rebase to v4.17-rc1,
- Handle new VIDEO_RENESAS_CEU symbol,
v2:
- Add Reviewed-by, Acked-by,
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.
Thanks for applying!
Geert Uytterhoeven (20):
ASoC: Remove depends on HAS_DMA in case of platform dependency
ata: Remove depends on HAS_DMA in case of platform dependency
cryp
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it
depend on ARM or ARM64, unless compile-testing.
Drop the dependency on HAS_DMA, as DMA is always available on ARM and
ARM64 platforms, and doing so will increase compile coverage.
Signed-off-by: Geert Uytterhoeven <
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
_SOC_STORM and/or
SND_SOC_APQ8016_SBC.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Acked-by: Mark Brown <broo...@kernel.org>
---
v3:
- Add Acked-by,
- Rebase t
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
_SOC_STORM and/or
SND_SOC_APQ8016_SBC.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Drop dependency of SND_
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v2
It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.
Thanks!
Geert Uytterhoeven (21):
ASoC: Remove depends on HAS_DMA in case of platform dependency
a
Do we need a dummy? The use of
set_dma_ops() in this driver is questionable),
- SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
dependency on HAS_DMA, as they are selected from
SND_SOC_APQ8016_SBC.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by:
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Do we need a dummy? The use of
set_dma_ops() in this driver is questionable),
- SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their
dependency on HAS_DMA, as they are selected from
SND_SOC_APQ8016_SBC.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by:
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
f NO_DMA=y, and its use in this driver
is questionable.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Acked-by: Robin Murphy <robin.mur...@arm.com>
---
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsyste
ncies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Mark Brown <broo...@kernel.org>
Hi Arnd,
On Thu, Feb 1, 2018 at 12:46 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Feb 1, 2018 at 11:21 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> Gcc versions before 4.4 do not recognize the __optimize__ compiler
>> attribute:
>>
>
Create a new function attribute __optimize, which allows to specify an
optimization level on a per-function basis.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
---
I assume this is supported as of gcc-4.4:
- gcc version 4.3.3 (GCC): warning: ‘__optimize__’ attribute dir
Gcc versions before 4.4 do not recognize the __optimize__ compiler
attribute:
warning: ‘__optimize__’ attribute directive ignored
Fixes: 7375ae3a0b79ea07 ("compiler-gcc.h: Introduce __nostackprotector function
attribute")
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k
With gcc-4.1.2:
crypto/sha3_generic.c:39: warning: ‘__optimize__’ attribute directive
ignored
Use the newly introduced __optimize macro to fix this.
Fixes: 83dee2ce1ae791c3 ("crypto: sha3-generic - rewrite KECCAK transform to
help the compiler optimize")
Signed-off-by: Geert Uy
NED_ACCESS
> def_bool 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
> help
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical
large for ‘long’ type
Fixes: 9e49451d7a15365d ("crypto: keywrap - simplify code")
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
---
crypto/keywrap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/keywrap.c b/crypto/keywrap.c
index
the intention for the test "sizeof(ip) > 4" to distinguish between
32-bit and 64-bit platforms?
As ip is __u64, while regs is a pointer, shouldn't the test be
"sizeof(regs) > 4"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linu
If NO_DMA=y:
ERROR: "bad_dma_ops" [drivers/crypto/mediatek/mtk-crypto.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Fixes: 7dee9f618790d0b7 ("crypto: mediatek - remove ARM dependencies")
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
---
drive
If NO_DMA=y:
ERROR: "bad_dma_ops" [drivers/crypto/atmel-tdes.ko] undefined!
ERROR: "bad_dma_ops" [drivers/crypto/atmel-sha.ko] undefined!
Add dependencies on HAS_DMA to fix this.
Fixes: ceb4afb3086ab08f ("crypto: atmel - refine Kconfig dependencies")
Sig
rypto: sha3 - Add SHA-3 hash algorithm")
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
---
crypto/sha3_generic.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/crypto/sha3_generic.c b/crypto/sha3_generic.c
index 62264397a2d28636..7e8ed96
intended to be sent
out. This works fine, as checkpatch will complain if I ever forget to remove
them while preparing patches.
The alternative would be to teach checkpatch to complain about FIXME, TODO,
and XXX in comments...
Gr{oetje,eeting}s,
Geert
--
Geert Uytt
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: David S. Miller <da...@davemloft.net>
Cc: linux-crypto@vger.ker
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Cc: Matt Mackall <m...@selenic.com>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.or
Hi Stephan,
On Tue, Jun 23, 2015 at 3:01 PM, Stephan Mueller smuel...@chronox.de wrote:
On Tue, Jun 23, 2015 at 11:17:23AM +0200, Geert Uytterhoeven wrote:
I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0.
With m68k-linux-gnu-gcc-4.1, which is still my default cross
-off-by: Stephan Mueller smuel...@chronox.de
Thanks, the warnings I saw before with m68k-linux-gnu-gcc-4.1.2
are gone.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people
target is not supported for this machine
[-Wpragmas]
#pragma GCC pop_options
^
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself
dma_request_slave_channel_compat()
Then all callers of dma_request_slave_channel_compat() have to be
modified to handle ERR_PTR first.
The same is true for (the existing) dma_request_slave_channel_reason()
vs. dma_request_slave_channel().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's
:(.text+0xa2b948): undefined reference to `dma_unmap_sg'
Also move the depends section below the tristate line while we're at
it.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
drivers/crypto/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto
From: Geert Uytterhoeven geert+rene...@glider.be
Commit 7e933d3b1e25b250 (crypto: ux500: use dmaengine_prep_slave_sg
API) changed the code to use the new API, but forgot to update an error
message.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Cc: Herbert Xu herb
Commit 7e933d3b1e25b250b58b827ef455a1b489c84157 (crypto: ux500: use
dmaengine_prep_slave_sg API) changed the code to use the new API, but
forgot to update an error message.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Jiri Kosina triv
select CRC_T10DIF?
select CRYPTO_HASH
help
CRC T10 Data Integrity Field computation is being cast as
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations
On Sun, 12 May 2013, Geert Uytterhoeven wrote:
However, the full list of errors isn't that unmanageable, so I'm following
up with a digested list...
lib/mpi/generic_mpih-mul1.c:50:3: error: inconsistent operand constraints in an
'asm': 1 errors in 1 logs
lib/mpi/generic_mpih-mul2.c:49:3: error
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
ball, but I think consistency wins. Not a validly signed
module = panic.
Just wondering, what's the advantage of doing panic over just
rejecting the module?
Panic is a DoS?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge
Ping?
On Sun, Mar 11, 2012 at 10:55, Geert Uytterhoeven ge...@linux-m68k.org wrote:
On Wed, 19 Oct 2011, Dmitry Kasatkin wrote:
Adds the multi-precision-integer maths library which was originally taken
from GnuPG and ported to the kernel by (among others) David Howells.
This version is taken
On Wed, May 19, 2010 at 13:40, David Woodhouse dw...@infradead.org wrote:
On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
Instead of having (different) defaults in sl[aou]b, perhaps we should
just remove the defaults completely, to ensure all architectures set
ARCH_SLAB_MINALIGN
)
Note that some platforms override this.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking
On Tue, 21 Apr 2009, Phillip Lougher wrote:
Geert Uytterhoeven wrote:
On Mon, 20 Apr 2009, Herbert Xu wrote:
On Tue, Mar 24, 2009 at 05:33:01PM +0100, Geert Uytterhoeven wrote:
Here's an alternative patch, which does exactly that.
Phillip, what do you think?
Thanks for your
If crypto_{,de}compress_{update,final}() succeed, return the actual number of
bytes produced instead of zero, so their users don't have to calculate that
theirselves.
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
---
As we're already at 2.6.30-rc5, I do not want to delay any
), complicating partial decompression.
I just started looking at this, my end goal is to use your pcomp patch for
squashfs and get lzma squahsfs.
That would be great, thx!
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate
On Mon, 20 Apr 2009, Geert Uytterhoeven wrote:
On Mon, 20 Apr 2009, Herbert Xu wrote:
On Tue, Mar 24, 2009 at 05:33:01PM +0100, Geert Uytterhoeven wrote:
Here's an alternative patch, which does exactly that.
Phillip, what do you think?
Thanks for your comments!
From
On Mon, 20 Apr 2009, Herbert Xu wrote:
On Tue, Mar 24, 2009 at 05:33:01PM +0100, Geert Uytterhoeven wrote:
Here's an alternative patch, which does exactly that.
Phillip, what do you think?
Thanks for your comments!
From be7d630f96a85d3ce48716b8e328563ba217647b Mon Sep 17 00:00:00
make C=1:
| crypto/pcompress.c:77:5: warning: symbol 'crypto_register_pcomp' was not
declared. Should it be static?
| crypto/pcompress.c:89:5: warning: symbol 'crypto_unregister_pcomp' was not
declared. Should it be static?
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
)
| crypto/testmgr.c:878:47:expected unsigned int *dlen
| crypto/testmgr.c:878:47:got int *noident
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
---
crypto/testmgr.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/crypto/testmgr.c b/crypto
On Tue, 17 Mar 2009, Geert Uytterhoeven wrote:
On Wed, 11 Mar 2009, Geert Uytterhoeven wrote:
On Sun, 8 Mar 2009, Phillip Lougher wrote:
Two API issues of concern (one major, one minor). Both of these relate
to the
way Squashfs drives the decompression code, where it repeatedly calls
On Wed, 25 Feb 2009, Geert Uytterhoeven wrote:
Modify SquashFS 4 to use the new pcomp crypto interface for decompression,
instead of calling the underlying zlib library directly. This simplifies e.g.
the addition of support for hardware decompression and different decompression
algorithms
On Wed, 11 Mar 2009, Geert Uytterhoeven wrote:
On Sun, 8 Mar 2009, Phillip Lougher wrote:
Two API issues of concern (one major, one minor). Both of these relate to
the
way Squashfs drives the decompression code, where it repeatedly calls it
supplying additional input/output buffers
Hi Phillip,
On Sun, 8 Mar 2009, Phillip Lougher wrote:
Herbert Xu wrote:
On Wed, Feb 25, 2009 at 02:43:14PM +0100, Geert Uytterhoeven wrote:
Modify SquashFS 4 to use the new pcomp crypto interface for
decompression,
instead of calling the underlying zlib library directly
missed this compile failure?
Does it sound sane to protect the routines that do call skb_put() by
#ifdef CONFIG_NET?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal
On Wed, 25 Feb 2009, Herbert Xu wrote:
On Mon, Feb 23, 2009 at 06:32:19PM +0100, Geert Uytterhoeven wrote:
Is the below (on top of my last patch series) what you have in mind?
Looks great to me!
OK.
Notes:
- I had to drop the `const' from the `params' pointers of
pcomp_alg
netlink attributes for the (de)compression setup parameters
- Move netlink attribute parsing support to lib/, enabled by CONFIG_NLATTR
David, Phillip: can I please have your ack?
If nobody objects, please apply.
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft
Netlink attribute parsing may be used even if CONFIG_NET is not set.
Move it from net/netlink to lib and control its inclusion based on the new
config symbol CONFIG_NLATTR, which is selected by CONFIG_NET.
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
Cc: David S. Miller da
meanings depend on
the actual (name of the) (de)compression algorithm.
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
---
crypto/Kconfig |4 +
crypto/Makefile|2 +
crypto/pcompress.c | 97
1 - 100 of 144 matches
Mail list logo
