I will never forget you

I will never forget you Greetings I'm sorry your response is very slow and i contacted another person, for the project.. I am happy to inform you about my success in getting those fund transferred to another account with the help of a new partner who is an international businessman. I am

[PATCH v16 2/7] parisc: iomap: introduce io{read|write}64

Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by: Logan

[PATCH v16 0/7] Add io{read|write}64 to io-64-atomic headers

This is v14 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their

[PATCH v16 3/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v16 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v16 1/7] iomap: Use non-raw io functions for io{read|write}XXbe

Fix an asymmetry in the io{read|write}XXbe functions in that the big-endian variants make use of the raw io accessors while the little-endian variants use the regular accessors. Some architectures implement barriers to order against both spinlocks and DMA accesses and for these case, the

[PATCH v16 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v16 5/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang

[PATCH v16 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

Hi Herbert, On Fri, Apr 20, 2018 at 3:01 PM, Herbert Xu wrote: > Is this a regression or a preexisting bug? It is not a regression. We haven't seen this problem before because dtsi files passed the 'fsl,sec-era' property. Since 4.17-rc1, imx7 supports CAAM:

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

On Fri, Apr 20, 2018 at 02:11:07PM -0300, Fabio Estevam wrote: > > Would it be possible to consider applying this one for 4.17-rc? > > Without this patch we get incorrect CAAM IP block version (era) on > i.MX7 on 4.17-rc1: > > caam 3090.caam: device ID = 0x0a160300 (Era -524) Is

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

Hi Herbert, On Fri, Apr 20, 2018 at 1:52 PM, Herbert Xu wrote: > On Wed, Apr 11, 2018 at 09:45:20AM -0300, Fabio Estevam wrote: >> From: Fabio Estevam >> >> The 'era' information can be retrieved from CAAM registers, so >> introduce a

Re: [PATCH] hwrng: via-rng - support new Centaur CPU

On Fri, Apr 13, 2018 at 03:03:03PM +0800, David Wang wrote: > New Centaur CPU(Family > 6) supprt Random Number Generator, but can't > support MSR_VIA_RNG. Just like VIA Nano. > > Signed-off-by: David Wang Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH] crypto: api - fix finding algorithm currently being tested

On Mon, Apr 16, 2018 at 04:59:13PM -0700, Eric Biggers wrote: > From: Eric Biggers > > Commit eb02c38f0197 ("crypto: api - Keep failed instances alive") is > making allocating crypto transforms sometimes fail with ELIBBAD, when > multiple processes try to access encrypted

Re: [PATCH v2] crypto: caam: - Use kmemdup() function

On Mon, Apr 16, 2018 at 01:05:01PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Use kmemdup() rather than duplicating its implementation. > > By usign kmemdup() we can also get rid of the 'val' variable. > > Detected with Coccinelle script. > > Signed-off-by:

Re: [PATCH] crypto: caam - strip input zeros from RSA input buffer

On Mon, Apr 16, 2018 at 12:34:45PM +0300, Horia Geantă wrote: > Sometimes the provided RSA input buffer provided is not stripped > of leading zeros. This could cause its size to be bigger than that > of the modulus, making the HW complain: > > caam_jr 2142000.jr1: 4789: DECO: desc idx 7: >

Re: [PATCH] crypto: drbg - set freed buffers to NULL

On Thu, Apr 12, 2018 at 08:40:55AM +0200, Stephan Müller wrote: > Add the Fixes, CC stable tags. > > ---8<--- > > During freeing of the internal buffers used by the DRBG, set the pointer > to NULL. It is possible that the context with the freed buffers is > reused. In case of an error during

Re: [PATCH] crypto: rsa - Remove unneeded error assignment

On Wed, Apr 11, 2018 at 06:37:17PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > There is no need to assign an error value to 'ret' prior > to calling mpi_read_raw_from_sgl() because in the case > of error the 'ret' variable will be assigned to the error > code

Re: [PATCH] crypto: testmgr: Allow different compression results

On Thu, Apr 19, 2018 at 01:58:40PM +0200, Jan Glauber wrote: > > Nice idea. Would a crypto_alloc_cipher("deflate", ...) pick the generic > implementation or how can we select it? For our ciphers we generally use the -generic suffix in the driver name. The compression algorithms seem to be all

Re: [PATCH][next] crypto: chtls: don't leak information from the stack to userspace

On Thu, Apr 05, 2018 at 05:44:03PM +0100, Colin King wrote: > From: Colin Ian King > > The structure crypto_info contains fields that are not initialized and > only .version is set. The copy_to_user call is hence leaking information > from the stack to userspace which

Re: [PATCH] crypto : chtls_cm - Fix potential NULL pointer dereferences

On Tue, Apr 03, 2018 at 03:09:12PM -0500, Gustavo A. R. Silva wrote: > Add null checks on lookup_tid() return value in order to prevent > null pointer dereferences. > > Addresses-Coverity-ID: 1467422 ("Dereference null return value") > Addresses-Coverity-ID: 1467443 ("Dereference null return

Re: [PATCH][next] crypto: chtls: remove redundant assignment to cdev->ports

On Fri, Apr 06, 2018 at 05:58:47PM +0100, Colin King wrote: > From: Colin Ian King > > There is a double assignment to cdev->ports, the first is redundant > as it is over-written so remove it. > > Detected by CoverityScan, CID#1467432 ("Unused value") > >

Re: [PATCH v4 1/2] crypto: caam - staticize caam_get_era()

On Wed, Apr 11, 2018 at 09:45:19AM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > caam_get_era() is only used locally, so do not export this function > and make it static instead. > > Signed-off-by: Fabio Estevam > Reviewed-by: Horia Geantă

Re: [PATCH] crypto: testmgr: Allow different compression results

On Wed, Apr 11, 2018 at 08:28:32PM +0200, Jan Glauber wrote: > From: Mahipal Challa > > The following error is triggered by the ThunderX ZIP driver > if the testmanager is enabled: > > [ 199.069437] ThunderX-ZIP :03:00.0: Found ZIP device 0 177d:a01a on > Node 0 > [

Re: [PATCH v2 0/2] crypto: removing various VLAs

On Mon, Apr 09, 2018 at 03:54:45PM +0200, Salvatore Mesoraca wrote: > v2: > As suggested by Herbert Xu, the blocksize and alignmask checks > have been moved to crypto_check_alg. > So, now, all the other separate checks are not necessary. > Also, the defines have been moved

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

On Wed, Apr 11, 2018 at 09:45:20AM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > The 'era' information can be retrieved from CAAM registers, so > introduce a caam_get_era_from_hw() function that gets it via register > reads in case the 'fsl,sec-era' property is not

Re: [PATCH v2 0/5] ThunderX ZIP driver bug fixes

On Mon, Apr 09, 2018 at 05:45:49PM +0200, Jan Glauber wrote: > Some bug fixes for this driver after it stopped working with virtual mapped > stacks. I think the first two patches qualify for stable. > > Jan Glauber (5): > crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK > crypto:

Re: [PATCH v3 1/2] crypto: authenc - don't leak pointers to authenc keys

On Tue, Apr 03, 2018 at 09:39:00AM +0300, Tudor Ambarus wrote: > In crypto_authenc_setkey we save pointers to the authenc keys in > a local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > > Signed-off-by:

Re: [RESEND PATCH] crypto: Add zstd support

On Fri, Mar 30, 2018 at 12:14:53PM -0700, Nick Terrell wrote: > Adds zstd support to crypto and scompress. Only supports the default > level. > > Previously we held off on this patch, since there weren't any users. > Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD, > which

Re: [PATCH v3 2/2] crypto: authencesn - don't leak pointers to authenc keys

On Tue, Apr 03, 2018 at 09:39:01AM +0300, Tudor Ambarus wrote: > In crypto_authenc_esn_setkey we save pointers to the authenc keys > in a local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > >

Re: [PATCH v2] crypto/ecc: Actually remove stack VLA usage

On Fri, Mar 30, 2018 at 09:55:44AM -0700, Kees Cook wrote: > On the quest to remove all VLAs from the kernel[1], this avoids VLAs > by just using the maximum allocation size (4 bytes) for stack arrays. > All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just > make it 4 bytes all

Re: [PATCH 0/3] crypto: caam - IV-related fixes

On Wed, Mar 28, 2018 at 03:39:16PM +0300, Horia Geantă wrote: > This patch set fixes several issues related to IV handling: > -in some cases IV direction is incorrect > -IVs need to be DMA mapped (when they are not provided directly > as "immediate" values in the descriptors); however, crypto API

Re: [PATCH v7 0/5] add compression algorithm zBeWalgo

Hi Benjamin, Today I tried your new patchset but I couldn't go further due to below problem. Unfortunately, I don't have the time to look into. Could you check on it? Thanks. [ 169.597064] zram0: detected capacity change from 1073741824 to 0 [ 177.523268] zram0: detected capacity change from

Re: [PATCH 06/61] crypto: simplify getting .drvdata

On Thu, Apr 19, 2018 at 4:05 PM, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang > --- > > Build tested