* Re: [PATCH 3/3] arm64: dts: qcom: shikra: Add qcrypto node support
From: Dmitry Baryshkov @ 2026-05-25 10:43 UTC (permalink / raw)
To: Kuldeep Singh
Cc: Konrad Dybcio, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Vinod Koul, Frank Li, Andy Gross, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <8a1d6c78-fd16-4994-bae9-cf75b1e7e3c5@oss.qualcomm.com>
On Mon, May 25, 2026 at 03:39:17PM +0530, Kuldeep Singh wrote:
> >>> These two entries are logically the same (SID & ~mask) as the first two,
> >>> does it still work if you remove them?
> >>
> >> Yes, resulting sid is same for 84/94 and 86/92.
> >> Basically, the resulting sid could be same, it's an optimization which
> >> smmu is doing which can result in same SMR(Stream matching register)
> >> routing 2 different sid to same context bank.
> >> So, 2 sid can be used even though resulting sid remains same.
> >>
> >> Also, DT usually dictates what hw capabilities are supported and hence,
> >> captured all apps entries here to match the hardware description.
> >>
> >> I hope this answers your query.
> >
> > It doesn't. Can we drop them?
>
> Could you please explain more on what's missing?
Usually we don't have duplciate SIDs in DT. Why is it not the case for
this device?
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] crypto: use two-argument strscpy where destination size is known
From: Thorsten Blum @ 2026-05-25 10:30 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Tom Lendacky, John Allen, Weili Qian,
Zhou Wang, Giovanni Cabiddu, Srujana Challa, Bharat Bhushan
Cc: linux-crypto, linux-kernel, qat-linux, Thorsten Blum
To simplify the code, drop explicit and hard-coded size arguments from
strscpy() where the destination buffer has a fixed size and strscpy()
can automatically determine it using sizeof().
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
crypto/api.c | 2 +-
crypto/crypto_user.c | 9 ++++-----
crypto/hctr2.c | 3 +--
crypto/lrw.c | 2 +-
crypto/lskcipher.c | 3 +--
crypto/xts.c | 3 ++-
drivers/crypto/cavium/nitrox/nitrox_hal.c | 3 ++-
drivers/crypto/ccp/ccp-crypto-sha.c | 2 +-
drivers/crypto/hisilicon/qm.c | 5 +----
drivers/crypto/intel/qat/qat_common/adf_cfg.c | 7 ++++---
drivers/crypto/intel/qat/qat_common/adf_cfg_services.c | 2 +-
drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c | 3 ++-
drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c | 3 ++-
.../crypto/intel/qat/qat_common/adf_transport_debug.c | 3 ++-
drivers/crypto/intel/qat/qat_common/qat_compression.c | 3 ++-
drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c | 6 +++---
drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c | 4 ++--
17 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/crypto/api.c b/crypto/api.c
index 74e17d5049c9..040b7a965c2f 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -116,7 +116,7 @@ struct crypto_larval *crypto_larval_alloc(const char *name, u32 type, u32 mask)
larval->alg.cra_priority = -1;
larval->alg.cra_destroy = crypto_larval_destroy;
- strscpy(larval->alg.cra_name, name, CRYPTO_MAX_ALG_NAME);
+ strscpy(larval->alg.cra_name, name);
init_completion(&larval->completion);
return larval;
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index e8b6ae75f31f..d3ccb507153b 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -11,6 +11,7 @@
#include <linux/cryptouser.h>
#include <linux/sched.h>
#include <linux/security.h>
+#include <linux/string.h>
#include <net/netlink.h>
#include <net/net_namespace.h>
#include <net/sock.h>
@@ -87,11 +88,9 @@ static int crypto_report_one(struct crypto_alg *alg,
{
memset(ualg, 0, sizeof(*ualg));
- strscpy(ualg->cru_name, alg->cra_name, sizeof(ualg->cru_name));
- strscpy(ualg->cru_driver_name, alg->cra_driver_name,
- sizeof(ualg->cru_driver_name));
- strscpy(ualg->cru_module_name, module_name(alg->cra_module),
- sizeof(ualg->cru_module_name));
+ strscpy(ualg->cru_name, alg->cra_name);
+ strscpy(ualg->cru_driver_name, alg->cra_driver_name);
+ strscpy(ualg->cru_module_name, module_name(alg->cra_module));
ualg->cru_type = 0;
ualg->cru_mask = 0;
diff --git a/crypto/hctr2.c b/crypto/hctr2.c
index ad5edf9366ac..cfc2343bcc1c 100644
--- a/crypto/hctr2.c
+++ b/crypto/hctr2.c
@@ -354,8 +354,7 @@ static int hctr2_create_common(struct crypto_template *tmpl, struct rtattr **tb,
err = -EINVAL;
if (strncmp(xctr_alg->base.cra_name, "xctr(", 5))
goto err_free_inst;
- len = strscpy(blockcipher_name, xctr_alg->base.cra_name + 5,
- sizeof(blockcipher_name));
+ len = strscpy(blockcipher_name, xctr_alg->base.cra_name + 5);
if (len < 1)
goto err_free_inst;
if (blockcipher_name[len - 1] != ')')
diff --git a/crypto/lrw.c b/crypto/lrw.c
index aa31ab03a597..e306e85d7ced 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -359,7 +359,7 @@ static int lrw_create(struct crypto_template *tmpl, struct rtattr **tb)
if (!memcmp(cipher_name, "ecb(", 4)) {
int len;
- len = strscpy(ecb_name, cipher_name + 4, sizeof(ecb_name));
+ len = strscpy(ecb_name, cipher_name + 4);
if (len < 2)
goto err_free_inst;
diff --git a/crypto/lskcipher.c b/crypto/lskcipher.c
index e4328df6e26c..d7ec215e2b3a 100644
--- a/crypto/lskcipher.c
+++ b/crypto/lskcipher.c
@@ -528,8 +528,7 @@ struct lskcipher_instance *lskcipher_alloc_instance_simple(
int len;
err = -EINVAL;
- len = strscpy(ecb_name, &cipher_alg->co.base.cra_name[4],
- sizeof(ecb_name));
+ len = strscpy(ecb_name, &cipher_alg->co.base.cra_name[4]);
if (len < 2)
goto err_free_inst;
diff --git a/crypto/xts.c b/crypto/xts.c
index ad97c8091582..1dc948745444 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -16,6 +16,7 @@
#include <linux/module.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include <crypto/xts.h>
#include <crypto/b128ops.h>
@@ -400,7 +401,7 @@ static int xts_create(struct crypto_template *tmpl, struct rtattr **tb)
if (!memcmp(cipher_name, "ecb(", 4)) {
int len;
- len = strscpy(name, cipher_name + 4, sizeof(name));
+ len = strscpy(name, cipher_name + 4);
if (len < 2)
goto err_free_inst;
diff --git a/drivers/crypto/cavium/nitrox/nitrox_hal.c b/drivers/crypto/cavium/nitrox/nitrox_hal.c
index 1b5abdb6cc5e..e36c1741bb78 100644
--- a/drivers/crypto/cavium/nitrox/nitrox_hal.c
+++ b/drivers/crypto/cavium/nitrox/nitrox_hal.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/delay.h>
+#include <linux/string.h>
#include "nitrox_dev.h"
#include "nitrox_csr.h"
@@ -647,7 +648,7 @@ void nitrox_get_hwinfo(struct nitrox_device *ndev)
ndev->hw.revision_id);
/* copy partname */
- strscpy(ndev->hw.partname, name, sizeof(ndev->hw.partname));
+ strscpy(ndev->hw.partname, name);
}
void enable_pf2vf_mbox_interrupts(struct nitrox_device *ndev)
diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c b/drivers/crypto/ccp/ccp-crypto-sha.c
index 85058a89f35b..ff9bb253dbb2 100644
--- a/drivers/crypto/ccp/ccp-crypto-sha.c
+++ b/drivers/crypto/ccp/ccp-crypto-sha.c
@@ -426,7 +426,7 @@ static int ccp_register_hmac_alg(struct list_head *head,
*ccp_alg = *base_alg;
INIT_LIST_HEAD(&ccp_alg->entry);
- strscpy(ccp_alg->child_alg, def->name, CRYPTO_MAX_ALG_NAME);
+ strscpy(ccp_alg->child_alg, def->name);
alg = &ccp_alg->alg;
alg->setkey = ccp_sha_setkey;
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index 3ca47e2a9719..0c8cc0d7a82a 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -2870,11 +2870,8 @@ static int qm_alloc_uacce(struct hisi_qm *qm)
.flags = UACCE_DEV_SVA,
.ops = &uacce_qm_ops,
};
- int ret;
- ret = strscpy(interface.name, dev_driver_string(&pdev->dev),
- sizeof(interface.name));
- if (ret < 0)
+ if (strscpy(interface.name, dev_driver_string(&pdev->dev)) < 0)
return -ENAMETOOLONG;
uacce = uacce_alloc(&pdev->dev, &interface);
diff --git a/drivers/crypto/intel/qat/qat_common/adf_cfg.c b/drivers/crypto/intel/qat/qat_common/adf_cfg.c
index c202209f17d5..24c2618af68d 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_cfg.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_cfg.c
@@ -2,6 +2,7 @@
/* Copyright(c) 2014 - 2020 Intel Corporation */
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/list.h>
#include <linux/seq_file.h>
#include "adf_accel_devices.h"
@@ -294,13 +295,13 @@ int adf_cfg_add_key_value_param(struct adf_accel_dev *accel_dev,
return -ENOMEM;
INIT_LIST_HEAD(&key_val->list);
- strscpy(key_val->key, key, sizeof(key_val->key));
+ strscpy(key_val->key, key);
if (type == ADF_DEC) {
snprintf(key_val->val, ADF_CFG_MAX_VAL_LEN_IN_BYTES,
"%ld", (*((long *)val)));
} else if (type == ADF_STR) {
- strscpy(key_val->val, (char *)val, sizeof(key_val->val));
+ strscpy(key_val->val, (char *)val);
} else if (type == ADF_HEX) {
snprintf(key_val->val, ADF_CFG_MAX_VAL_LEN_IN_BYTES,
"0x%lx", (unsigned long)val);
@@ -360,7 +361,7 @@ int adf_cfg_section_add(struct adf_accel_dev *accel_dev, const char *name)
if (!sec)
return -ENOMEM;
- strscpy(sec->name, name, sizeof(sec->name));
+ strscpy(sec->name, name);
INIT_LIST_HEAD(&sec->param_head);
down_write(&cfg->lock);
list_add_tail(&sec->list, &cfg->sec_list);
diff --git a/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c b/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c
index 7d00bcb41ce7..11cba347d12d 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c
@@ -60,7 +60,7 @@ static int adf_service_string_to_mask(struct adf_accel_dev *accel_dev, const cha
if (len > ADF_CFG_MAX_VAL_LEN_IN_BYTES - 1)
return -EINVAL;
- strscpy(services, buf, ADF_CFG_MAX_VAL_LEN_IN_BYTES);
+ strscpy(services, buf);
substr = services;
while ((token = strsep(&substr, ADF_SERVICES_DELIMITER))) {
diff --git a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c b/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
index c2e6f0cb7480..ae10b91da5ba 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
@@ -5,6 +5,7 @@
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/fs.h>
#include <linux/bitops.h>
#include <linux/pci.h>
@@ -350,7 +351,7 @@ static int adf_ctl_ioctl_get_status(struct file *fp, unsigned int cmd,
dev_info.num_logical_accel = hw_data->num_logical_accel;
dev_info.banks_per_accel = hw_data->num_banks
/ hw_data->num_logical_accel;
- strscpy(dev_info.name, hw_data->dev_class->name, sizeof(dev_info.name));
+ strscpy(dev_info.name, hw_data->dev_class->name);
dev_info.instance_id = hw_data->instance_id;
dev_info.type = hw_data->dev_class->type;
dev_info.bus = accel_to_pci_dev(accel_dev)->bus->number;
diff --git a/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c b/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c
index f9017e03ec0f..32aeb795cc03 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_mstate_mgr.c
@@ -2,6 +2,7 @@
/* Copyright(c) 2024 Intel Corporation */
#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/types.h>
#include "adf_mstate_mgr.h"
@@ -158,7 +159,7 @@ static struct adf_mstate_sect_h *adf_mstate_sect_add_header(struct adf_mstate_mg
return NULL;
}
- strscpy(sect->id, id, sizeof(sect->id));
+ strscpy(sect->id, id);
sect->size = 0;
sect->sub_sects = 0;
mgr->state += sizeof(*sect);
diff --git a/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c b/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c
index a8f853516a3f..fc5d88a2bb17 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_transport_debug.c
@@ -2,6 +2,7 @@
/* Copyright(c) 2014 - 2020 Intel Corporation */
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/seq_file.h>
#include "adf_accel_devices.h"
#include "adf_transport_internal.h"
@@ -103,7 +104,7 @@ int adf_ring_debugfs_add(struct adf_etr_ring_data *ring, const char *name)
if (!ring_debug)
return -ENOMEM;
- strscpy(ring_debug->ring_name, name, sizeof(ring_debug->ring_name));
+ strscpy(ring_debug->ring_name, name);
snprintf(entry_name, sizeof(entry_name), "ring_%02d",
ring->ring_number);
diff --git a/drivers/crypto/intel/qat/qat_common/qat_compression.c b/drivers/crypto/intel/qat/qat_common/qat_compression.c
index 1424d7a9bcd3..8129ad0c32d8 100644
--- a/drivers/crypto/intel/qat/qat_common/qat_compression.c
+++ b/drivers/crypto/intel/qat/qat_common/qat_compression.c
@@ -2,6 +2,7 @@
/* Copyright(c) 2022 Intel Corporation */
#include <linux/module.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include "adf_accel_devices.h"
#include "adf_common_drv.h"
#include "adf_transport.h"
@@ -144,7 +145,7 @@ static int qat_compression_create_instances(struct adf_accel_dev *accel_dev)
int i;
INIT_LIST_HEAD(&accel_dev->compression_list);
- strscpy(key, ADF_NUM_DC, sizeof(key));
+ strscpy(key, ADF_NUM_DC);
ret = adf_cfg_get_param_value(accel_dev, SEC, key, val);
if (ret)
return ret;
diff --git a/drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c b/drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c
index e0f38d32bc93..5c3636080757 100644
--- a/drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c
+++ b/drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c
@@ -99,7 +99,7 @@ static int dev_supports_eng_type(struct otx_cpt_eng_grps *eng_grps,
static void set_ucode_filename(struct otx_cpt_ucode *ucode,
const char *filename)
{
- strscpy(ucode->filename, filename, OTX_CPT_UCODE_NAME_LENGTH);
+ strscpy(ucode->filename, filename);
}
static char *get_eng_type_str(int eng_type)
@@ -140,7 +140,7 @@ static int get_ucode_type(struct otx_cpt_ucode_hdr *ucode_hdr, int *ucode_type)
u32 i, val = 0;
u8 nn;
- strscpy(tmp_ver_str, ucode_hdr->ver_str, OTX_CPT_UCODE_VER_STR_SZ);
+ strscpy(tmp_ver_str, ucode_hdr->ver_str);
for (i = 0; i < strlen(tmp_ver_str); i++)
tmp_ver_str[i] = tolower(tmp_ver_str[i]);
@@ -1331,7 +1331,7 @@ static ssize_t ucode_load_store(struct device *dev,
eng_grps = container_of(attr, struct otx_cpt_eng_grps, ucode_load_attr);
err_msg = "Invalid engine group format";
- strscpy(tmp_buf, buf, OTX_CPT_UCODE_NAME_LENGTH);
+ strscpy(tmp_buf, buf);
start = tmp_buf;
has_se = has_ie = has_ae = false;
diff --git a/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c b/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c
index 9b0887d7e62c..465f00e74623 100644
--- a/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c
+++ b/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c
@@ -74,7 +74,7 @@ static int is_2nd_ucode_used(struct otx2_cpt_eng_grp_info *eng_grp)
static void set_ucode_filename(struct otx2_cpt_ucode *ucode,
const char *filename)
{
- strscpy(ucode->filename, filename, OTX2_CPT_NAME_LENGTH);
+ strscpy(ucode->filename, filename);
}
static char *get_eng_type_str(int eng_type)
@@ -130,7 +130,7 @@ static int get_ucode_type(struct device *dev,
int i, val = 0;
u8 nn;
- strscpy(tmp_ver_str, ucode_hdr->ver_str, OTX2_CPT_UCODE_VER_STR_SZ);
+ strscpy(tmp_ver_str, ucode_hdr->ver_str);
for (i = 0; i < strlen(tmp_ver_str); i++)
tmp_ver_str[i] = tolower(tmp_ver_str[i]);
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: qcom: shikra: Add qcrypto node support
From: Kuldeep Singh @ 2026-05-25 10:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Vinod Koul, Frank Li, Andy Gross, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <algvollvttjlu4qpawi3gnhwponwml6pts47ebmcvrjvlryl3a@qjq5ildo4qsm>
>>> These two entries are logically the same (SID & ~mask) as the first two,
>>> does it still work if you remove them?
>>
>> Yes, resulting sid is same for 84/94 and 86/92.
>> Basically, the resulting sid could be same, it's an optimization which
>> smmu is doing which can result in same SMR(Stream matching register)
>> routing 2 different sid to same context bank.
>> So, 2 sid can be used even though resulting sid remains same.
>>
>> Also, DT usually dictates what hw capabilities are supported and hence,
>> captured all apps entries here to match the hardware description.
>>
>> I hope this answers your query.
>
> It doesn't. Can we drop them?
Could you please explain more on what's missing?
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH 0/3] Add support for qcrypto on shikra
From: Dmitry Baryshkov @ 2026-05-25 10:07 UTC (permalink / raw)
To: Eric Biggers
Cc: Kuldeep Singh, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Vinod Koul, Frank Li, Andy Gross, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <20260522024912.GC5937@quark>
On Thu, May 21, 2026 at 09:49:12PM -0500, Eric Biggers wrote:
> On Thu, May 21, 2026 at 12:21:41PM +0530, Kuldeep Singh wrote:
> > On 15-05-2026 01:17, Eric Biggers wrote:
> > > On Fri, May 15, 2026 at 12:53:35AM +0530, Kuldeep Singh wrote:
> > >> Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali.
> > >> Shikra bam dma supports 7 iommus so update dt-bindings accordingly.
> > >>
> > >> The patchset depends on below. There's recursive dependency so referred
> > >> to base DT patch here.
> > >> - https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/
> > >>
> > >> Validations:
> > >> - make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check
> > >> - make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
> > >> - cryptobam and crypto driver probe
> > >> - kcapi test
> > >>
> > >> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> > >
> > > What specific kernel features would this be useful for, and what
> > > specific performance improvements are you seeing with those features?
> >
> > I hope you mean 7 iommu entries.
> >
> > Please note, shikra is an old platform and differs with latest platforms
> > like kaanapali in terms of iommus#.
> > Kaanapali is optimised(in terms of iommus#) as same pipe index/sid i.e
> > 4/5 can be used for general purpose or for any other usecase like
> > DRM/HDCP etc.
> > Whereas for shikra, there's dedicated iommu entry for each usecase and
> > same pipe index/sid cannot be used for other usecases.
> >
> > The performance will be be effectively similar.
>
> It sounds like you don't actually have an answer to my questions, then.
>
> Performance tests (e.g.
> https://lore.kernel.org/r/20250615031807.GA81869@sol/) have clearly
> shown that this driver is an order of magnitude slower than the CPU.
Are other harware crypto drivers faster or slower than the CPU
implementation? What about the CAAM (sorry, it's just the driver that I
worked with few years ago). Or Xilinx? My guess would be that for the
most of the modern ARM64 hardware the NEON implementation is faster than
the "hw IP" one. My assumtion has always been that we support crypto IP
for the sake of security (i.e. making sure that the key can't be found
in the cleartext in memory dumps or that it's impossible to tamper with
the hash values before singing/verification). From this point of view,
using priorities is expected and logical: most of the users will need a
quickest implementation. Some users will need to use protected keys or
other hw-only features.
Note, I'm not commenting on the driver being buggy. If the issues are
not fixed in a timely manner, it should be marked with 'depends on
BROKEN' and further removed if the issues contine to be non-fixed.
> This driver has historically been quite harmful. People were using it
> accidentally and encountering very bad performance, as well as bugs such
> as crashes and filesystem hangs. We fixed that by lowering its
> cra_priority. But for the same reason, even when enabled on a platform,
> it's not actually used. Linux would be better without this driver.
>
> We seem to be seeing the usual drivers/crypto/ pattern here: this crypto
> offload driver is being pushed by the hardware manufacturer, with no
> awareness of the fact that it's actually useless in Linux.
>
> I've had enough of this. Please consider this series:
>
> Nacked-by: Eric Biggers <ebiggers@kernel.org>
>
> FWIW: the approaches that are actually used and work well in Linux are
> ICE and the CPU-accelerated crypto.
>
> - Eric
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] crypto: atmel-tdes - use min3 to simplify sg_copy and crypt_start
From: Thorsten Blum @ 2026-05-25 9:29 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Replace multiple min() and min_t() calls with min3() to simplify the
code. Using min3() instead of min_t() in atmel_tdes_crypt_start() is
safe since the values are all unsigned and compatible.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-tdes.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
index 643e507f9c02..834c6d3e1b06 100644
--- a/drivers/crypto/atmel-tdes.c
+++ b/drivers/crypto/atmel-tdes.c
@@ -143,8 +143,7 @@ static int atmel_tdes_sg_copy(struct scatterlist **sg, size_t *offset,
size_t count, off = 0;
while (buflen && total) {
- count = min((*sg)->length - *offset, total);
- count = min(count, buflen);
+ count = min3((*sg)->length - *offset, total, buflen);
if (!count)
return off;
@@ -469,8 +468,8 @@ static int atmel_tdes_crypt_start(struct atmel_tdes_dev *dd)
if (fast) {
- count = min_t(size_t, dd->total, sg_dma_len(dd->in_sg));
- count = min_t(size_t, count, sg_dma_len(dd->out_sg));
+ count = min3(sg_dma_len(dd->in_sg), sg_dma_len(dd->out_sg),
+ dd->total);
err = dma_map_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
if (!err) {
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: qcom: shikra: Add qcrypto node support
From: Dmitry Baryshkov @ 2026-05-25 8:47 UTC (permalink / raw)
To: Kuldeep Singh
Cc: Konrad Dybcio, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Vinod Koul, Frank Li, Andy Gross, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <57c26520-42dd-4159-bd2a-69874945cbbe@oss.qualcomm.com>
On Thu, May 21, 2026 at 02:15:45PM +0530, Kuldeep Singh wrote:
> On 15-05-2026 15:58, Konrad Dybcio wrote:
> > On 5/14/26 9:23 PM, Kuldeep Singh wrote:
> >> Add qcrypto and cryptobam support for shikra target.
> >>
> >> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> >> ---
> >> arch/arm64/boot/dts/qcom/shikra.dtsi | 35 +++++++++++++++++++++++++++++++++++
> >> 1 file changed, 35 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> >> index 262c488add1e..dbac0e901d6e 100644
> >> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> >> @@ -541,6 +541,41 @@ config_noc: interconnect@1900000 {
> >> #interconnect-cells = <2>;
> >> };
> >>
> >> + cryptobam: dma-controller@1b04000 {
> >> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
> >> + reg = <0x0 0x01b04000 0x0 0x24000>;
> >> + interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
> >> + #dma-cells = <1>;
> >> + iommus = <&apps_smmu 0x84 0x0011>,
> >> + <&apps_smmu 0x86 0x0011>,
> >> + <&apps_smmu 0x92 0x0>,
> >
> >> + <&apps_smmu 0x94 0x0011>,
> >> + <&apps_smmu 0x96 0x0011>,
> >
> > These two entries are logically the same (SID & ~mask) as the first two,
> > does it still work if you remove them?
>
> Yes, resulting sid is same for 84/94 and 86/92.
> Basically, the resulting sid could be same, it's an optimization which
> smmu is doing which can result in same SMR(Stream matching register)
> routing 2 different sid to same context bank.
> So, 2 sid can be used even though resulting sid remains same.
>
> Also, DT usually dictates what hw capabilities are supported and hence,
> captured all apps entries here to match the hardware description.
>
> I hope this answers your query.
It doesn't. Can we drop them?
> >
> >
> >> + <&apps_smmu 0x98 0x0001>,
> >> + <&apps_smmu 0x9F 0x0>;
> >
> > Let's keep lowercase hex
> Sure, will update in next rev.
> Please note, I'll be clubbing patches together in one series as
> suggested by krzysztof and fix this too that time.
>
> --
> Regards
> Kuldeep
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] crypto: loongson - Select CRYPTO_RNG
From: Qunqin Zhao @ 2026-05-25 8:17 UTC (permalink / raw)
To: Eric Biggers
Cc: Huacai Chen, linux-crypto, Herbert Xu, linux-kernel, loongarch,
Yinggang Gu, Lee Jones, kernel test robot, stable
In-Reply-To: <20260525032006.GA243157@quark>
在 2026/5/25 上午11:20, Eric Biggers 写道:
> On Mon, May 25, 2026 at 10:45:14AM +0800, Qunqin Zhao wrote:
>>>> To be honest, I previously assumed that the `hw_random` was designed
>>>> strictly and exclusively for the TRNG mode.
>>>>
>>>> Is it architecturally acceptable or common practice for a PRNG mode to
>>>> utilize `hw_random` as well?
>>>>
>>>> Thanks,
>>> So the Loongson RNG is a PRNG? Where does it get its entropy from, and
>>> what is its security strength?
>> Loongson's hardware supports both TRNG and PRNG simultaneously.
>>
>> We can locate a reseed function within loongson-rng.c, which clearly
>> indicates that it is a PRNG driver.
> That reseed function gets called with entropy from the Linux RNG. So,
> it seems it's really just a PRNG seeded from the Linux RNG. What value
> does that provide over just using the Linux RNG directly?
Alternatively,the reseed function can serve as a stirring mechanism,
where the primary entropy comes from the internal hardware TRNG.
Or simply ignore the entropy from the Linux RNG entirely, trigger a
reseeding internal.
The driver merely forwards the seed to the firmware; how it is utilized
and what kind of random numbers are returned are entirely determined by
the firmware implementation.
>
>> So the core issue here is whether a PRNG driver can utilize the crypto
>> interface.
> If you're asking about crypto_rng, it can. But the crypto_rng interface
> is also kind of useless. If you're asking about hwrng, it does look
> like it's designed for TRNGs. Would it be possible for this driver to
> use the TRNG mode?
I mean crypto_rng.
We might use the hwrng interface to add support for the TRNG in this driver.
>
>> If it cannot, does that imply the drivers listed below serve no practical
>> purpose? (7.1-rc1)
>>
>> loongson@loongson:~/upstream/linux/drivers/crypto$ grep crypto_register_rng
> Most of the drivers in drivers/crypto/ are added by the hardware
> manufacturer without any regard for whether they're useful or not.
If we are dropping crypto-rng drivers entirely,
I am fine with removing the Loongson driver along with the others.
However, targeting the Loongson driver alone is unacceptable.
Thanks,
Qunqin.
>
> - Eric
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Dmitry Baryshkov @ 2026-05-25 8:11 UTC (permalink / raw)
To: Kuldeep Singh
Cc: Eric Biggers, Krzysztof Kozlowski, Demi Marie Obenour, Herbert Xu,
David S. Miller, Thara Gopinath, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Russell King,
linux-kernel, linux-crypto, linux-arm-msm, Ard Biesheuvel,
devicetree, linux-arm-kernel
In-Reply-To: <e36172c6-4424-4b77-9b3c-47dcdbdff05b@oss.qualcomm.com>
On Mon, May 25, 2026 at 11:59:33AM +0530, Kuldeep Singh wrote:
> > This driver is more than an order of magnitude slower than the CPU for
> > both encryption and hashing. See:
> >
> > https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/
> > https://lore.kernel.org/r/20250615031807.GA81869@sol/
> >
> > There are many examples of it having bugs as well, for example see the
> > second link above.
> >
> > That's why it had to be disabled via the cra_priority system. This
> > driver was actively making Linux worse.
> >
> > This isn't particularly unique to drivers/crypto/, of course. This one
> > we just have data on, so it's a bit clearer.
> >
> > I've yet to see any real reason to keep this driver.
>
> https://lore.kernel.org/all/c1697372-54ec-4f57-85d9-ad375ff1a44d@oss.qualcomm.com/
> Kindly check my latest reply to the thread. There are numerous usecases
> like DRM(Digital rights management) coming up and qce driver is required
> for secure content.
>
> > Crypto drivers need to be held to a higher standard than other device
> > drivers, as well. The onus is on those who want to keep a particular
> > crypto driver to prove that it's worth keeping.
> Sure, I'll be working on stabilizing self_tests infra for qce.
> Kindly allow sometime to go over failures in crypto selftest and will
> submit fix if applicable.
Why are not selftests a part of your default config? How are you testing
the driver?
> So far, i am observing 2 ciphers failing(xts-aes-qce and ctr-aes-qce )
> with CONFIG_CRYPTO_SELFTESTS enabled.
Please make sure to run the tests on older platforms too, not just the
latest & greatest.
>
> https://lore.kernel.org/r/20250615031807.GA81869@sol/
> May I know how to issue reproduce steps because I didn't observe
> crypto/ahash.c failure with CONFIG_CRYPTO_SELFTESTS?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] net: Remove support for AIO on sockets
From: Christoph Hellwig @ 2026-05-25 8:03 UTC (permalink / raw)
To: demiobenour
Cc: Herbert Xu, David S. Miller, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, Jens Axboe, Jakub Kicinski,
Simon Horman, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Jonathan Corbet, Shuah Khan, Eric Biggers,
Ard Biesheuvel, linux-crypto, linux-kernel, io-uring, netdev,
linux-perf-users, linux-doc, Toke Høiland-Jørgensen,
linux-api
In-Reply-To: <20260523-af-alg-harden-v1-1-c76755c3a5c5@gmail.com>
On Sat, May 23, 2026 at 03:43:02PM -0400, Demi Marie Obenour via B4 Relay wrote:
> From: Demi Marie Obenour <demiobenour@gmail.com>
>
> The only user of msg->msg_iocb was AF_ALG, but that's deprecated.
> It can be removed entirely at the cost of only supporting synchronous
> operations. This doesn't break userspace, which will silently block
> (for a bounded amount of time) in io_submit instead of operating
> asynchronously.
>
> This also makes struct msghdr smaller, helping every other caller of
> sendmsg().
So we just had a discussion at LLC about how networking needs to support
AIO better for zero copy.
The current TCP zerocopy implementation provides completion notification
through the socket error code, which is freaking weird and doesn't
integrate well with either io_uring or in-kernel callers.
So we really want to pass the iocb down into networking and have it
call ki_complete on completion, with something higher up in the stack
adding that to the error queue for the legacy user interface.
Now I'm not sure if we wouldn't be better off passing that iocb
explicitly instead of in a weird hidden way, but this seemed like
a good place to bring this up.
^ permalink raw reply
* [PATCH v3] crypto: nx: fix nx_crypto_ctx_exit argument
From: Sam James @ 2026-05-25 7:56 UTC (permalink / raw)
To: Breno Leitão, Nayna Jain, Paulo Flabiano Smorigo,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Herbert Xu, David S. Miller,
Ard Biesheuvel, Eric Biggers
Cc: Sam James, Eric Biggers, stable, Calvin Buckley, Brad Spengler,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <b8b1b6fe740187c70349cd04a820d57324e0f70c.1779509289.git.sam@gentoo.org>
nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...)
but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *.
Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx
call.
This fixes the following oops:
BUG: Unable to handle kernel data access at 0xc0403effffffffc8
Faulting instruction address: 0xc000000000396cb4
Oops: Kernel access of bad area, sig: 11 [#15]
Call Trace:
nx_crypto_ctx_shash_exit+0x24/0x60
crypto_shash_exit_tfm+0x28/0x40
crypto_destroy_tfm+0x98/0x140
crypto_exit_ahash_using_shash+0x20/0x40
crypto_destroy_tfm+0x98/0x140
hash_release+0x1c/0x30
alg_sock_destruct+0x38/0x60
__sk_destruct+0x48/0x2b0
af_alg_release+0x58/0xb0
__sock_release+0x68/0x150
sock_close+0x20/0x40
__fput+0x110/0x3a0
sys_close+0x48/0xa0
system_call_exception+0x140/0x2d0
system_call_common+0xf4/0x258
.. which came from hardlink(1) opportunistically using AF_ALG.
The same problem exists with nx_crypto_ctx_skcipher_exit getting a context
it wasn't expecting, but apparently nobody hit that for years.
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: stable@vger.kernel.org
Fixes: bfd9efddf990 ("crypto: nx - convert AES-ECB to skcipher API")
Fixes: 9420e628e7d8 ("crypto: nx - Use API partial block handling")
Acked-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Reported-by: Calvin Buckley <calvin@cmpct.info>
Tested-by: Calvin Buckley <calvin@cmpct.info>
Suggested-by: Brad Spengler <brad.spengler@opensrcsec.com>
Signed-off-by: Sam James <sam@gentoo.org>
---
v3: Fix doc tag.
v2: Add stable cc, fix doc for tfm param.
v1: https://lore.kernel.org/all/a3e89c1e8342ffa415b0d29725a0571a4f355d34.1779472902.git.sam@gentoo.org/
v2: https://lore.kernel.org/all/b8b1b6fe740187c70349cd04a820d57324e0f70c.1779509289.git.sam@gentoo.org/
drivers/crypto/nx/nx.c | 6 ++----
drivers/crypto/nx/nx.h | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index 78135fb13f5c..1b7509e2ce44 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -714,15 +714,13 @@ int nx_crypto_ctx_aes_xcbc_init(struct crypto_shash *tfm)
/**
* nx_crypto_ctx_exit - destroy a crypto api context
*
- * @tfm: the crypto transform pointer for the context
+ * @nx_ctx: the crypto api context
*
* As crypto API contexts are destroyed, this exit hook is called to free the
* memory associated with it.
*/
-void nx_crypto_ctx_exit(struct crypto_tfm *tfm)
+void nx_crypto_ctx_exit(struct nx_crypto_ctx *nx_ctx)
{
- struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(tfm);
-
kfree_sensitive(nx_ctx->kmem);
nx_ctx->csbcpb = NULL;
nx_ctx->csbcpb_aead = NULL;
diff --git a/drivers/crypto/nx/nx.h b/drivers/crypto/nx/nx.h
index 36974f08490a..6dfabfbf8192 100644
--- a/drivers/crypto/nx/nx.h
+++ b/drivers/crypto/nx/nx.h
@@ -153,7 +153,7 @@ int nx_crypto_ctx_aes_ctr_init(struct crypto_skcipher *tfm);
int nx_crypto_ctx_aes_cbc_init(struct crypto_skcipher *tfm);
int nx_crypto_ctx_aes_ecb_init(struct crypto_skcipher *tfm);
int nx_crypto_ctx_sha_init(struct crypto_shash *tfm);
-void nx_crypto_ctx_exit(struct crypto_tfm *tfm);
+void nx_crypto_ctx_exit(struct nx_crypto_ctx *nx_ctx);
void nx_crypto_ctx_skcipher_exit(struct crypto_skcipher *tfm);
void nx_crypto_ctx_aead_exit(struct crypto_aead *tfm);
void nx_crypto_ctx_shash_exit(struct crypto_shash *tfm);
base-commit: 79bd2dded182b1d458b18e62684b7f82ffc682e5
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Demi Marie Obenour @ 2026-05-25 7:49 UTC (permalink / raw)
To: Kuldeep Singh, Eric Biggers, Krzysztof Kozlowski
Cc: Dmitry Baryshkov, Herbert Xu, David S. Miller, Thara Gopinath,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Russell King, linux-kernel, linux-crypto,
linux-arm-msm, Ard Biesheuvel, devicetree, linux-arm-kernel
In-Reply-To: <e36172c6-4424-4b77-9b3c-47dcdbdff05b@oss.qualcomm.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1441 bytes --]
On 5/25/26 02:29, Kuldeep Singh wrote:
>> This driver is more than an order of magnitude slower than the CPU for
>> both encryption and hashing. See:
>>
>> https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/
>> https://lore.kernel.org/r/20250615031807.GA81869@sol/
>>
>> There are many examples of it having bugs as well, for example see the
>> second link above.
>>
>> That's why it had to be disabled via the cra_priority system. This
>> driver was actively making Linux worse.
>>
>> This isn't particularly unique to drivers/crypto/, of course. This one
>> we just have data on, so it's a bit clearer.
>>
>> I've yet to see any real reason to keep this driver.
>
> https://lore.kernel.org/all/c1697372-54ec-4f57-85d9-ad375ff1a44d@oss.qualcomm.com/
> Kindly check my latest reply to the thread. There are numerous usecases
> like DRM(Digital rights management) coming up and qce driver is required
> for secure content.
1. This content is restricted. It's no more secure.
2. General purpose (desktop, laptop) systems won't be able to display
restricted content. To the best of my knowledge, the only Wayland
compositors that support restricted content are Weston and Chromium
OS's compositor.
3. Will this code be useful without out of tree drivers?
4. Does this use the existing crypto APIs or a separate API?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] hw_random/core: fix rng list on registration error
From: Manos Pitsidianakis @ 2026-05-25 7:25 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu
Cc: linux-crypto, linux-kernel, Manos Pitsidianakis
hwrng_register(rng) does the following:
1. Checks if rng has name and read methods set
2. Checks if the name already exists
3. Adds rng to global rng_list
4. May try to set rng to current_rng
If step 4 fails, it returns an error. However, it does not remove the
rng from rng_list, causing a dangling reference which can result in
use-after-free if the caller frees rng, since registration failed.
Add a list_del_init() cleanup step.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
---
drivers/char/hw_random/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aba92d777f72604861b644469032c8f443f1ed50..3015b863412ee17c734eb4ce2feebe78f5049d89 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -604,11 +604,13 @@ int hwrng_register(struct hwrng *rng)
*/
err = set_current_rng(rng);
if (err)
- goto out_unlock;
+ goto out_list_del;
}
}
mutex_unlock(&rng_mutex);
return 0;
+out_list_del:
+ list_del_init(&rng->list);
out_unlock:
mutex_unlock(&rng_mutex);
out:
---
base-commit: 8bc67e4db64aa72732c474b44ea8622062c903f0
change-id: 20260525-hw_random_registration_rng_list-7651b27b76c8
Best regards,
--
Manos Pitsidianakis <manos@pitsidianak.is>
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Kuldeep Singh @ 2026-05-25 6:29 UTC (permalink / raw)
To: Eric Biggers, Krzysztof Kozlowski
Cc: Demi Marie Obenour, Dmitry Baryshkov, Herbert Xu, David S. Miller,
Thara Gopinath, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Russell King, linux-kernel,
linux-crypto, linux-arm-msm, Ard Biesheuvel, devicetree,
linux-arm-kernel
In-Reply-To: <20260524204537.GB110177@quark>
> This driver is more than an order of magnitude slower than the CPU for
> both encryption and hashing. See:
>
> https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/
> https://lore.kernel.org/r/20250615031807.GA81869@sol/
>
> There are many examples of it having bugs as well, for example see the
> second link above.
>
> That's why it had to be disabled via the cra_priority system. This
> driver was actively making Linux worse.
>
> This isn't particularly unique to drivers/crypto/, of course. This one
> we just have data on, so it's a bit clearer.
>
> I've yet to see any real reason to keep this driver.
https://lore.kernel.org/all/c1697372-54ec-4f57-85d9-ad375ff1a44d@oss.qualcomm.com/
Kindly check my latest reply to the thread. There are numerous usecases
like DRM(Digital rights management) coming up and qce driver is required
for secure content.
> Crypto drivers need to be held to a higher standard than other device
> drivers, as well. The onus is on those who want to keep a particular
> crypto driver to prove that it's worth keeping.
Sure, I'll be working on stabilizing self_tests infra for qce.
Kindly allow sometime to go over failures in crypto selftest and will
submit fix if applicable.
So far, i am observing 2 ciphers failing(xts-aes-qce and ctr-aes-qce )
with CONFIG_CRYPTO_SELFTESTS enabled.
https://lore.kernel.org/r/20250615031807.GA81869@sol/
May I know how to issue reproduce steps because I didn't observe
crypto/ahash.c failure with CONFIG_CRYPTO_SELFTESTS?
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v18 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Manivannan Sadhasivam @ 2026-05-25 5:44 UTC (permalink / raw)
To: Eric Biggers
Cc: Bartosz Golaszewski, Vinod Koul, Jonathan Corbet, Thara Gopinath,
Herbert Xu, David S. Miller, Udit Tiwari, Md Sadre Alam,
Dmitry Baryshkov, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260524204921.GC110177@quark>
On Sun, May 24, 2026 at 03:49:21PM -0500, Eric Biggers wrote:
> On Fri, May 22, 2026 at 03:39:53PM +0200, Bartosz Golaszewski wrote:
> > Currently the QCE crypto driver accesses the crypto engine registers
> > directly via CPU. Trust Zone may perform crypto operations simultaneously
> > resulting in a race condition.
>
> So this driver is just critically broken currently? Yet it's still not
> marked as BROKEN?
>
It is currently broken on a subset of platforms supporting multi-EE, not all.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 0/3] Add support for qcrypto on shikra
From: Kuldeep Singh @ 2026-05-25 5:40 UTC (permalink / raw)
To: Eric Biggers
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Vinod Koul, Frank Li, Andy Gross, linux-arm-msm, linux-crypto,
devicetree, linux-kernel, dmaengine, Bartosz Golaszewski,
Bartosz Golaszewski, Gaurav Kashyap, Neeraj Soni
In-Reply-To: <20260522024912.GC5937@quark>
> It sounds like you don't actually have an answer to my questions, then.
>
> Performance tests (e.g.
> https://lore.kernel.org/r/20250615031807.GA81869@sol/) have clearly
> shown that this driver is an order of magnitude slower than the CPU.
>
> This driver has historically been quite harmful. People were using it
> accidentally and encountering very bad performance, as well as bugs such
> as crashes and filesystem hangs. We fixed that by lowering its
> cra_priority. But for the same reason, even when enabled on a platform,
> it's not actually used. Linux would be better without this driver.
>
+Bartosz, Gaurav, Neeraj
Hi Eric,
GPCE is relevant in terms of providing hardware security.
There are multiple usecases coming up for example to handle DRM/secure
buffer usecases to improve overall throughput for secure content.
Regarding performance, it's currently slower compared to arm CE but
provides an edge by giving hardware security which is considered more
secure.
Btw, there's been performance improvement with new targets and we are
expecting to achieve far more better performance with new SoCs family.
Pakala: GPCE - 550MBps, ARMv8 - 8GBps
Kaanapali: GPCE - 3GBps, ARMv8 - 10GBps
Please note, there's almost 5x improvement in kaanapali compared to
pakala. Though overall is still slower compared to arm but as mentioned,
expecting better performance with hardware improvements as we progress.
Also, currently qce driver exhibit stability issues and that's what we
are putting effort in stabilizing the software on immediate basis.
There's parallel effort ongoing by Bartosz to introduce baseline for
secure buffer usecases.
https://lore.kernel.org/lkml/20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com/
There's active development ongoing and i believe lowering cra_priority
for qce is fine as of now and can scale values once qce becomes
performance efficient.
Please share your thoughts. Thanks!
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH] crypto: loongson - Select CRYPTO_RNG
From: Eric Biggers @ 2026-05-25 3:20 UTC (permalink / raw)
To: Qunqin Zhao
Cc: Huacai Chen, linux-crypto, Herbert Xu, linux-kernel, loongarch,
Yinggang Gu, Lee Jones, kernel test robot, stable
In-Reply-To: <4501444d-9c17-8d4b-8bfd-bd1d69d77a76@loongson.cn>
On Mon, May 25, 2026 at 10:45:14AM +0800, Qunqin Zhao wrote:
> > > To be honest, I previously assumed that the `hw_random` was designed
> > > strictly and exclusively for the TRNG mode.
> > >
> > > Is it architecturally acceptable or common practice for a PRNG mode to
> > > utilize `hw_random` as well?
> > >
> > > Thanks,
> > So the Loongson RNG is a PRNG? Where does it get its entropy from, and
> > what is its security strength?
>
> Loongson's hardware supports both TRNG and PRNG simultaneously.
>
> We can locate a reseed function within loongson-rng.c, which clearly
> indicates that it is a PRNG driver.
That reseed function gets called with entropy from the Linux RNG. So,
it seems it's really just a PRNG seeded from the Linux RNG. What value
does that provide over just using the Linux RNG directly?
> So the core issue here is whether a PRNG driver can utilize the crypto
> interface.
If you're asking about crypto_rng, it can. But the crypto_rng interface
is also kind of useless. If you're asking about hwrng, it does look
like it's designed for TRNGs. Would it be possible for this driver to
use the TRNG mode?
> If it cannot, does that imply the drivers listed below serve no practical
> purpose? (7.1-rc1)
>
> loongson@loongson:~/upstream/linux/drivers/crypto$ grep crypto_register_rng
Most of the drivers in drivers/crypto/ are added by the hardware
manufacturer without any regard for whether they're useful or not.
- Eric
^ permalink raw reply
* Re: [PATCH] crypto: loongson - Select CRYPTO_RNG
From: Qunqin Zhao @ 2026-05-25 2:45 UTC (permalink / raw)
To: Eric Biggers
Cc: Huacai Chen, linux-crypto, Herbert Xu, linux-kernel, loongarch,
Yinggang Gu, Lee Jones, kernel test robot, stable
In-Reply-To: <20260522174835.GA1894319@google.com>
在 2026/5/23 上午1:48, Eric Biggers 写道:
> On Fri, May 22, 2026 at 02:40:38PM +0800, Qunqin Zhao wrote:
>> 在 2026/5/22 下午12:03, Eric Biggers 写道:
>>> On Fri, May 22, 2026 at 11:41:15AM +0800, Qunqin Zhao wrote:
>>>> 在 2026/5/22 上午10:57, Eric Biggers 写道:
>>>>> On Fri, May 22, 2026 at 10:52:42AM +0800, Huacai Chen wrote:
>>>>>> On Fri, May 22, 2026 at 10:26 AM Eric Biggers <ebiggers@kernel.org> wrote:
>>>>>>> This driver registers a rng_alg, so it requires CRYPTO_RNG.
>>>>>>>
>>>>>>> Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")
>>>>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>>>>> Closes: https://lore.kernel.org/oe-kbuild-all/202605201622.qWOiiZTV-lkp@intel.com/
>>>>>>> Cc: stable@vger.kernel.org
>>>>>>> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
>>>>>> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
>>>>>>> ---
>>>>>>> drivers/crypto/loongson/Kconfig | 1 +
>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>
>>>>> By the way, do any of the loongson people have any comment on what they
>>>>> think the point of this driver is? It's not registered with the actual
>>>> To provide an AF_ALG-based random number generation interface for other
>>>> modules and user-space programs.
>>>>
>>>> Thanks,
>>>>
>>>> Qunqin
>>> AF_ALG is a userspace interface; it's not available for in-kernel use.
>>> If you mean using crypto_rng directly, note that no kernel code actually
>>> uses it other than the tests, the implementation of AF_ALG, and the
>>> FIPS-specific code which uses drbg.c specifically.
>>>
>>> So, the first half of your justification doesn't make any sense.
>>>
>>> As far as the second half: why would a userspace program do that instead
>>> of just using the regular Linux RNG (/dev/urandom)?
> Could you answer this question? If there's no answer to this question,
> then there's no use case for this driver as-is.
While I'm not an expert on the specific application scenarios for these,
I believe any PRNG driver should utilize the crypto_rng subsystem.
>>> AFAIK, the only reason to use a HW RNG directly is for certification
>>> reasons.
>>>
>>> However, there's also already an interface for that: /dev/hw_random.
>>>
>>> So AF_ALG seems completely redundant for this case.
>> To be honest, I previously assumed that the `hw_random` was designed
>> strictly and exclusively for the TRNG mode.
>>
>> Is it architecturally acceptable or common practice for a PRNG mode to
>> utilize `hw_random` as well?
>>
>> Thanks,
> So the Loongson RNG is a PRNG? Where does it get its entropy from, and
> what is its security strength?
Loongson's hardware supports both TRNG and PRNG simultaneously.
We can locate a reseed function within loongson-rng.c, which clearly
indicates that it is a PRNG driver.
So the core issue here is whether a PRNG driver can utilize the crypto
interface.
If it cannot, does that imply the drivers listed below serve no
practical purpose? (7.1-rc1)
loongson@loongson:~/upstream/linux/drivers/crypto$ grep
crypto_register_rng -r *
allwinner/sun8i-ss/sun8i-ss-core.c: err =
crypto_register_rng(&ss_algs[i].alg.rng);
allwinner/sun8i-ce/sun8i-ce-core.c: err =
crypto_register_rng(&ce_algs[i].alg.rng);
allwinner/sun4i-ss/sun4i-ss-core.c: err =
crypto_register_rng(&ss_algs[i].alg.rng);
amcc/crypto4xx_core.c: rc = crypto_register_rng(&alg->alg.u.rng);
caam/caamprng.c: ret = crypto_register_rng(&caam_prng_alg.rng);
exynos-rng.c: ret = crypto_register_rng(&exynos_rng_alg);
hisilicon/trng/trng.c: ret = crypto_register_rng(&hisi_trng_alg);
loongson/loongson-rng.c: ret =
crypto_register_rng(&loongson_rng_alg);
qcom-rng.c: ret = crypto_register_rng(&qcom_rng_alg);
xilinx/xilinx-trng.c: ret = crypto_register_rng(&xtrng_trng_alg);
Thanks,
Qunqin
>
> - Eric
^ permalink raw reply
* Re: [PATCH v8 0/3]
From: Jarkko Sakkinen @ 2026-05-24 23:43 UTC (permalink / raw)
To: keyrings
Cc: David Howells, linux-crypto, linux-integrity, David Woodhouse,
James Bottomley, Stefan Berger, Herbert Xu, Mimi Zohar,
Paul Moore, James Morris, Serge E. Hallyn,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <20260524051519.3708075-1-jarkko@kernel.org>
On Sun, May 24, 2026 at 08:15:11AM +0300, Jarkko Sakkinen wrote:
> This series introduces key type for operating with asymmetric keys using
> a TPM2 chip.
This would deserve more explanation but the original trait was to
implement TPM2 parts of:
https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/00/
What motivated me to reiterate are actually these coding agents and how
all secrets are sprayed across the home directory. So, besides iwd one
could use this feature to provide per-session cryptography for coding
agents.
There's a lot to do with security and coding agents as we have literally
moved to an era where we host indeterministically rogues software in our
development workstations.
There's other questions too that we need to eventually answer like for
instace, how to deal with persistent agent memory stored at the
computer's hard drive?
The irony here is that LLM is really neither rogue nor a lier. It is
just a text predictor optimizing for maximum reward and those
descriptions are just human interpretations of the output text. It
understand neither evil, lying nor quality for that matter ;-)
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v8 0/3]
From: Jarkko Sakkinen @ 2026-05-24 23:18 UTC (permalink / raw)
To: keyrings
Cc: David Howells, linux-crypto, linux-integrity, David Woodhouse,
James Bottomley, Stefan Berger, Herbert Xu, Mimi Zohar,
Paul Moore, James Morris, Serge E. Hallyn,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <20260524051519.3708075-1-jarkko@kernel.org>
On Sun, May 24, 2026 at 08:15:11AM +0300, Jarkko Sakkinen wrote:
> This series introduces key type for operating with asymmetric keys using
> a TPM2 chip.
>
> Change Log
> ==========
>
> v8:
> - Reset patch change logs given the overhaul of the code and patches.
> - Have only single new subkey type.
> - Make key type only use TPM operations.
> - Use TPM2_Sign for both ECC and RSA keys.
> - Align key descriptions with other key types.
>
> Previous versions
> =================
>
> * v7: https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
> * v6: https://lore.kernel.org/linux-integrity/20240528035136.11464-1-jarkko@kernel.org/
> * v5: https://lore.kernel.org/linux-integrity/20240523212515.4875-1-jarkko@kernel.org/
> * v4: https://lore.kernel.org/linux-integrity/20240522005252.17841-1-jarkko@kernel.org/
> * v3: https://lore.kernel.org/linux-integrity/20240521152659.26438-1-jarkko@kernel.org/
> * v2: https://lore.kernel.org/linux-integrity/336755.1716327854@warthog.procyon.org.uk/
> * v1: https://lore.kernel.org/linux-integrity/20240520184727.22038-1-jarkko@kernel.org/
> * Derived from https://lore.kernel.org/all/20200518172704.29608-1-prestwoj@gmail.com/
>
>
> Jarkko Sakkinen (3):
> lib/asn1_encoder: Add asn1_encode_integer_bytes()
> crypto: Migrate TPMKey ASN.1 objects from trusted-keys
> keys: asymmetric: tpm2_asymmetric
>
> crypto/Kconfig | 7 +
> crypto/Makefile | 6 +
> crypto/asymmetric_keys/Kconfig | 17 +
> crypto/asymmetric_keys/Makefile | 1 +
> crypto/asymmetric_keys/tpm2_asymmetric.c | 1096 +++++++++++++++++++++
> crypto/tpm2_key.asn1 | 11 +
> crypto/tpm2_key.c | 150 +++
> include/crypto/tpm2_key.h | 46 +
> include/linux/asn1_encoder.h | 3 +
> include/linux/tpm.h | 10 +
> lib/asn1_encoder.c | 62 ++
> security/keys/trusted-keys/Kconfig | 2 +-
> security/keys/trusted-keys/Makefile | 2 -
> security/keys/trusted-keys/tpm2key.asn1 | 11 -
> security/keys/trusted-keys/trusted_tpm2.c | 119 +--
> 15 files changed, 1421 insertions(+), 122 deletions(-)
> create mode 100644 crypto/asymmetric_keys/tpm2_asymmetric.c
> create mode 100644 crypto/tpm2_key.asn1
> create mode 100644 crypto/tpm2_key.c
> create mode 100644 include/crypto/tpm2_key.h
> delete mode 100644 security/keys/trusted-keys/tpm2key.asn1
>
> --
> 2.47.3
>
Oops, I deleted the subject line, it was unintentional :-)
BR, Jarkko
^ permalink raw reply
* Re: [PATCH 1/6] crypto: eip93: return IRQ request errors from probe
From: Jihong Min @ 2026-05-24 21:49 UTC (permalink / raw)
To: Aleksander Jan Bajkowski, Jihong Min, Herbert Xu, linux-crypto
Cc: Christian Marangi, Antoine Tenart, David S . Miller,
Richard van Schagen, linux-kernel, Benjamin Larsson,
Mieczyslaw Nalewaj
In-Reply-To: <ddb3ad67-5125-457a-b033-8804f08b4439@wp.pl>
On 5/25/26 06:09, Aleksander Jan Bajkowski wrote:
> Hi Jihjong,
> I sent same patch a few days ago. You can find it on Patchwork[1].
>
> 1. https://patchwork.kernel.org/project/linux-crypto/
> patch/20260518212506.292170-1-olek2@wp.pl/
> Best regards,
> Aleksander
>
Hi Aleksander,
I missed that patch. Thanks for pointing it out.
I will drop this one from my next submission.
Sincerely,
Jihong Min
> On 24/05/2026 21:45, Jihong Min wrote:
>> devm_request_threaded_irq() can fail, but eip93_crypto_probe()
>> continues as if the interrupt handler was installed. Return the error
>> immediately so the driver does not register algorithms for a device that
>> cannot signal completions.
>>
>> Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel
>> EIP-93 crypto engine support")
>> Originally-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
>> Assisted-by: Codex:gpt-5.5
>> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
>> ---
>> drivers/crypto/inside-secure/eip93/eip93-main.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/crypto/inside-secure/eip93/eip93-main.c b/
>> drivers/crypto/inside-secure/eip93/eip93-main.c
>> index 7dccfdeb7b11..276839e1a515 100644
>> --- a/drivers/crypto/inside-secure/eip93/eip93-main.c
>> +++ b/drivers/crypto/inside-secure/eip93/eip93-main.c
>> @@ -433,6 +433,8 @@ static int eip93_crypto_probe(struct
>> platform_device *pdev)
>> ret = devm_request_threaded_irq(eip93->dev, eip93->irq,
>> eip93_irq_handler,
>> NULL, IRQF_ONESHOT,
>> dev_name(eip93->dev), eip93);
>> + if (ret)
>> + return ret;
>> eip93->ring = devm_kcalloc(eip93->dev, 1, sizeof(*eip93-
>> >ring), GFP_KERNEL);
>> if (!eip93->ring)
^ permalink raw reply
* Re: [PATCH 6/6] crypto: eip93: handle request ID exhaustion
From: Jihong Min @ 2026-05-24 21:47 UTC (permalink / raw)
To: Aleksander Jan Bajkowski, Herbert Xu, linux-crypto
Cc: Christian Marangi, Antoine Tenart, David S . Miller,
Richard van Schagen, linux-kernel, Benjamin Larsson,
Mieczyslaw Nalewaj
In-Reply-To: <e2242046-f08c-4903-a2ea-f21d3bb241cd@wp.pl>
Hi Aleksander,
On 5/25/26 06:30, Aleksander Jan Bajkowski wrote:
> Hi Jihong,
>
> On 24/05/2026 21:45, Jihong Min wrote:
>> diff --git a/drivers/crypto/inside-secure/eip93/eip93-main.h b/drivers/crypto/inside-secure/eip93/eip93-main.h
>> index 990c2401b7ce..5237b75bba62 100644
>> --- a/drivers/crypto/inside-secure/eip93/eip93-main.h
>> +++ b/drivers/crypto/inside-secure/eip93/eip93-main.h
>> @@ -13,11 +13,13 @@
>> #include <crypto/internal/skcipher.h>
>> #include <linux/bitfield.h>
>> #include <linux/interrupt.h>
>> +#include <linux/limits.h>
>>
>> #define EIP93_RING_BUSY_DELAY 500
>>
>> #define EIP93_RING_NUM 512
>> #define EIP93_RING_BUSY 32
>> +#define EIP93_REQUEST_IDR_LIMIT (U16_MAX + 1)
>
> This looks suspicious. You are now overflowing the 16-bit field
> EIP93_PE_USER_ID_CRYPTO_IDR. Did you mean (U16_MAX - 1)? Best regards,
> Aleksander
>
U16_MAX + 1 is intentional here because it is passed to idr_alloc() as
the exclusive end value, not stored in EIP93_PE_USER_ID_CRYPTO_IDR.
So this allocates IDs 0..U16_MAX inclusive, and the value 0x10000 is
never written to the 16-bit descriptor field.
That said, the name is confusing. I will rename it to something like
EIP93_REQUEST_IDR_END and add a short comment if you prefer.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: powerpc: update VMX AES entries
From: Eric Biggers @ 2026-05-24 21:35 UTC (permalink / raw)
To: Thorsten Blum
Cc: Herbert Xu, David S. Miller, Breno Leitão, Nayna Jain,
Paulo Flabiano Smorigo, Ard Biesheuvel, linux-crypto,
linuxppc-dev, linux-kernel
In-Reply-To: <20260524212943.799757-3-thorsten.blum@linux.dev>
On Sun, May 24, 2026 at 11:29:45PM +0200, Thorsten Blum wrote:
> Commit 7cf2082e74ce ("lib/crypto: powerpc/aes: Migrate POWER8 optimized
> code into library") removed arch/powerpc/crypto/aes.c and moved
> arch/powerpc/crypto/aesp8-ppc.pl to lib/crypto/powerpc/.
>
> However, the "IBM Power VMX Cryptographic instructions" entry still
> references the removed file and no longer covers the moved aesp8-ppc.pl.
>
> Remove the stale entry, add lib/crypto/powerpc/aesp8-ppc.pl, and tighten
> the arch/powerpc/crypto/aesp8-ppc.* pattern to match the remaining
> header only.
>
> Fixes: 7cf2082e74ce ("lib/crypto: powerpc/aes: Migrate POWER8 optimized code into library")
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Acked-by: Eric Biggers <ebiggers@kernel.org>
If this doesn't get picked up through the powerpc tree, I can take this
through libcrypto-next.
- Eric
^ permalink raw reply
* [PATCH] MAINTAINERS: powerpc: update VMX AES entries
From: Thorsten Blum @ 2026-05-24 21:29 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Breno Leitão, Nayna Jain,
Paulo Flabiano Smorigo, Eric Biggers, Ard Biesheuvel
Cc: linux-crypto, linuxppc-dev, linux-kernel, Thorsten Blum
Commit 7cf2082e74ce ("lib/crypto: powerpc/aes: Migrate POWER8 optimized
code into library") removed arch/powerpc/crypto/aes.c and moved
arch/powerpc/crypto/aesp8-ppc.pl to lib/crypto/powerpc/.
However, the "IBM Power VMX Cryptographic instructions" entry still
references the removed file and no longer covers the moved aesp8-ppc.pl.
Remove the stale entry, add lib/crypto/powerpc/aesp8-ppc.pl, and tighten
the arch/powerpc/crypto/aesp8-ppc.* pattern to match the remaining
header only.
Fixes: 7cf2082e74ce ("lib/crypto: powerpc/aes: Migrate POWER8 optimized code into library")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b539be153f6a..c48cdb05e6dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12349,13 +12349,13 @@ L: linux-crypto@vger.kernel.org
S: Supported
F: arch/powerpc/crypto/Kconfig
F: arch/powerpc/crypto/Makefile
-F: arch/powerpc/crypto/aes.c
F: arch/powerpc/crypto/aes_cbc.c
F: arch/powerpc/crypto/aes_ctr.c
F: arch/powerpc/crypto/aes_xts.c
-F: arch/powerpc/crypto/aesp8-ppc.*
+F: arch/powerpc/crypto/aesp8-ppc.h
F: arch/powerpc/crypto/ppc-xlate.pl
F: arch/powerpc/crypto/vmx.c
+F: lib/crypto/powerpc/aesp8-ppc.pl
F: lib/crypto/powerpc/gf128hash.h
F: lib/crypto/powerpc/ghashp8-ppc.pl
^ permalink raw reply related
* Re: [PATCH 1/6] crypto: eip93: return IRQ request errors from probe
From: Aleksander Jan Bajkowski @ 2026-05-24 21:09 UTC (permalink / raw)
To: Jihong Min, Herbert Xu, linux-crypto
Cc: Christian Marangi, Antoine Tenart, David S . Miller,
Richard van Schagen, linux-kernel, Benjamin Larsson,
Mieczyslaw Nalewaj
In-Reply-To: <20260524194528.3666383-2-hurryman2212@gmail.com>
Hi Jihjong,
I sent same patch a few days ago. You can find it on Patchwork[1].
1.
https://patchwork.kernel.org/project/linux-crypto/patch/20260518212506.292170-1-olek2@wp.pl/
Best regards,
Aleksander
On 24/05/2026 21:45, Jihong Min wrote:
> devm_request_threaded_irq() can fail, but eip93_crypto_probe()
> continues as if the interrupt handler was installed. Return the error
> immediately so the driver does not register algorithms for a device that
> cannot signal completions.
>
> Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support")
> Originally-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
> ---
> drivers/crypto/inside-secure/eip93/eip93-main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/crypto/inside-secure/eip93/eip93-main.c b/drivers/crypto/inside-secure/eip93/eip93-main.c
> index 7dccfdeb7b11..276839e1a515 100644
> --- a/drivers/crypto/inside-secure/eip93/eip93-main.c
> +++ b/drivers/crypto/inside-secure/eip93/eip93-main.c
> @@ -433,6 +433,8 @@ static int eip93_crypto_probe(struct platform_device *pdev)
> ret = devm_request_threaded_irq(eip93->dev, eip93->irq, eip93_irq_handler,
> NULL, IRQF_ONESHOT,
> dev_name(eip93->dev), eip93);
> + if (ret)
> + return ret;
>
> eip93->ring = devm_kcalloc(eip93->dev, 1, sizeof(*eip93->ring), GFP_KERNEL);
> if (!eip93->ring)
^ permalink raw reply
* Re: [PATCH v18 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Eric Biggers @ 2026-05-24 20:49 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com>
On Fri, May 22, 2026 at 03:39:53PM +0200, Bartosz Golaszewski wrote:
> Currently the QCE crypto driver accesses the crypto engine registers
> directly via CPU. Trust Zone may perform crypto operations simultaneously
> resulting in a race condition.
So this driver is just critically broken currently? Yet it's still not
marked as BROKEN?
What are we even doing?
- Eric
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox