From: Eric Biggers
More fscrypt definitions are being added, and we shouldn't use a
disproportionate amount of space in for fscrypt stuff.
So move the fscrypt definitions to a new header .
For source compatibility with existing userspace programs,
still includes the new header.
Signed-off-by:
From: Eric Biggers
Add an inode back-pointer to 'struct fscrypt_info', such that
inode->i_crypt_info->ci_inode == inode.
This will be useful for:
1. Evicting the inodes when a fscrypt key is removed, since we'll track
the inodes using a given key by linking their fscrypt_infos together,
r
Hello,
[Note: I'd like to apply this for v5.4. Additional review is greatly
appreciated, especially of the API before it's set in stone. Thanks!]
This patchset makes major improvements to how keys are added, removed,
and derived in fscrypt, aka ext4/f2fs/ubifs encryption. It does this by
addi
From: Eric Biggers
Prefix all filesystem encryption UAPI constants except the ioctl numbers
with "FSCRYPT_" rather than with "FS_". This namespaces the constants
more appropriately and makes it clear that they are related specifically
to the filesystem encryption feature, and to the 'fscrypt_*'
From: Eric Biggers
Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
deriving additional key material from the fscrypt master keys for v2
encryption policies. HKDF is a key derivation function built on top of
HMAC. We choose SHA-512 for the underlying unkeyed hash, and use
From: Eric Biggers
Add a new fscrypt ioctl, FS_IOC_GET_ENCRYPTION_KEY_STATUS. Given a key
specified by 'struct fscrypt_key_specifier' (the same way a key is
specified for the other fscrypt key management ioctls), it returns
status information in a 'struct fscrypt_get_key_status_arg'.
The main m
From: Eric Biggers
Update fs/crypto/ to use the new names for the UAPI constants rather
than the old names, then make the old definitions conditional on
!__KERNEL__.
Signed-off-by: Eric Biggers
---
fs/crypto/crypto.c | 2 +-
fs/crypto/fname.c| 2 +-
fs/crypto/fscrypt_pr
From: Eric Biggers
In preparation for introducing v2 encryption policies which will find
and derive encryption keys differently from the current v1 encryption
policies, refactor the v1 policy-specific key setup code from keyinfo.c
into keysetup_legacy.c. Then rename keyinfo.c to keysetup.c.
Not
From: Eric Biggers
Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
encryption key to the filesystem's fscrypt keyring ->s_master_keys,
making any files encrypted with that key appear "unlocked".
Why we need this
The main problem is that the "locked/unloc
From: Eric Biggers
Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
ioctls to be used by non-root users to add and remove encryption keys
from the filesystem-level crypto keyrings, subject to limitations.
Motivation: while privileged fscrypt key management is sufficient for
s
From: Eric Biggers
Add a new fscrypt policy version, "v2". It has the following changes
from the original policy version, which we call "v1" (*):
- Master keys (the user-provided encryption keys) are only ever used as
input to HKDF-SHA512. This is more flexible and less error-prone, and
it
From: Eric Biggers
Add a new fscrypt ioctl, FS_IOC_REMOVE_ENCRYPTION_KEY. This ioctl
removes an encryption key that was added by FS_IOC_ADD_ENCRYPTION_KEY.
It wipes the secret key itself, then "locks" the encrypted files and
directories that had been unlocked using that key -- implemented by
evi
From: Eric Biggers
Wire up the new ioctls for adding and removing fscrypt keys to/from the
filesystem, and the new ioctl for retrieving v2 encryption policies.
FS_IOC_REMOVE_ENCRYPTION_KEY also required making UBIFS use
fscrypt_drop_inode().
For more details see Documentation/filesystems/fscryp
From: Eric Biggers
Wire up the new ioctls for adding and removing fscrypt keys to/from the
filesystem, and the new ioctl for retrieving v2 encryption policies.
FS_IOC_REMOVE_ENCRYPTION_KEY also required making ext4_drop_inode() call
fscrypt_drop_inode().
For more details see Documentation/files
From: Eric Biggers
Update the fscrypt documentation file to catch up to all the latest
changes, including the new ioctls to manage master encryption keys in
the filesystem-level keyring and the support for v2 encryption policies.
Signed-off-by: Eric Biggers
---
Documentation/filesystems/fscryp
From: Eric Biggers
By looking up the master keys in a filesystem-level keyring rather than
in the calling processes' key hierarchy, it becomes possible for a user
to set an encryption policy which refers to some key they don't actually
know, then encrypt their files using that key. Cryptographic
From: Eric Biggers
Wire up the new ioctls for adding and removing fscrypt keys to/from the
filesystem, and the new ioctl for retrieving v2 encryption policies.
FS_IOC_REMOVE_ENCRYPTION_KEY also required making f2fs_drop_inode() call
fscrypt_drop_inode().
For more details see Documentation/files
> -Original Message-
> From: Horia Geanta
> Sent: Friday, July 26, 2019 9:17 PM
> To: Pascal Van Leeuwen ;
> linux-crypto@vger.kernel.org
> Cc: Herbert Xu ; da...@davemloft.net; m...@iki.fi
> Subject: Re: gcm.c question regarding the rfc4106 cipher suite
>
> On 7/26/2019 6:55 PM, Pascal
While looking at CONFIG_PREEMPT dependencies treewide the #ifdef in
crypto_yield() matched.
CONFIG_PREEMPT and CONFIG_PREEMPT_VOLUNTARY are mutually exclusive so the
extra !CONFIG_PREEMPT conditional is redundant.
cond_resched() has only an effect when CONFIG_PREEMPT_VOLUNTARY is set,
otherwise i
On 7/26/2019 6:55 PM, Pascal Van Leeuwen wrote:
> Hi,
>
> I recently watched some patches fly by fixing issues in other drivers
> regarding the checking
> of supposedly illegal AAD sizes - i.e. to match the generic implementation
> there.
> I followed that with some interest as I'm about to impl
The newly introduced AES library exposes aes_encrypt/aes_decrypt
routines so rename existing occurrences of those identifiers in
the s390 driver.
Signed-off-by: Ard Biesheuvel
---
arch/s390/crypto/aes_s390.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/s390/cr
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
master
head: 0fe1c5a77257b9006b0b4b60652927d647bdd1a3
commit: e59c1c98745637796df824c0177f279b6e9cad94 [18/80] crypto: aes - create
AES library based on the fixed time AES code
config: s390-debug_defconf
This small patch fixes a null pointer derefence panic that occurred when
unloading the driver (using rmmod) on macchiatobin due to not setting
the platform driver data properly in the probe routine.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 2 ++
1 file chan
This patch adds support for the AES-XTS skcipher algorithm.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers/crypto/inside-secure/safexcel.h| 2 +
drivers/crypto/inside-secure/safexcel_cipher.c | 102 -
3 file
This patch set adds support for the AES-XTS skcipher algorithm.
Pascal van Leeuwen (3):
crypto: inside-secure - Move static cipher alg & mode settings to init
crypto: inside-secure - Add support for the AES-XTS algorithm
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers/crypto/
ctx->alg and ctx->mode were set from safexcel_send_req through the
various safexcel_encrypt and _decrypt routines, but this makes little
sense as these are static per ciphersuite. So moved to _init instead,
in preparation of adding more ciphersuites.
Signed-off-by: Pascal van Leeuwen
---
drivers
Hi,
I recently watched some patches fly by fixing issues in other drivers regarding
the checking
of supposedly illegal AAD sizes - i.e. to match the generic implementation
there.
I followed that with some interest as I'm about to implement this for the
inside-secure
driver.
And something puzzl
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check the return value of the hardware registration for caam_rng and free
> resources in case of failure.
>
> Fixes: e24f7c9 ("crypto: caam - hwrng support")
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
but please use at least 12 charac
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> @@ -892,24 +895,26 @@ void cnstr_shdsc_rfc4106_encap(u32 * const desc, struct
> alginfo *cdata,
> append_math_sub_imm_u32(desc, VARSEQINLEN, REG3, IMM, ivsize);
> append_math_add(desc, VARSEQOUTLEN, ZERO, REG3, CAAM_CMD_SZ);
>
> - /*
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check assoclen to solve the extra tests that expect -EINVAL to be
> returned when the associated data size is not valid.
>
> Validated assoclen for RFC4106 and RFC4543 which expects an assoclen
> of 16 or 20.
> Based on seqiv, IPsec ESP and RFC4543/RFC
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check authsize to solve the extra tests that expect -EINVAL to be
> returned when the authentication tag size is not valid.
>
> Validated authsize for GCM, RFC4106 and RFC4543.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Hor
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check key length to solve the extra tests that expect -EINVAL to be
> returned when the key size is not valid.
>
> Validated AES keylen for skcipher, ahash and aead.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> From: Horia Geantă
>
> Fuzz testing uncovered an issue when |user key| > |derived key|.
> Derived key generation has to be fixed in two cases:
>
> 1. Era >= 6 (DKP is available)
> DKP cannot be used with immediate input key if |user key| > |derived k
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> From: Horia Geantă
>
> skcipher encryption might fail and in some cases, like (invalid) input
> length smaller then block size, updating the IV would lead to panic
> due to copying from a negative offset (req->cryptlen - ivsize).
>
In v1 I mentioned
Antoine,
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Antoine Tenart
> Sent: Friday, July 26, 2019 3:47 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Pascal van Leeuwen
> ; linux-crypto@vger.kernel.org;
> herb...@gondor.apana.org.au; da...@davemlo
On 7/25/2019 4:47 PM, Iuliana Prodan wrote:
> Added inline helper functions to check authsize and assoclen for
> gcm and rfc4106.
Also rfc4543.
> diff --git a/include/crypto/gcm.h b/include/crypto/gcm.h
> index c50e057..9834b97 100644
> --- a/include/crypto/gcm.h
> +++ b/include/crypto/gcm.h
> @@
On 7/25/2019 4:47 PM, Iuliana Prodan wrote:
> Add inline helper function to check key length for AES algorithms.
> The key can be 128, 192 or 256 bits size.
> This function is used in the generic aes and aes_ti implementations.
>
Looks good.
Will need to respin it, since aes has just been refactor
This is a first baby step towards making the inside-secure crypto driver
more broadly useful. The current driver only works for Marvell Armada HW
and requires proprietary firmware, only available under NDA from Marvell,
to be installed. This patch set allows the driver to be used with other
hardwar
Until now, the inside-secure driver required a set of firmware images
supplied by the silicon vendor, typically under NDA, to be present in
/lib/firmware/inside-secure in order to be able to function.
This patch removes the dependence on this official vendor firmware by
falling back to generic "min
While being a generic EIP97/EIP197 driver, the driver was only selectable
for Marvell Armada hardware. This fix makes the driver selectable for any
Device Tree supporting kernel configuration, allowing it to be used for
other compatible hardware by just adding the correct device tree entry.
It als
Hi Pascal,
On Fri, Jul 26, 2019 at 01:28:13PM +, Pascal Van Leeuwen wrote:
> > On Fri, Jul 05, 2019 at 08:49:23AM +0200, Pascal van Leeuwen wrote:
>
> > > - /* H/W capabilities selection */
> > > - val = EIP197_FUNCTION_RSVD;
> > > - val |= EIP197_PROTOCOL_ENCRYPT_ONLY
This patch adds support for a PCIE development board with FPGA from Xilinx,
to facilitate pre-silicon driver development by both Inside Secure and its
IP customers. Since Inside Secure neither produces nor has access to actual
silicon, this is required functionality to allow us to contribute.
Sign
Antoine,
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Antoine Tenart
> Sent: Friday, July 26, 2019 3:07 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Pascal van Leeuwen
> ; linux-crypto@vger.kernel.org;
> herb...@gondor.apana.org.au; da...@davemlo
From: David Rientjes
[ Upstream commit 83bf42510d7f7e1daa692c096e8e9919334d7b57 ]
SEV_VERSION_GREATER_OR_EQUAL() will fail if upgrading from 2.2 to 3.1, for
example, because the minor version is not equal to or greater than the
major.
Fix this and move to a static inline function for appropriat
Antoine,
> Hi Pascal,
>
> On Fri, Jul 05, 2019 at 08:49:23AM +0200, Pascal van Leeuwen wrote:
> > Signed-off-by: Pascal van Leeuwen
>
> Could you add a commit message?
>
I can do that. Just didn't know it was really needed.
> > - /* H/W capabilities selection */
> > - val
On 02/07/2019 11:16 pm, Hannah Pan wrote:
> Add self-tests for the lzo-rle algorithm.
>
> Signed-off-by: Hannah Pan
> ---
> crypto/testmgr.c | 10 ++
> crypto/testmgr.h | 80
> 2 files changed, 90 insertions(+)
Hi Hannah,
Thanks for adding th
Hi Pascal,
On Fri, Jul 26, 2019 at 12:57:21PM +, Pascal Van Leeuwen wrote:
> > On Fri, Jul 05, 2019 at 08:49:22AM +0200, Pascal van Leeuwen wrote:
> > > Signed-off-by: Pascal van Leeuwen
> >
> > Could you provide a commit message, explaining briefly what the patch is
> > doing?
> >
> I init
Antoine,
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Antoine Tenart
> Sent: Friday, July 26, 2019 2:20 PM
> To: Pascal van Leeuwen
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
> herb...@gondor.apana.org.au; da...@davemloft.net; Pasc
On Fri, Jul 26, 2019 at 01:07:47PM +0200, Corentin Labbe via Groups.Io wrote:
> On Thu, Jul 25, 2019 at 04:55:30PM -0600, Rob Herring wrote:
> > On Thu, Jul 25, 2019 at 1:43 PM Corentin Labbe wrote:
> > >
> > > This patch adds documentation for Device-Tree bindings for the
> > > Amlogic GXL crypto
Ard Biesheuvel wrote:
> This v2/v3/v4 is a follow-up to both 'crypto: aegis128 - add NEON intrinsics
> version for ARM/arm64' [0] and 'crypto: morus - remove generic and x86
> implementations' [1]. Since there is some overlap, it makes sense to merge
> them and avoid merge conflicts.
>
> Now that
Chuhong Yuan wrote:
> Use dma_pool_zalloc instead of using dma_pool_alloc to allocate
> memory and then zeroing it with memset 0.
> This simplifies the code.
>
> Signed-off-by: Chuhong Yuan
> ---
> drivers/crypto/ccp/ccp-ops.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Patch appli
Hannah Pan wrote:
> Add self-tests for the lzo-rle algorithm.
>
> Signed-off-by: Hannah Pan
> ---
> crypto/testmgr.c | 10 ++
> crypto/testmgr.h | 80
> 2 files changed, 90 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> Use the new helper devm_platform_ioremap_resource() which wraps the
> platform_get_resource() and devm_ioremap_resource() together, to
> simplify the code.
>
> Signed-off-by: Anson Huang
> ---
> drivers/char/hw_random/imx-rngc.c | 4 +---
> 1 fi
Hook, Gary wrote:
> From: Gary R Hook
>
> Add a prefix to any messages logged by the ccp-crypto module, and
> add a notice if the module fails to load in the case that no CCPs
> are defined.
>
> Gary R Hook (2):
> crypto: ccp - Include the module name in system log messages
> crypto: ccp - Lo
Arnd Bergmann wrote:
> Each of the operations in ccp_run_cmd() needs several hundred
> bytes of kernel stack. Depending on the inlining, these may
> need separate stack slots that add up to more than the warning
> limit, as shown in this clang based build:
>
> drivers/crypto/ccp/ccp-ops.c:871:12:
Pascal van Leeuwen wrote:
> This patch set fixes all remaining issues with the cryptomgr extra tests
> when run on a Marvell A7K or A8K device (i.e Macchiatobin), resulting in
> a clean boot with the extra tests enabled.
>
> Pascal van Leeuwen (9):
> crypto: inside-secure - keep ivsize for DES E
Vakul Garg wrote:
> While running ipsec processing for traffic through multiple network
> interfaces, it is observed that caam driver gets less time to poll
> responses from caam block compared to ethernet driver. This is because
> ethernet driver has as many napi instances per cpu as the number o
Ard Biesheuvel wrote:
> This started out as an attempt to provide synchronous SIMD based GCM
> on 32-bit ARM, but along the way, I ended up changing and cleaning up
> so many things that it is more of a general AES cleanup now rather than
> anything else.
>
> Changes since v3:
> - fix build warni
Herbert,
> -Original Message-
> From: Herbert Xu
> Sent: Friday, July 26, 2019 2:24 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
> da...@davemloft.net
> Subject: Re: [PATCHv2 0/3] crypto: inside-secure - broaden driver scope
>
> On Fri, Ju
Sebastian Andrzej Siewior wrote:
> For spinlocks the type spinlock_t should be used instead of "struct
> spinlock".
>
> Use spinlock_t for spinlock's definition.
>
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: linux-crypto@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> dr
Pascal van Leeuwen wrote:
> This patch set adds support for the following additional AEAD suites:
> - authenc(hmac(sha1),cbc(des3_ede))
> - authenc(hmac(sha1),rfc3686(ctr(aes)))
> - authenc(hmac(sha224),rfc3686(ctr(aes)))
> - authenc(hmac(sha256),rfc3686(ctr(aes)))
> - authenc(hmac(sha384),rfc3686
Eric Biggers wrote:
> From: Eric Biggers
>
> To help avoid confusion, add a comment to ghash-generic.c which explains
> the convention that the kernel's implementation of GHASH uses.
>
> Also update the Kconfig help text and module descriptions to call GHASH
> a "hash function" rather than a "m
Fuqian Huang wrote:
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code and also reduce the chances of
On Fri, Jul 26, 2019 at 12:34:06PM +, Pascal Van Leeuwen wrote:
>
> Which now makes me wonder which of the patches I sent out ended up
> on the mailing list at alll ...
Just check the patchwork list:
https://patchwork.kernel.org/project/linux-crypto/list/
Cheers,
--
Email: Herbert X
Daniel Jordan wrote:
> With the removal of the padata timer, padata_do_serial no longer
> needs special CPU handling, so remove it.
>
> Signed-off-by: Daniel Jordan
> Cc: Herbert Xu
> Cc: Steffen Klassert
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> kernel/pada
Iuliana Prodan wrote:
> Check assoclen to solve the extra tests that expect -EINVAL to be
> returned when the associated data size is not valid.
>
> Validated assoclen for RFC4543 which expects an assoclen
> of 16 or 20, the same as RFC4106.
> Based on seqiv, IPsec ESP and RFC4543/RFC4106 the ass
Arnd Bergmann wrote:
> Clang sometimes makes very different inlining decisions from gcc.
> In case of the aegis crypto algorithms, it decides to turn the innermost
> primitives (and, xor, ...) into separate functions but inline most of
> the rest.
>
> This results in a huge amount of variables sp
Phani Kiran Hemadri wrote:
> This patch adds support to load Asymmetric crypto firmware on
> AE cores of CNN55XX device. Firmware is stored on UCD block 2
> and all available AE cores are tagged to group 0.
>
> Signed-off-by: Phani Kiran Hemadri
> Reviewed-by: Srikanth Jampala
> ---
> drivers/c
Hi Pascal,
On Fri, Jul 05, 2019 at 08:49:23AM +0200, Pascal van Leeuwen wrote:
> Signed-off-by: Pascal van Leeuwen
Could you add a commit message?
> - /* H/W capabilities selection */
> - val = EIP197_FUNCTION_RSVD;
> - val |= EIP197_PROTOCOL_ENCRYPT_ONLY | E
Hook, Gary wrote:
> Firstly, add a switch to allow/disallow debugfs code to be built into
> the CCP driver.
>
> This rest of the patch series implements a set of module parameters
> that allows control over which CCPs on a system are enabled by the
> driver, and how many queues on each device are
Ondrej Mosnacek wrote:
> Currently, NETLINK_CRYPTO works only in the init network namespace. It
> doesn't make much sense to cut it out of the other network namespaces,
> so do the minor plumbing work necessary to make it work in any network
> namespace. Code inspired by net/core/sock_diag.c.
>
>
Gilad Ben-Yossef wrote:
> Clean up unused ivgen support code and add support for notifiying
> Trusted Execution Enviornment of FIPS tests failures in FIPS mode.
>
> Gilad Ben-Yossef (4):
> crypto: ccree: drop legacy ivgen support
> crypto: ccree: account for TEE not ready to report
> crypto: f
Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/crypto/ccree/cc_driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: ht
Antoine,
> -Original Message-
> From: antoine.ten...@bootlin.com
> Sent: Friday, July 26, 2019 2:02 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
> herb...@gondor.apana.org.au; da...@davemloft.net
> Subject: Re: [PATCHv2 0/3] crypto: inside-
On Fri, Jul 26, 2019 at 12:21:40PM +, Pascal Van Leeuwen wrote:
>
> Actually, I did receive them back through the mailing list. In fact I depend
> on the mailing list to get them into my own regular company mailbox as
> I have to send them through gmail from my Linux dev system ...
> So I'm 10
Herbert,
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Herbert Xu
> Sent: Friday, July 26, 2019 2:03 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
> da...@davemloft.net
> Subject: Re: [PATCHv2 0/3] crypto: i
Hi Pascal,
On Fri, Jul 05, 2019 at 08:49:22AM +0200, Pascal van Leeuwen wrote:
> Signed-off-by: Pascal van Leeuwen
Could you provide a commit message, explaining briefly what the patch is
doing?
> @@ -199,6 +201,15 @@ static int safexcel_aead_aes_setkey(struct crypto_aead
> *ctfm, const u8 *ke
On Thu, 4 Jul 2019, Sebastian Andrzej Siewior wrote:
Polite reminder...
> For spinlocks the type spinlock_t should be used instead of "struct
> spinlock".
>
> Use spinlock_t for spinlock's definition.
>
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: linux-crypto@vger.kernel.org
> Signed-off-b
On Fri, Jul 26, 2019 at 11:33:07AM +, Pascal Van Leeuwen wrote:
> Hi,
>
> Just a gentle ping to remind people that this patch set - which incorporates
> the feedback I
> got on an earlier version thereof - has been pending for over a month now
> without
> receiving any feedback on it whats
Hi Pascal,
On Fri, Jul 26, 2019 at 11:33:07AM +, Pascal Van Leeuwen wrote:
>
> Just a gentle ping to remind people that this patch set - which incorporates
> the feedback I
> got on an earlier version thereof - has been pending for over a month now
> without
> receiving any feedback on it
Hi,
Just a gentle ping to remind people that this patch set - which incorporates
the feedback I
got on an earlier version thereof - has been pending for over a month now
without
receiving any feedback on it whatsoever ...
> -Original Message-
> From: Pascal van Leeuwen
> Sent: Tuesda
On Thu, Jul 25, 2019 at 04:55:30PM -0600, Rob Herring wrote:
> On Thu, Jul 25, 2019 at 1:43 PM Corentin Labbe wrote:
> >
> > This patch adds documentation for Device-Tree bindings for the
> > Amlogic GXL cryptographic offloader driver.
> >
> > Signed-off-by: Corentin Labbe
> > ---
> > .../bindin
82 matches
Mail list logo
