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 currently
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 Gun
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
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 a
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
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 big-endian
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 enco
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
Acked-by: Allen Hubbe
Acked-by: Jon Mason
---
drivers/ntb/hw/
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
Cc: Jon Mason
---
dr
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:
0eeabcad7da5 ("ARM: dts: imx7s: ad
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 this
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 caam_get_era_from_hw() function that gets it via register
>>
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
Home Page: http://gondor.apana.org.au/~herbe
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 files with fscrypt for t
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: Fabio Estevam
Patch app
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:
> Pro
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 init
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 inside the if block.
>
> I
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 ove
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 must be avoided. Fix this b
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 value
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")
>
> Signed-off-by: Colin Ian King
Patch a
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ă
Patch applied. Thanks.
--
Email: Herbert Xu
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
> [ 199.073573] alg: comp:
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 t
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 passed in the device
>
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: thund
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 is
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: Tu
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 the
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.
>
> Signed-off-by
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 d
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 0
33 matches
Mail list logo
