Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: > On 11/18/2015 04:29 PM, Arnd Bergmann wrote: > > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: > >> 2. non slave channel requests, where only the functionality matters, like > >> memcpy, interleaved, memset, etc. > >> We

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wed, Nov 18, 2015 at 04:51:54PM +0100, Arnd Bergmann wrote: > On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: > > > > > > I assume that the sst-firmware.c case is a mistake, it should just use a > > > plain DMA_SLAVE and not DMA_MEMCPY. > > > > Other way around. > > > > Ok, I

Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support

On Wed, 2015-11-18 at 13:06 +0800, Herbert Xu wrote: > On Tue, Nov 17, 2015 at 04:30:14PM -0800, Tim Chen wrote: > > On Wed, 2015-11-18 at 08:07 +0800, Herbert Xu wrote: > > > On Tue, Nov 17, 2015 at 02:59:29PM -0800, Tim Chen wrote: > > > > > > > > Herbert, would you prefer me to use ablkcipher

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi wrote: > Hi Vinod, > > bringing this old thread back to life as I just started to work on this. What I remember we need to convert drivers to use new API meanwhile it is good to keep old one to avoid patch storm which does

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wed, Nov 18, 2015 at 5:51 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: >> > >> > I assume that the sst-firmware.c case is a mistake, it should just use a >> > plain DMA_SLAVE and not DMA_MEMCPY. >> >> Other way around. >> > > Ok, I

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wed, Nov 18, 2015 at 5:07 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >> >> 2. non slave channel requests, where only the

[PATCH v3] crypto: atmel: fix bogus select

>From 0d53d42a56e9a3769847fd03c703876f2c063fb4 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 27 Jan 2015 22:34:04 +0100 Subject: [PATCH] [SUBMITTED] crypto: atmel: fix bogus select The Atmel at91 crypto driver unconditionally selects AT_HDMAC, which results in a Kconfig

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: > > > > I assume that the sst-firmware.c case is a mistake, it should just use a > > plain DMA_SLAVE and not DMA_MEMCPY. > > Other way around. > Ok, I see. In that case I guess it also shouldn't call dmaengine_slave_config(), right?

Re: [PATCH v3] crypto: atmel: fix bogus select

Hi Arnd, [auto build test WARNING on: cryptodev/master] [also build test WARNING on: v4.4-rc1 next-20151118] url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/crypto-atmel-fix-bogus-select/20151118-233706 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev

Re: [PATCH v3] crypto: atmel: fix bogus select

Hi Arnd, [auto build test WARNING on: cryptodev/master] [also build test WARNING on: v4.4-rc1 next-20151118] url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/crypto-atmel-fix-bogus-select/20151118-233706 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev

Re: A new, fast and "unbreakable" encryption algorithm

On Wed, Nov 18, 2015 at 12:10 AM, Ismail Kizir wrote: > I've developed a new encryption algorithm, which dynamically changes > the key according to plaintext and practically impossible to break. There is a very long history of crypto whose author considers is secure being

[PATCH v2] hw_random: omap3-rom-rng: convert timer to delayed work

We cannot put the HW RNG to idle using a timer because we cannot disable clocks from atomic context. Use a delayed work instead. Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot. Reported-by: Sebastian Reichel Signed-off-by: Aaro Koskinen

Re: A new, fast and "unbreakable" encryption algorithm

Hello Sandy, I agree every word you wrote. That's why, I am trying to explain all my login publicly to professionals. It's not rocket science. You will "just understand" when you read: Until today, we were looking from the "wrong side" I guess. We were all thinking that we must have a "fixed"

Re: [PATCH v3] crypto: atmel: fix bogus select

On Thursday 19 November 2015 02:17:21 kbuild test robot wrote: > > [auto build test WARNING on: cryptodev/master] > [also build test WARNING on: v4.4-rc1 next-20151118] > > url: > https://github.com/0day-ci/linux/commits/Arnd-Bergmann/crypto-atmel-fix-bogus-select/2015

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: > 2. non slave channel requests, where only the functionality matters, like > memcpy, interleaved, memset, etc. > We could have a simple: > dma_request_channel(mask); > > But looking at the drivers using dmaengine legacy

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On 11/18/2015 04:29 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >> 2. non slave channel requests, where only the functionality matters, like >> memcpy, interleaved, memset, etc. >> We could have a simple: >> dma_request_channel(mask); >> >> But looking

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

Hi Vinod, bringing this old thread back to life as I just started to work on this. On 06/24/2015 07:24 PM, Vinod Koul wrote: >> We would end up with the following APIs, all returning with error code on >> failure: >> dma_request_slave_channel(dev, name); >> dma_request_channel_legacy(mask, fn,

Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support

On Thu, 2015-11-19 at 08:12 +0800, Herbert Xu wrote: > On Wed, Nov 18, 2015 at 07:58:56AM -0800, Tim Chen wrote: > > > > IPSec will invoke this multi-buffer encrypt with async request. > > The work is done in crypto daemon, so it wouldn't be in atomic > > context. But anyway, I'm okay with

re: crypto: sahara - check return value of sg_nents_for_len

Hello LABBE Corentin, The patch 6c2b74d4774f: "crypto: sahara - check return value of sg_nents_for_len" from Nov 4, 2015, leads to the following static checker warning: drivers/crypto/sahara.c:480 sahara_hw_descriptor_create() warn: unsigned 'dev->nb_in_sg' is never less than

RE: [PATCH] crypto: add asynchronous compression support

On 10/16/2015 11:13 PM, Herbert Xu wrote: > On Fri, Oct 16, 2015 at 11:11:00PM +0800, Weigang Li wrote: >> This patch set introduces Asynchronous Compression API. >> What is proposed is a new crypto type called crypto_acomp_type, >> plus new struct acomp_alg and struct crypto_acomp, together with

Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support

On Wed, Nov 18, 2015 at 07:58:56AM -0800, Tim Chen wrote: > > IPSec will invoke this multi-buffer encrypt with async request. > The work is done in crypto daemon, so it wouldn't be in atomic > context. But anyway, I'm okay with switching to ablkcipher walk, > as long as it doesn't incur too much