Re: echainiv not working as supposed to be?

On Wed, Sep 07, 2016 at 12:08:10AM +0800, Herbert Xu wrote: > > > So, should echainiv use a per-context per-cpu array instead that -- > > for simplicity -- gets initialised with random bytes and will be > > updated as it's now, just not with a single global per-cpu array, but > > a per-context

Re: [PATCH] crypto: qat - fix incorrect accelerator mask for C3X devices

On Tue, Aug 30, 2016 at 06:56:00PM +0100, Giovanni Cabiddu wrote: > From: Maksim Lukoshkov > > Fix incorrect value of ADF_C3XXX_ACCELERATORS_MASK. > > Signed-off-by: Maksim Lukoshkov > Signed-off-by: Giovanni Cabiddu

Re: [PATCH] char: hw_random: bcm2835: handle of_iomap failures in bcm2835 driver

On Mon, Aug 29, 2016 at 10:40:16PM +0530, Arvind Yadav wrote: > Check return value of of_iomap and handle errors correctly. > > Signed-off-by: Arvind Yadav Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v2] hwrng: pasemi_rng.c: Migrate to managed API

On Sun, Sep 04, 2016 at 11:43:08PM +0530, PrasannaKumar Muralidharan wrote: > Use devm_ioremap and devm_hwrng_register instead of ioremap and > hwrng_register. This removes unregistering and error handling code. > > Changes in v2: > Remove hardcoded resource size in ioremap, use resource struct

Re: [PATCH] hwrng: core - Allocate memory during module init

