similar to: STM32 Embedded - memory use and encode problem.

This patch convert the stm32-hash driver to the new crypto engine API. Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> --- drivers/crypto/stm32/stm32-hash.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/stm32/stm32-hash.c b/drivers/crypto/stm32/stm32-hash.c index 4ca4a264a833..9790c2c936c7 100644 ---

This patch convert the stm32-cryp driver to the new crypto engine API. Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> --- drivers/crypto/stm32/stm32-cryp.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c index cf1dddbeaa2c..99e0473ef247 100644 ---

This patch convert the driver to the new crypto engine API. Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> --- drivers/crypto/stm32/stm32-hash.c | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/stm32/stm32-hash.c b/drivers/crypto/stm32/stm32-hash.c index 4ca4a264a833..e3f9f7b04ce2 100644 ---

On 03/01/18 21:11, Corentin Labbe wrote: > This patch convert the stm32-cryp driver to the new crypto engine API. > Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> > --- > drivers/crypto/stm32/stm32-cryp.c | 21 ++++++++++++++++----- > 1 file changed, 16 insertions(+), 5 deletions(-) > > diff --git a/drivers/crypto/stm32/stm32-cryp.c

On 03/01/18 21:11, Corentin Labbe wrote: > This patch convert the stm32-hash driver to the new crypto engine API. > > Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> > --- > drivers/crypto/stm32/stm32-hash.c | 18 +++++++++++++----- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/drivers/crypto/stm32/stm32-hash.c

>Dear Speex developers >I am going to port Speex on LPC2368 >I tested Speex encoding and the mesurments shows ~40ms cpu time for one >frame >Do you know who ported speex to NXP or other 32bit platform? >Best Regards >Zohar fox I have an own optimisation for Speex for different versions of ARM architecture. Here is Measurements of performance for STM32 72 MHz. 4000

Hello everyone. I would like to use the opus codec in the following scenario: the PCM audio signal, coming from bluetooth module is captured by STM32F446 MCU and then decoded by opus codec. However, I don't know where to start to build the opuslib for ARM Cortex-M4. Could someone provide any hints or give any brief guide on this? WBR, Aleksandr -------------- next part -------------- An

Hello everyone. I would like to use the opus codec in the following scenario: the PCM audio signal, coming from bluetooth module is captured by STM32F446 MCU and then decoded by opus codec. However, I don't know where to start to build the opuslib for ARM Cortex-M4. Could someone provide any hints or give any brief guide on this? WBR, Aleksandr -------------- next part -------------- An

Hi Jen-Marc, this news were very interesting because of what I intedd to use speex for... Can you make some personal comments about that? Were you involved or consulted about it? Will it make it's way into the official version? I remember that you commented a long time ago that the DSPIC version was too much of a tour-de-force to make it to the official version, but this is a much nicer

Hi Corentin, I am fine with this proposal: it is generic enough and I have been able to test and run the crypto engine with aead_request without changing any single line of code. This is what I need to be able to send the AEAD extension of the stm32-cryp driver (successfully tested with your engine upgrade proposal). I have also tested the stm32-hash patch. Note that stm32-cryp (new

Hello, lately, I have been thinking about how to resolve the problem with that the program size increases enormously when including <iostream> when compiling with libstdc++. In this library, in <iostream> there is a static object __ioinit initialized like so: ... // For construction of filebuffers for cout, cin, cerr, clog et. al. static ios_base::Init __ioinit; ... This

On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote: > The reset control API has two modes: exclusive access, where the driver > expects to have full and immediate control over the state of the reset > line, and shared (clock-like) access, where drivers only request reset > deassertion while active, but don't care about the state of the reset line > while inactive.

The reset control API has two modes: exclusive access, where the driver expects to have full and immediate control over the state of the reset line, and shared (clock-like) access, where drivers only request reset deassertion while active, but don't care about the state of the reset line while inactive. Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset

On Wed, Dec 06, 2017 at 10:59:47AM +0000, Fabien DESSENNE wrote: > Hi Corentin, > > > I am fine with this proposal: it is generic enough and I have been able > to test and run the crypto engine with aead_request without changing any > single line of code. > > This is what I need to be able to send the AEAD extension of the > stm32-cryp driver (successfully tested

On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote: > Hello > > The current crypto_engine support only ahash and ablkcipher request. > My first patch which try to add skcipher was Nacked, it will add too many functions > and adding other algs(aead, asymetric_key) will make the situation worst. > > This patchset remove all algs specific stuff and now only process

Hello everyone, This set will switch the users of pm_runtime_put_autosuspend() to __pm_runtime_put_autosuspend() while the former will soon be re-purposed to include a call to pm_runtime_mark_last_busy(). The two are almost always used together, apart from bugs which are likely common. Going forward, most new users should be using pm_runtime_put_autosuspend(). Once this conversion is done and

On Thu, Feb 15, 2018 at 11:51:00PM +0800, Herbert Xu wrote: > On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote: > > Hello > > > > The current crypto_engine support only ahash and ablkcipher request. > > My first patch which try to add skcipher was Nacked, it will add too many functions > > and adding other algs(aead, asymetric_key) will make the

Hello The current crypto_engine support only ahash and ablkcipher request. My first patch which try to add skcipher was Nacked, it will add too many functions and adding other algs(aead, asymetric_key) will make the situation worst. This patchset remove all algs specific stuff and now only process generic crypto_async_request. The requests handler function pointer are now moved out of struct

Hi Corentin, Thank you for this new version which I have testes successfully with the stm32 hash & cryp drivers. As a general comment on this patchset, I would say that it does not cover all async requests: typically I need (for the pending stm32 cryp driver uprade) to use CryptoEngine to process AEAD requests which is not covered here. Could you please consider adding the

This patch adds the slim core rproc driver to the STi section of the MAINTAINERS file. Signed-off-by: Peter Griffin <peter.griffin at linaro.org> --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0bbe4b1..5dd3b24 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1749,6 +1749,7 @@ F: drivers/phy/phy-stih407-usb.c F: