Hallo,
Sind Sie in einer schwierigen Situation, für die Sie sich für ein
Darlehen suchen? Benötigen Sie eine Finanzierung, um eine Schuld zu
begleichen oder eine Aktivität zu finanzieren? Haben Sie einen
Verbraucherkredit, eine Hypothek, einen persönlichen Kredit, eine
Hypothek, Investition Darleh
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 2d55807b7f7bf62bb05a8b91247c5eb7cd19ac04
commit: 83dee2ce1ae791c3dc0c9d4d3a8d42cb109613f6 [165/172] crypto: sha3-generic
- rewrite KECCAK transform to help the compiler optimize
config: mn10300-allyes
On 25/01/18 17:50, Horia Geantă wrote:
If the first ("global") caam register page is not accessible, RNG init is not
the only problem. For e.g. device endianness detection won't work.
Hi Horia,
Yes I had that thought that there were other gotchas lurking once the
CAAM was in a more restricted
On Thu, Jan 25, 2018 at 01:58:38PM -0800, Tim Chen wrote:
> On 01/24/2018 07:10 PM, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The HASH_FIRST flag is never set. Remove it.
> >
> > Signed-off-by: Eric Biggers
> > ---
> > arch/x86/crypto/sha1-mb/sha1_mb.c | 28 +++---
On 01/24/2018 07:10 PM, Eric Biggers wrote:
> From: Eric Biggers
>
> The HASH_FIRST flag is never set. Remove it.
>
> Signed-off-by: Eric Biggers
> ---
> arch/x86/crypto/sha1-mb/sha1_mb.c | 28 +++-
> arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 8 +++-
> 2 files c
On 01/24/2018 07:09 PM, Eric Biggers wrote:
> From: Eric Biggers
>
> There is no need for ahash_mcryptd_{update,final,finup,digest}(); we
> should just call crypto_ahash_*() directly.
>
This clean up could have been done when we made sha1-mb async. Looks
reasonable.
Acked-by: Tim Chen
> Sig
<1513769897-26945-1-git-send-email-atul.gu...@chelsio.com>
On 12/20/17 05:08 PM, Atul Gupta wrote:
> +static void __init chtls_init_ulp_ops(void)
> +{
> + chtls_base_prot = tcp_prot;
> + chtls_base_prot.hash= chtls_hash;
> + chtls_base_prot.unhash =
On 25/01/18 13:20, Auer, Lukas wrote:
On Wed, 2018-01-24 at 14:50 +, Bryan O'Donoghue wrote:
When TrustZone is enabled on sec4 compatible silicon the first page
of the
CAAM is reserved for TrustZone only, this means that access to the
deco
registers is restricted and will return zero when re
On 1/24/2018 4:50 PM, Bryan O'Donoghue wrote:
> This patch-set enables CAAM on the i.MX7s and fixes a number of issues
> identified with the CAAM driver and hardware when TrustZone mode is
> enabled.
>
> The first block of patches are simple bug-fixes, followed by a second block
> of patches which
On 1/24/2018 4:50 PM, Bryan O'Donoghue wrote:
> From: Rui Miguel Silva
>
> caam_remove already removes the debugfs entry, so we need to remove the one
> immediately before calling caam_remove.
>
> This fix a NULL dereference at error paths is caam_probe fail.
>
> [bod: changed name prefix to "c
On Thu, Jan 25, 2018 at 12:38 PM, Yury Norov wrote:
> On Wed, Jan 24, 2018 at 11:28:55AM +0100, Arnd Bergmann wrote:
>> On Wed, Jan 24, 2018 at 10:05 AM, Yury Norov
>> wrote:
> Thanks for doing this test. Looking at this I realize that this is
> not the architecture feature but compiler feature
On Wed, 2018-01-24 at 14:50 +, Bryan O'Donoghue wrote:
> When TrustZone is enabled on sec4 compatible silicon the first page
> of the
> CAAM is reserved for TrustZone only, this means that access to the
> deco
> registers is restricted and will return zero when read.
>
> The solution to this p
On 25/01/18 11:38, Yury Norov wrote:
On Wed, Jan 24, 2018 at 11:28:55AM +0100, Arnd Bergmann wrote:
On Wed, Jan 24, 2018 at 10:05 AM, Yury Norov wrote:
This series adds API for 128-bit memory IO access and enables it for ARM64.
The original motivation for 128-bit API came from new Cavium netwo
On Wed, Jan 24, 2018 at 11:28:55AM +0100, Arnd Bergmann wrote:
> On Wed, Jan 24, 2018 at 10:05 AM, Yury Norov
> wrote:
> > This series adds API for 128-bit memory IO access and enables it for ARM64.
> > The original motivation for 128-bit API came from new Cavium network device
> > driver. The ha
After checking all possible call chains to crypto_report here,
my tool finds that crypto_report is never called in atomic context.
And crypto_report calls crypto_alg_match which calls down_read,
thus it proves again that crypto_report can call functions which may sleep.
Thus GFP_ATOMIC is not nece
After checking all possible call chains to kzalloc here,
my tool finds that this kzalloc is never called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
--
16 matches
Mail list logo