On Sun, Sep 04, 2016 at 01:59:38PM +0530, PrasannaKumar Muralidharan wrote: > > @@ -573,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister); > > static int __init hwrng_modinit(void) > { > + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */ > + rng_buffer =

Re: [PATCH] crypto: ccp - add missing release in ccp_dmaengine_register

On Fri, Sep 02, 2016 at 11:48:53AM +0200, Quentin Lambert wrote: > ccp_dmaengine_register used to return with an error code before > releasing all resource. This patch adds a jump to the appropriate label > ensuring that the resources are properly released before returning. > > This issue was

Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz

On Sat, Sep 03, 2016 at 07:45:35PM +0300, Iaroslav Gridin wrote: > > @@ -247,6 +261,8 @@ err_clks_iface: > clk_disable_unprepare(qce->iface); > err_clks_core: > clk_disable_unprepare(qce->core); > +err_clks_core_src: > + clk_disable_unprepare(qce->core_src); What about

Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz

Hi Iaroslav, On 09/03/2016 07:45 PM, Iaroslav Gridin wrote: > Without that, QCE performance is about 2x less. On which platform? The clock rates are per SoC. > > Signed-off-by: Iaroslav Gridin > --- > drivers/crypto/qce/core.c | 18 +- >

Re: [PATCH] crypto: caam: add missing header dependencies

On Sat, Sep 03, 2016 at 11:29:30AM +0800, Baoyou Xie wrote: > We get 1 warning when building kernel with W=1: > drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for > 'caam_get_era' [-Wmissing-prototypes] > > In fact, this function is declared in drivers/crypto/caam/ctrl.h > and

Re: [PATCH] hwrng: core - Allocate memory during module init

On Wed, Sep 07, 2016 at 06:44:32PM +0530, PrasannaKumar Muralidharan wrote: > > Ah, yes! I can send a revised patch. > Do you think allocating rng_buffer, rng_fillbuf in module init useful? > If not there is no point in sending a new patch with fix. Yes I think it makes sense. Those who want to

Re: [PATCH] crypto: mv_cesa: remove NO_IRQ reference

On Sat, Sep 03, 2016 at 01:26:40AM +0200, Arnd Bergmann wrote: > Drivers should not use NO_IRQ, as we are trying to get rid of that. > In this case, the call to irq_of_parse_and_map() is both wrong > (as it returns '0' on failure, not NO_IRQ) and unnecessary > (as platform_get_irq() does the same

Re: [PATCH] hwrng: core - Allocate memory during module init

> On Sun, Sep 04, 2016 at 01:59:38PM +0530, PrasannaKumar Muralidharan wrote: >> >> @@ -573,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister); >> >> static int __init hwrng_modinit(void) >> { >> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */ >> + rng_buffer =

Re: [PATCH v4 0/2] crypto: engine: permit to enqueue ashash_request

On Wed, Aug 31, 2016 at 02:02:56PM +0200, Corentin Labbe wrote: > Hello > > I wanted to use the crypto engine for my Allwinner crypto driver but something > prevented me to use it: it cannot enqueue hash requests. > This patch convert crypto engine to permit enqueuing of ahash_requests. > It also

Re: [PATCH v2 0/3] crypto: arm and cryptd fixes

On Thu, Sep 01, 2016 at 02:25:40PM +0100, Ard Biesheuvel wrote: > Patch #1 fixes a trivial code generation issue on ARM. > > Patch #2 and #3 fix the broken GHASH on ARM using the v8 Crypto Extensions > pmull.64 instructions. The problem seems to be that it is allowed to call > .import() without

Re: [PATCH] crypto: caam - fix rfc3686(ctr(aes)) IV load

On Wed, Aug 31, 2016 at 03:57:55PM +0300, Catalin Vasile wrote: > -nonce is being loaded using append_load_imm_u32() instead of > append_load_as_imm() (nonce is a byte array / stream, not a 4-byte > variable) > -counter is not being added in big endian format, as mandatated by > RFC3686 and

Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs

On Mon, Sep 05, 2016 at 03:06:05PM +0300, Tero Kristo wrote: > > Additional request, would it be possible for you to check the rest > of the series and just ignore patches #2 and #3 for now, the rest > don't have any dependencies against these and can be applied cleanly > without. > > I would

Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration

On 7 September 2016 at 19:53, Romain Perier wrote: > Hello, > > > Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit : >>> >>> Use devm_hwrng_register instead of hwrng_register. It avoids the need >>> to handle unregistration explicitly from the remove

Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration

Hello, Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit : Use devm_hwrng_register instead of hwrng_register. It avoids the need to handle unregistration explicitly from the remove function. Signed-off-by: Romain Perier ---

Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration

Le 07/09/2016 16:45, PrasannaKumar Muralidharan a écrit : On 7 September 2016 at 19:53, Romain Perier wrote: Hello, Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit : Use devm_hwrng_register instead of hwrng_register. It avoids the need to handle

[PATCH v2 4/8] hwrng: omap - Remove global definition of hwrng

The omap-rng driver currently assumes that there will only ever be a single instance of an RNG device. For this reason, there is a statically allocated struct hwrng, with a fixed name. However, registering two struct hwrng with the same isn't accepted by the RNG framework, so we need to switch to

[PATCH v2 0/8] Add support for SafeXcel IP-76 to OMAP RNG

The driver omap-rng has a lot of similarity with the IP block SafeXcel IP-76. A lot of registers are the same and the way that the driver works is very closed the description of the TRNG EIP76 in its datasheet. This series refactorize the driver, add support for generating bigger output random

[PATCH v2 7/8] hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K

This commits adds a device variant for Safexcel,EIP76 found in Marvell Armada 8k. It defines registers mapping with the good offset and add a specific initialization function. Signed-off-by: Romain Perier --- Changes in v2: - Call pm_runtime_put_sync from the

[PATCH v2 2/8] dt-bindings: omap-rng: Document SafeXcel IP-76 device variant

This commits add missing fields in the documentation that are used by the new device variant. It also includes DT example to show how the variant should be used. Signed-off-by: Romain Perier --- Documentation/devicetree/bindings/rng/omap_rng.txt | 14

[PATCH v2 1/8] dt-bindings: Add vendor prefix for INSIDE Secure

This commits adds a vendor for the company INSIDE Secure. See https://www.insidesecure.com, for more details. Signed-off-by: Romain Perier --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v2 6/8] hwrng: omap - Don't prefix the probe message with OMAP

So far, this driver was only used for OMAP SoCs. However, if a device variant is added for an IP block that has nothing to do with the OMAP platform, the message "OMAP Random Number Generator Ver" is displayed anyway. Instead of hardcoding "OMAP" into this message, we decide to only display

[PATCH v2 5/8] hwrng: omap - Add support for 128-bit output of data

So far, this driver only supports up to 64 bits of output data generated by an RNG. Some IP blocks, like the SafeXcel IP-76 supports up to 128 bits of output data. This commits renames registers descriptions OUTPUT_L_REG and OUTPUT_H_REG to OUTPUT_0_REG and OUPUT_1_REG, respectively. It also adds

Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz

> > + ret = clk_set_rate(qce->core_src, 1); > > Could you point me from where you got this number? I got it from codeaurora qce driver: https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-r1/drivers/crypto/msm/qce50.c#3386 -- To unsubscribe from this list:

BUG while working on algif_skcipher AIO support

Hi Herbert, here is a reliably producable bug that I triggered while educating my libkcapi about AIO support. [70129.671557] page:ea0001361d80 count:0 mapcount:0 mapping: (null) index:0x0 [70129.671560] flags: 0x1c() [70129.671562] page dumped because:

BUG in recvmsg using io_submit

Hi Herbert, another one, different than the first report [71972.773115] page:ea0001fabf40 count:0 mapcount:0 mapping: (null) index:0x0 [71972.773118] flags: 0x1c() [71972.773119] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) [71972.773140]