TRADING ACCOUNT

2018-08-25 Thread KELLY ALAN



Dear sir ,

I KELLY ALAN  purchasing and sales manager of CFM INTERNATIONAL .Our 
Company specialised in Supplying computer hardware and Electronic .We 
want to extend our supplier list because of concurrency in prices on the 
international market. We are seeking a supplier with whom we can to have 
 partnered long-term in order to have competitive prices . we are 
interested to buy the products you sell and want to place an order with 
you in big quantities.
Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) 
?
What is the procedure for our account opening  and credit line 
application ?


Cordially

 KELLY ALAN

CFM INTERNATIONAL
2 BOULEVARD DU GAL MARTIAL VALIN
75015 PARIS
REG N° 302 527 700
VAT N° FR90 302527700
TEL +33171025367
FAX +33177759149
https://www.cfmaeroengines.com


Re: [PATCH] crypto: arm64/aes-gcm-ce - fix scatterwalk API violation

2018-08-25 Thread Herbert Xu
On Mon, Aug 20, 2018 at 04:58:34PM +0200, Ard Biesheuvel wrote:
> Commit 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on
> two input blocks at a time") modified the granularity at which
> the AES/GCM code processes its input to allow subsequent changes
> to be applied that improve performance by using aggregation to
> process multiple input blocks at once.
> 
> For this reason, it doubled the algorithm's 'chunksize' property
> to 2 x AES_BLOCK_SIZE, but retained the non-SIMD fallback path that
> processes a single block at a time. In some cases, this violates the
> skcipher scatterwalk API, by calling skcipher_walk_done() with a
> non-zero residue value for a chunk that is expected to be handled
> in its entirety. This results in a WARN_ON() to be hit by the TLS
> self test code, but is likely to break other user cases as well.
> Unfortunately, none of the current test cases exercises this exact
> code path at the moment.
> 
> Fixes: 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on two ...")
> Reported-by: Vakul Garg 
> Signed-off-by: Ard Biesheuvel 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: arm64/sm4-ce - check for the right CPU feature bit

2018-08-25 Thread Herbert Xu
On Tue, Aug 07, 2018 at 11:18:36PM +0200, Ard Biesheuvel wrote:
> ARMv8.2 specifies special instructions for the SM3 cryptographic hash
> and the SM4 symmetric cipher. While it is unlikely that a core would
> implement one and not the other, we should only use SM4 instructions
> if the SM4 CPU feature bit is set, and we currently check the SM3
> feature bit instead. So fix that.
> 
> Signed-off-by: Ard Biesheuvel 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: caam/qi - fix error path in xts setkey

2018-08-25 Thread Herbert Xu
On Mon, Aug 06, 2018 at 03:29:39PM +0300, Horia Geantă wrote:
> xts setkey callback returns 0 on some error paths.
> Fix this by returning -EINVAL.
> 
> Cc:  # 4.12+
> Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc 
> algorithms")
> Signed-off-by: Horia Geantă 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: caam - fix DMA mapping direction for RSA forms 2 & 3

2018-08-25 Thread Herbert Xu
On Mon, Aug 06, 2018 at 03:29:55PM +0300, Horia Geantă wrote:
> Crypto engine needs some temporary locations in external memory for
> running RSA decrypt forms 2 and 3 (CRT).
> These are named "tmp1" and "tmp2" in the PDB.
> 
> Update DMA mapping direction of tmp1 and tmp2 from TO_DEVICE to
> BIDIRECTIONAL, since engine needs r/w access.
> 
> Cc:  # 4.13+
> Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
> Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3")
> Signed-off-by: Horia Geantă 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: caam/jr - fix descriptor DMA unmapping

2018-08-25 Thread Herbert Xu
On Mon, Aug 06, 2018 at 03:29:09PM +0300, Horia Geantă wrote:
> Descriptor address needs to be swapped to CPU endianness before being
> DMA unmapped.
> 
> Cc:  # 4.8+
> Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam 
> endianness")
> Reported-by: Laurentiu Tudor 
> Signed-off-by: Horia Geantă 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] chtls_cm.c: fix missing return value check of alloc_skb()

2018-08-25 Thread Herbert Xu
Jiecheng Wu  wrote:
> Function chtls_close_conn() defined in 
> drivers/crypto/chelsio/chtls/chtls_cm.c calls alloc_skb() to allocate memory 
> for struct sk_buff which is dereferenced immediately. As alloc_skb() may 
> return NULL on failure, this code piece may cause NULL pointer dereference 
> bug.

Please add a sign-off.  You can refer to

Documentation/process/submitting-patches.rst

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [RESEND PATCH 2/2] crypto: caam - Support deferred probing in JR dependent drivers

2018-08-25 Thread Herbert Xu
On Tue, Aug 07, 2018 at 12:34:57PM +, Horia Geanta wrote:
> On 8/7/2018 11:00 AM, Marcin Niestroj wrote:
> > It is possible, that caam_jr_alloc() is called before JR devices are
> > probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
> > they are probed at later stage.
> > 
> These drivers don't have a probe() callback.
> Returning -EPROBE_DEFER in module's init() (caamrng) or crypto algorithm's
> init() (caamalg etc.) callbacks is not going to help, they won't be called 
> later.
> 
> Does adding request_module("caam_jr") in module's init() solve the issue?

If everything is built as a module this should always work because
a module isn't available until after its init function has finished.

So the only problem here appears to be when everything is built-in
in which case the init functions are run in random order.

So perhaps move caam_jr's module_init function to an earlier level
(i.e., earlier than device_initcall)?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt