From: Hui Tang
HPRE of Kunpeng 930 is updated on cluster numbers and configurations
of Kunpeng 920 HPRE, so we try to update this driver to make it running
okay on both chips.
Signed-off-by: Hui Tang
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h |
1. Add 'CURVE25519' curve parameter definition to
'include/crypto/ecc_curve_defs.h';
2. Enable 'CURVE25519' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reported-by: kernel test robot
---
drivers/crypto/hisilicon/Kconfig| 1 +
drivers/crypto/hisilicon
1. Add some new 'ECDH' curve parameter definitions to
'include/crypto/ecc_curve_defs.h', and reorder ECC 'Curves IDs'
in 'include/crypto/ecdh.h';
2. Enable 'ECDH' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 4 +
Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
drivers/crypto/hisilicon/hpre/hpr
Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
so all can use it,
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 1 -
crypto/ecc.h| 37 +
crypto/ecc_curve_defs.h | 57
1. Move elliptic curve parameter definitions out to "include/crypto";
2. Add some new elliptic curve parameters definitions, and reorder
ECC 'Curves IDs';
3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930.
These patches depend on:
[v2,1/6] crypto: hisilicon/hpre - add version adapt
Remove including that don't need it.
Signed-off-by: Tian Tao
---
drivers/crypto/ccree/cc_driver.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/ccree/cc_driver.h b/drivers/crypto/ccree/cc_driver.h
index 5f1d460..f49579a 100644
--- a/drivers/crypto/ccree/cc_driver.h
+++ b/dri
PicoXcell has had nothing but treewide cleanups for at least the last 8
years and no signs of activity. The most recent activity is a yocto vendor
kernel based on v3.0 in 2015.
These patches can go via the respective maintainers' trees.
Rob
Rob Herring (4):
ARM: dts: Remove PicoXcell platforms
PicoXcell has had nothing but treewide cleanups for at least the last 8
years and no signs of activity. The most recent activity is a yocto vendor
kernel based on v3.0 in 2015.
Cc: Jamie Iles
Cc: devicet...@vger.kernel.org
Signed-off-by: Rob Herring
---
arch/arm/boot/dts/Makefile
PicoXcell has had nothing but treewide cleanups for at least the last 8
years and no signs of activity. The most recent activity is a yocto vendor
kernel based on v3.0 in 2015.
Cc: Jamie Iles
Cc: Russell King
Signed-off-by: Rob Herring
---
MAINTAINERS | 9
arch/arm/K
PicoXcell has had nothing but treewide cleanups for at least the last 8
years and no signs of activity. The most recent activity is a yocto vendor
kernel based on v3.0 in 2015.
Cc: Jamie Iles
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Rob Herring
---
T
PicoXcell has had nothing but treewide cleanups for at least the last 8
years and no signs of activity. The most recent activity is a yocto vendor
kernel based on v3.0 in 2015.
Cc: Jamie Iles
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Rob Herring
---
I'll take this via the DT tree.
.../de
On Thu, Dec 10, 2020 at 03:47:50PM +0100, Heiner Kallweit wrote:
> Zillions of drivers use the unlikely() hint when checking the result of
> dma_mapping_error(). This is an inline function anyway, so we can move
> the hint into the function and remove it from drivers.
> From time to time discussion
> On Dec 10, 2020, at 2:49 AM, David Howells wrote:
>
> Eric Snowberg wrote:
>
>> Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
>> is found, it is added as an asymmetrical key to the .blacklist keyring.
>> Anytime the .platform keyring is used, the keys in the .bla
This series is presented in response to the discussion [0] that has been going
on on the linux-crypto list regarding the use of SIMD in synchronous skciphers
and AEADs, which is problematic if such transforms may be used in softirq
context while the SIMD unit is already being used by the kernel in
Allow kernel mode NEON to be used in softirq context as well as process
context. To avoid nested use of the NEON, which would require the kernel
mode process context NEON state to be preserved while the NEON is used in
softirq context, turn off softirq processing when enabling kernel mode NEON.
Si
Now that kernel mode NEON is guaranteed to be available both in process
and in softirq context, we no longer have a need for the SIMD helper or
for non-SIMD fallbacks, given that the skcipher API is not supported in
any other context anyway. So drop this code.
Signed-off-by: Ard Biesheuvel
---
a
Now that kernel mode NEON is guaranteed to be available both in process
and in softirq context, we no longer have a need for the SIMD helper or
for non-SIMD fallbacks, given that the skcipher API is not supported in
any other context anyway. So drop this code.
Signed-off-by: Ard Biesheuvel
---
a
Hi Nicolas,
On Thu, Dec 10, 2020 at 02:18:45PM +0100, Nicolas Dichtel wrote:
> Le 10/12/2020 à 12:48, Eyal Birger a écrit :
> > On Thu, Dec 10, 2020 at 1:10 PM Nicolas Dichtel
> > wrote:
> [snip]
> > I also think they should be consistent. But it'd still be confusing to me
> > to get an OUTPUT ho
Hi Ard,
I love your patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on powerpc/next v5.10-rc7 next-20201210]
[cannot apply to crypto/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On 12/9/20 11:30 PM, Ard Biesheuvel wrote:
On Thu, 10 Dec 2020 at 04:01, Ben Greear wrote:
On 12/9/20 6:43 PM, Herbert Xu wrote:
On Thu, Dec 10, 2020 at 01:18:12AM +0100, Ard Biesheuvel wrote:
One thing I realized just now is that in the current situation, all
the synchronous skciphers alre
gh which tree this is supposed to go.
Patch is based on linux-next-20201210.
---
drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 3 +--
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 2 +-
.../marvell/octeontx/otx_cptvf_reqmgr.c | 5 ++--
drivers/crypto/mediatek/mtk-aes.c
Le 10/12/2020 à 12:48, Eyal Birger a écrit :
> Hi Nicolas,
Hi Eyal,
>
> On Thu, Dec 10, 2020 at 1:10 PM Nicolas Dichtel
> wrote:
[snip]
> I also think they should be consistent. But it'd still be confusing to me
> to get an OUTPUT hook on the inner packet in the forwarding case.
I re-read the wh
On Thu, 10 Dec 2020 at 13:16, Herbert Xu wrote:
>
> On Thu, Dec 10, 2020 at 01:03:56PM +0100, Ard Biesheuvel wrote:
> >
> > But we should probably start policing this a bit more. For instance, we now
> > have
> >
> > drivers/net/macsec.c:
> >
> > /* Pick a sync gcm(aes) cipher to ensure order is
On Thu, Dec 10, 2020 at 01:03:56PM +0100, Ard Biesheuvel wrote:
>
> But we should probably start policing this a bit more. For instance, we now
> have
>
> drivers/net/macsec.c:
>
> /* Pick a sync gcm(aes) cipher to ensure order is preserved. */
> tfm = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG
On Thu, 10 Dec 2020 at 12:14, Herbert Xu wrote:
>
> On Thu, Dec 10, 2020 at 08:30:47AM +0100, Ard Biesheuvel wrote:
> >
> > I would argue that these are orthogonal. My patch improves both the
> > accelerated and the fallback path, given that the latter does not have
> > to walk the input data twic
Hi Nicolas,
On Thu, Dec 10, 2020 at 1:10 PM Nicolas Dichtel
wrote:
>
> Le 09/12/2020 à 15:40, Eyal Birger a écrit :
> > Hi Phil,
> >
> > On Tue, Dec 8, 2020 at 8:51 PM Phil Sutter wrote:
> >>
> >> Hi Eyal,
> >>
> >> On Tue, Dec 08, 2020 at 04:47:02PM +0200, Eyal Birger wrote:
> >>> On Mon, Dec 7
In the new generation of accelerator hardware, in order to
add new algorithm support, the hardware adds a new SQE data structure,
so the driver has been upgraded as needed.
Signed-off-by: Sihang Chen
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec.h| 6 +-
drivers/cr
Add support for new algorithms of SEC accelerator on Kunpeng930,
the driver and test case needs to be updated
Longfang Liu (5):
crypto: hisilicon/sec - add new type of sqe for Kunpeng930
crypto: hisilicon/sec - add new skcipher mode for SEC
crypto: hisilicon/sec - add new AEAD mode for SEC
Add new skcipher algorithms for Kunpeng930 SEC:
OFB(AES), CFB(AES), CTR(AES),
OFB(SM4), CFB(SM4), CTR(SM4).
Signed-off-by: Wenkai Lin
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 88 +++---
drivers/crypto/hisilicon/sec2/sec_crypto.h | 2 +
From: Meng Yu
A new generation of accelerator Kunpeng930 has appeared, and the
corresponding driver needs to be updated to support some new
algorithms of Kunpeng930. To be compatible with Kunpeng920, we
add parameter 'struct hisi_qm *qm' to sec_algs_(un)register to
identify the chip's version.
S
On Thu, Dec 10, 2020 at 08:30:47AM +0100, Ard Biesheuvel wrote:
>
> I would argue that these are orthogonal. My patch improves both the
> accelerated and the fallback path, given that the latter does not have
> to walk the input data twice anymore, and go through 3 layers of
> templates and the ass
1. Fix a problem of error log printing
2. Modify error log printing style
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec.h| 5 +-
drivers/crypto/hisilicon/sec2/sec_crypto.c | 94 +++---
drivers/crypto/hisilicon/sec2/sec_crypto.h | 4 +-
3 file
Add testing cases for new algorithms such as
'XTS(SM4)', 'CCM(SM4)' and 'GCM(SM4)' to 'Crypto testmgr'.
Except for CCM(AES) exiting with unexpected success,
other algorithms have successfully passed the
crypto self-tests.
Signed-off-by: Longfang Liu
---
arch/arm64/configs/defconfig | 2 +-
cr
Le 09/12/2020 à 15:40, Eyal Birger a écrit :
> Hi Phil,
>
> On Tue, Dec 8, 2020 at 8:51 PM Phil Sutter wrote:
>>
>> Hi Eyal,
>>
>> On Tue, Dec 08, 2020 at 04:47:02PM +0200, Eyal Birger wrote:
>>> On Mon, Dec 7, 2020 at 4:07 PM Phil Sutter wrote:
[snip]
>>
>> The packet appears twice being sent t
Add new AEAD algorithms to SEC:
CCM(AES), GCM(AES), CCM(SM4), GCM(SM4).
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec.h| 4 +
drivers/crypto/hisilicon/sec2/sec_crypto.c | 382 -
drivers/crypto/hisilicon/sec2/sec_crypto.h | 5 +
3 files
Eric Snowberg wrote:
> Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
> is found, it is added as an asymmetrical key to the .blacklist keyring.
> Anytime the .platform keyring is used, the keys in the .blacklist keyring
> are referenced, if a matching key is found, the
Ben Boeckel wrote:
> > I've extended my collection of minor keyrings fixes for the next merge
> > window. Anything else I should add (or anything I should drop)?
> >
> > The patches can be found on the following branch:
> >
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
The cipher routines in the crypto API are mostly intended for templates
implementing skcipher modes generically in software, and shouldn't be
used outside of the crypto subsystem. So move the prototypes and all
related definitions to a new header file under include/crypto/internal.
Also, let's use
Allocating a cipher via the crypto API only to free it again after using
it to encrypt a single block is unnecessary in cases where the algorithm
is known at compile time. So replace this pattern with a call to the AES
library.
Cc: Ayush Sawal
Cc: Vinay Kumar Yadav
Cc: Rohit Maheshwari
Signed-o
Patch #2 puts the cipher API (which should not be used outside of the
crypto API implementation) into an internal header file and module
namespace
Patch #1 is a prerequisite for this, to avoid having to make the chelsio
driver import the crypto internal namespace.
Cc: Eric Biggers
Ard Biesheuve
On 12/3/2020 3:35 AM, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan
>
> This series removes CRYPTO_ALG_ALLOCATES_MEMORY flag and
> allocates the memory needed by the driver, to fulfil a
> request, within the crypto request object.
> The extra size needed for base extended descriptor, hw
> de
42 matches
Mail list logo
