* Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Tom Lendacky @ 2026-05-21 13:12 UTC (permalink / raw)
To: Pratik R. Sampat, ashish.kalra, john.allen, herbert, davem
Cc: linux-crypto, linux-kernel, aik, tycho, nikunj, michael.roth
In-Reply-To: <4ccf6dc7-88e6-488c-8314-5bcd95164661@amd.com>
On 5/20/26 21:10, Pratik R. Sampat wrote:
> Hi Tom,
>
> On 5/20/26 4:22 PM, Tom Lendacky wrote:
>> On 5/19/26 14:50, Pratik R. Sampat wrote:
>>> The SEV-SNP firmware provides the SNP_VERIFY_MITIGATION command, which
>>> can be used to query the status of currently supported vulnerability
>>> mitigations and to initiate mitigations within the firmware.
>>>
>>> This command is an explicit mechanism to ascertain if a firmware
>>> mitigation is applied without needing a full RMP re-build, which is most
>>> useful in a live firmware update scenario.
>>>
>>> The firmware supports two subcommands: STATUS and VERIFY. The STATUS
>>> subcommand is used to query the supported and verified mitigation bits.
>>> The VERIFY subcommand initiates the mitigation process within the FW for
>>> the specified vulnerability. Expose a userspace interface under:
>>> /sys/firmware/sev/vulnerabilities/
>>> - supported_mitigations (read-only): supported mitigation vector mask
>>> - verified_mitigations (read/write): current verified mask; write a
>>> vector to request VERIFY for that bit
>>>
>>> The behavior of SNP_VERIFY_MITIGATION and the pre-requisites for using
>>> it are bug-specific. Information about supported mitigations and its
>>> corresponding vector is to be published as part of the AMD Security
>>> Bulletin.
>>>
>>> See SEV-SNP Firmware ABI specifications 1.58, SNP_VERIFY_MITIGATION for
>>> more details.
>>>
>>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
>>> ---
>>> .../sysfs-firmware-sev-vulnerabilities | 17 ++
>>> drivers/crypto/ccp/sev-dev.c | 172 ++++++++++++++++++
>>> drivers/crypto/ccp/sev-dev.h | 3 +
>>> include/linux/psp-sev.h | 51 ++++++
>>> 4 files changed, 243 insertions(+)
>>> create mode 100644 Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>>> new file mode 100644
>>> index 000000000000..cc84adbac3c0
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>>> @@ -0,0 +1,17 @@
>>> +What: /sys/firmware/sev/vulnerabilities/
>>> + /sys/firmware/sev/vulnerabilities/supported_mitigations
>>> + /sys/firmware/sev/vulnerabilities/verified_mitigations
>>> +Date: May 2026
>>> +Contact: linux-crypto@vger.kernel.org
>>> +Description: Information about SEV-SNP firmware vulnerability mitigations.
>>> + supported_mitigations: Read-only interface that reports
>>> + the vector of mitigations supported by
>>> + the firmware.
>>> + verified_mitigations: Read/write interface that reports
>>> + the vector of mitigations already verified
>>> + by the firmware. Writing a vector value
>>> + requests the firmware to VERIFY the
>>> + corresponding mitigation bit(s).
>>> + The list of supported mitigations and the meaning of each
>>> + vector bit are both platform- and bug-specific and are
>>> + published as part of the AMD Security Bulletin.
>>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>>> index d1e9e0ac63b6..eec4864c6597 100644
>>> --- a/drivers/crypto/ccp/sev-dev.c
>>> +++ b/drivers/crypto/ccp/sev-dev.c
>>> @@ -57,6 +57,7 @@
>>> #define CMD_BUF_DESC_MAX (CMD_BUF_FW_WRITABLE_MAX + 1)
>>>
>>> static DEFINE_MUTEX(sev_cmd_mutex);
>>> +static DEFINE_MUTEX(sev_mit_sysfs_mutex);
>>> static struct sev_misc_dev *misc_dev;
>>>
>>> static int psp_cmd_timeout = 100;
>>> @@ -245,6 +246,7 @@ static int sev_cmd_buffer_len(int cmd)
>>> case SEV_CMD_SNP_LAUNCH_FINISH: return sizeof(struct sev_data_snp_launch_finish);
>>> case SEV_CMD_SNP_DBG_DECRYPT: return sizeof(struct sev_data_snp_dbg);
>>> case SEV_CMD_SNP_DBG_ENCRYPT: return sizeof(struct sev_data_snp_dbg);
>>> + case SEV_CMD_SNP_VERIFY_MITIGATION: return sizeof(struct sev_data_snp_verify_mitigation);
>>> case SEV_CMD_SNP_PAGE_UNSMASH: return sizeof(struct sev_data_snp_page_unsmash);
>>> case SEV_CMD_SNP_PLATFORM_STATUS: return sizeof(struct sev_data_snp_addr);
>>> case SEV_CMD_SNP_GUEST_REQUEST: return sizeof(struct sev_data_snp_guest_request);
>>> @@ -1351,6 +1353,162 @@ static int snp_filter_reserved_mem_regions(struct resource *rs, void *arg)
>>> return 0;
>>> }
>>>
>>> +static int snp_verify_mitigation(u16 command, u64 vector,
>>> + struct sev_data_snp_verify_mitigation_dst *dst)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst *mit_dst = NULL;
>>> + struct sev_data_snp_verify_mitigation data = {0};
>>> + struct sev_device *sev = psp_master->sev_data;
>>> + int ret, error = 0;
>>> +
>>> + mit_dst = snp_alloc_firmware_page(GFP_KERNEL | __GFP_ZERO);
>>> + if (!mit_dst)
>>> + return -ENOMEM;
>>> +
>>> + data.length = sizeof(data);
>>> + data.subcommand = command;
>>> + data.vector = vector;
>>> + data.dst_paddr = __psp_pa(mit_dst);
>>> + data.dst_paddr_en = true;
>>> +
>>> + ret = sev_do_cmd(SEV_CMD_SNP_VERIFY_MITIGATION, &data, &error);
>>> + if (!ret)
>>> + memcpy(dst, mit_dst, sizeof(*mit_dst));
>>> + else
>>> + dev_err(sev->dev, "SNP_VERIFY_MITIGATION command failed, ret = %d, error = %#x\n",
>>> + ret, error);
>>> +
>>> + snp_free_firmware_page(mit_dst);
>>> +
>>> + return ret;
>>> +}
>>
>> Should this function also be under the CONFIG_SYSFS #ifdef? Won't you get
>> an unused function warning if CONFIG_SYSFS isn't defined?
>
> That's right. Thanks for spotting that!
>
>>
>>> +
>>> +#ifdef CONFIG_SYSFS
>>> +static ssize_t supported_mitigations_show(struct kobject *kobj,
>>> + struct kobj_attribute *attr, char *buf)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst dst;
>>> + int ret;
>>> +
>>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return sysfs_emit(buf, "0x%llx\n", dst.mit_supported_vector);
>>> +}
>>> +
>>> +static struct kobj_attribute supported_attr =
>>> + __ATTR_RO_MODE(supported_mitigations, 0400);
>>> +
>>> +static ssize_t verified_mitigations_show(struct kobject *kobj,
>>> + struct kobj_attribute *attr, char *buf)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst dst;
>>> + int ret;
>>> +
>>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return sysfs_emit(buf, "0x%llx\n", dst.mit_verified_vector);
>>> +}
>>> +
>>> +static ssize_t verified_mitigations_store(struct kobject *kobj,
>>> + struct kobj_attribute *attr,
>>> + const char *buf, size_t count)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst dst;
>>> + struct sev_device *sev = psp_master->sev_data;
>>> + u64 vector;
>>> + int ret;
>>> +
>>> + ret = kstrtoull(buf, 0, &vector);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_VERIFY, vector, &dst);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (dst.mit_failure_status) {
>>> + dev_err(sev->dev, "Verify Mitigation - failure status: 0x%x\n",
>>> + dst.mit_failure_status);
>>> + return -EIO;
>>> + }
>>> +
>>> + return count;
>>> +}
>>> +
>>> +static struct kobj_attribute verified_attr =
>>> + __ATTR_RW_MODE(verified_mitigations, 0600);
>>> +
>>> +static struct attribute *mitigation_attrs[] = {
>>> + &supported_attr.attr,
>>> + &verified_attr.attr,
>>> + NULL
>>> +};
>>> +
>>> +static const struct attribute_group mit_attr_group = {
>>> + .attrs = mitigation_attrs,
>>> +};
>>> +
>>> +static void sev_snp_register_verify_mitigation(struct sev_device *sev)
>>> +{
>>> + int rc;
>>> +
>>> + if (!sev->snp_initialized || !sev->snp_plat_status.feature_info ||
>>> + !(sev->snp_feat_info_0.ecx & SNP_VERIFY_MITIGATION_SUPPORTED))
>>> + return;
>>> +
>>> + guard(mutex)(&sev_mit_sysfs_mutex);
>>> +
>>> + if (sev->verify_mit)
>>> + return;
>>> +
>>> + if (!sev->sev_kobj) {
>>> + sev->sev_kobj = kobject_create_and_add("sev", firmware_kobj);
>>> + if (!sev->sev_kobj)
>>> + return;
>>> + }
>>> +
>>> + sev->verify_mit = kobject_create_and_add("vulnerabilities", sev->sev_kobj);
>>> + if (!sev->verify_mit)
>>> + goto err_sev_kobj;
>>> +
>>> + rc = sysfs_create_group(sev->verify_mit, &mit_attr_group);
>>> + if (rc)
>>> + goto err_verify_mit;
>>> +
>>> + return;
>>> +
>>> +err_verify_mit:
>>> + kobject_put(sev->verify_mit);
>>> + sev->verify_mit = NULL;
>>> +err_sev_kobj:
>>> + kobject_put(sev->sev_kobj);
>>> + sev->sev_kobj = NULL;
>>> +}
>>> +
>>> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev)
>>> +{
>>> + guard(mutex)(&sev_mit_sysfs_mutex);
>>> +
>>> + if (sev->verify_mit) {
>>> + sysfs_remove_group(sev->verify_mit, &mit_attr_group);
>>> + kobject_put(sev->verify_mit);
>>> + sev->verify_mit = NULL;
>>> + }
>>> +
>>> + if (sev->sev_kobj) {
>>> + kobject_put(sev->sev_kobj);
>>> + sev->sev_kobj = NULL;
>>> + }
>>> +}
>>> +#else
>>> +static void sev_snp_register_verify_mitigation(struct sev_device *sev) { }
>>> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev) { }
>>> +#endif
>>> +
>>> static int __sev_snp_init_locked(int *error, unsigned int max_snp_asid)
>>> {
>>> struct sev_data_range_list *snp_range_list __free(kfree) = NULL;
>>> @@ -1670,6 +1828,14 @@ int sev_platform_init(struct sev_platform_init_args *args)
>>> rc = _sev_platform_init_locked(args);
>>> mutex_unlock(&sev_cmd_mutex);
>>>
>>> + /*
>>> + * The shutdown + init path can race with in-flight _show()/_store() operations
>>> + * which acquire the sev_cmd_mutex. Register the sysfs interface outside
>>> + * the sev_cmd_mutex and serialize by sev_mit_sysfs_mutex instead.
>>
>> I'm not quite sure I follow this. The shutdown and init path can't race
>> with each other, right? In which case this new mutex doesn't really matter
>> unless you take it on _show()/_short(), right?
>>
> What I meant here is the new mutex attempts to addresses the following scenario:
>
> First, assume sev_snp_[un]register_verify_mitigation() are protected under
> sev_cmd_mutex:
>
> t1 | t2
> ---------------------------------- | ----------------------------------
> sev_firmware_shutdown() |
> lock(sev_cmd_mutex) |
> | verified_mitigations_store()
> | lock(sev_cmd_mutex) <-- waits on t1
> unregister_verify_mitigation() |
> sysfs_remove_group() <-- waits for t2's _store to drain
>
> So sev_snp_unregister_verify_mitigation() has to run outside sev_cmd_mutex to
> avoid the sysfs_remove_group() <-> in-flight _show()/_store() deadlock.
>
> Now, with unregister no longer protected by sev_cmd_mutex, a concurrent init
> can race with shutdown on the sysfs lifetime like so:
Can it? Can init and shutdown race? Isn't that part of module load /
unload, I'm not sure how they can race...
> t1 | t2
> ---------------------------------- | ----------------------------------
> sev_firmware_shutdown() | sev_platform_init()
> unregister_verify_mitigation() | register_verify_mitigation()
> sysfs_remove_group() | sysfs_create_group()
>
> Both sides touch sev->verify_mit without serialization. The same race also
> exists for init vs init which is no longer covered by sev_cmd_mutex once
> register moves outside it.
I don't think you can have init vs init race, can you? This just all seems
odd to me. Have you created all these race scenarios to test this out?
Would putting the regsiter/unregister under the sev_cmd_mutex and then
taking the sev_cmd_mutex upon entry to _show()/_store() fix all this?
After obtaining the mutex in _show()/_store(), you check for
sev->verify_mit and return an error if NULL. Then you can use the
__sev_do_cmd_locked() to issue any commands.
Also, on the register function, all you need is the check for
!(sev->snp_feat_info_0.ecx & SNP_VERIFY_MITIGATION_SUPPORTED) since if
!sev->snp_plat_status.feature_info is true, so is this this check. And, as
the spec says, the required firmware state is based on the mitigation
requirements, so I don't think you should be checking for snp_initialized.
Thanks,
Tom
>
> So, I attempt address that with a sev_mit_sysfs_mutex guard.
>
> --Pratik
^ permalink raw reply
* [PATCH 0/5] Shikra: Add DT support for ice, rng and qce
From: Kuldeep Singh @ 2026-05-21 13:17 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Konrad Dybcio, Andy Gross
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine, Kuldeep Singh
This patchseries attempt to enable sdhc-ice, rng and qce on shikra
platform similar to other platforms.
Previously, the 3 dt-bindigs/DT changes were sent as individual series
and with feedback received, clubbed them together as all belong to same
crypto subsystem.
Here's link to old patchsets.
QCE: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-0-80f07b345c29@oss.qualcomm.com/
RNG: https://lore.kernel.org/lkml/20260514-shikra_rng-v1-0-4ea721a1429a@oss.qualcomm.com/
ICE: https://lore.kernel.org/lkml/20260515-shikra_ice_ufs-v2-0-2724a54339db@oss.qualcomm.com/
The patchseries require below as prerequisite:
https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/
Validations:
- Ice: driver probe on bootup.
- Qce: kcapi test alongwith driver probe
- Rng: validated with rngutils package.
- Validate shikra-cqs-evk.dtb with dt_bindings_check and CHECK_DTBS=y
with all yamls.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Kuldeep Singh (5):
dt-bindings: crypto: qcom,inline-crypto-engine: Document Shikra ICE
dt-bindings: crypto: qcom,prng: Document Shikra TRNG
dt-bindings: crypto: qcom-qce: Document the Shikra crypto engine
dt-bindings: dma: qcom,bam-dma: Increase iommus maxItems to seven
arm64: dts: qcom: shikra: Add ICE, TRNG and QCE nodes
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
.../devicetree/bindings/crypto/qcom,prng.yaml | 1 +
.../devicetree/bindings/crypto/qcom-qce.yaml | 1 +
.../devicetree/bindings/dma/qcom,bam-dma.yaml | 2 +-
arch/arm64/boot/dts/qcom/shikra.dtsi | 52 ++++++++++++++++++++++
5 files changed, 56 insertions(+), 1 deletion(-)
---
base-commit: bbf247cdb7ea162afb0c9548e2cd1354abb6462f
change-id: 20260521-shikra_crypto_changse-0c976c17763b
prerequisite-change-id: 20260511-shikra-dt-d75d97454646:v2
prerequisite-patch-id: e6edea1ef76fc1f3a9ad944684bee330c9ad7e59
prerequisite-patch-id: acae1549863061f0fdd7221f0a924b0892f15acf
prerequisite-patch-id: d145c1bd01622f50c69e5c1f13dee469ee4d1fe4
prerequisite-patch-id: 1b0da59c3859cba8c5f4f1e6bf08429988134c46
prerequisite-patch-id: fac2b512a679e1507debab6fc279b292fe4048cd
Best regards,
--
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/5] dt-bindings: crypto: qcom,inline-crypto-engine: Document Shikra ICE
From: Kuldeep Singh @ 2026-05-21 13:17 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Konrad Dybcio, Andy Gross
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine, Kuldeep Singh
In-Reply-To: <20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com>
Document the Inline Crypto Engine (ICE) on the Qualcomm Shikra platform.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index ccb6b8dd8e11..c0b083da78bf 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -20,6 +20,7 @@ properties:
- qcom,sa8775p-inline-crypto-engine
- qcom,sc7180-inline-crypto-engine
- qcom,sc7280-inline-crypto-engine
+ - qcom,shikra-inline-crypto-engine
- qcom,sm8450-inline-crypto-engine
- qcom,sm8550-inline-crypto-engine
- qcom,sm8650-inline-crypto-engine
--
2.34.1
^ permalink raw reply related
* [PATCH 2/5] dt-bindings: crypto: qcom,prng: Document Shikra TRNG
From: Kuldeep Singh @ 2026-05-21 13:17 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Konrad Dybcio, Andy Gross
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine, Kuldeep Singh
In-Reply-To: <20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com>
Document shikra compatible for the True Random Number Generator.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
index d054cc114707..3698525d3857 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -29,6 +29,7 @@ properties:
- qcom,sa8255p-trng
- qcom,sa8775p-trng
- qcom,sc7280-trng
+ - qcom,shikra-trng
- qcom,sm8450-trng
- qcom,sm8550-trng
- qcom,sm8650-trng
--
2.34.1
^ permalink raw reply related
* [PATCH 3/5] dt-bindings: crypto: qcom-qce: Document the Shikra crypto engine
From: Kuldeep Singh @ 2026-05-21 13:17 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Konrad Dybcio, Andy Gross
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine, Kuldeep Singh
In-Reply-To: <20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com>
Document the crypto engine on the Qualcomm Shikra platform.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index 08febd66c22b..5a653757ee75 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -54,6 +54,7 @@ properties:
- qcom,qcs8300-qce
- qcom,sa8775p-qce
- qcom,sc7280-qce
+ - qcom,shikra-qce
- qcom,sm6350-qce
- qcom,sm8250-qce
- qcom,sm8350-qce
--
2.34.1
^ permalink raw reply related
* [PATCH 4/5] dt-bindings: dma: qcom,bam-dma: Increase iommus maxItems to seven
From: Kuldeep Singh @ 2026-05-21 13:17 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Konrad Dybcio, Andy Gross
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine, Kuldeep Singh
In-Reply-To: <20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com>
Shikra bam dma engine support 7 iommu entries and not 6.
Increase maxItems property for iommus to pass dtbs_check errors.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
index 0923fb189ada..e72adc172af1 100644
--- a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
@@ -48,7 +48,7 @@ properties:
iommus:
minItems: 1
- maxItems: 6
+ maxItems: 7
num-channels:
$ref: /schemas/types.yaml#/definitions/uint32
--
2.34.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: qcom: shikra: Add ICE, TRNG and QCE nodes
From: Kuldeep Singh @ 2026-05-21 13:17 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Konrad Dybcio, Andy Gross
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine, Kuldeep Singh
In-Reply-To: <20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com>
Add device tree nodes describing the crypto hardware blocks present
on the Qualcomm Shikra platform:
- BAM DMA controller used by the Qualcomm crypto engine
- QCE (crypto) engine with DMA support
- TRNG hardware random number generator
- Inline crypto engine (ICE)
Also connect the SDHC controller to ICE via "qcom,ice" property to
support inline encryption.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 52 ++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index 31d0126e5b3e..b617735650ac 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -546,6 +546,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 0>;
+ #dma-cells = <1>;
+ iommus = <&apps_smmu 0x84 0x0011>,
+ <&apps_smmu 0x86 0x0011>,
+ <&apps_smmu 0x92 0x0>,
+ <&apps_smmu 0x94 0x0011>,
+ <&apps_smmu 0x96 0x0011>,
+ <&apps_smmu 0x98 0x0001>,
+ <&apps_smmu 0x9f 0x0>;
+ qcom,ee = <0>;
+ qcom,controlled-remotely;
+ num-channels = <16>;
+ qcom,num-ees = <4>;
+ };
+
+ crypto: crypto@1b3a000 {
+ compatible = "qcom,shikra-qce", "qcom,sm8150-qce", "qcom,qce";
+ reg = <0x0 0x01b3a000 0x0 0x6000>;
+ dmas = <&cryptobam 4>, <&cryptobam 5>;
+ dma-names = "rx", "tx";
+ iommus = <&apps_smmu 0x84 0x0011>,
+ <&apps_smmu 0x86 0x0011>,
+ <&apps_smmu 0x92 0x0>,
+ <&apps_smmu 0x94 0x0011>,
+ <&apps_smmu 0x96 0x0011>,
+ <&apps_smmu 0x98 0x0001>,
+ <&apps_smmu 0x9f 0x0>;
+ interconnects = <&system_noc MASTER_CRYPTO_CORE0 0
+ &mc_virt SLAVE_EBI_CH0 0>;
+ interconnect-names = "memory";
+ };
+
qfprom: efuse@1b44000 {
compatible = "qcom,shikra-qfprom", "qcom,qfprom";
reg = <0x0 0x01b44000 0x0 0x3000>;
@@ -585,6 +620,11 @@ spmi_bus: spmi@1c40000 {
qcom,ee = <0>;
};
+ rng: rng@4454000 {
+ compatible = "qcom,shikra-trng", "qcom,trng";
+ reg = <0x0 0x04454000 0x0 0x1000>;
+ };
+
rpm_msg_ram: sram@45f0000 {
compatible = "qcom,rpm-msg-ram", "mmio-sram";
reg = <0x0 0x045f0000 0x0 0x7000>;
@@ -646,6 +686,7 @@ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
mmc-hs400-enhanced-strobe;
resets = <&gcc GCC_SDCC1_BCR>;
+ qcom,ice = <&sdhc_ice>;
status = "disabled";
@@ -668,6 +709,17 @@ opp-384000000 {
};
};
+ sdhc_ice: crypto@4748000 {
+ compatible = "qcom,shikra-inline-crypto-engine",
+ "qcom,inline-crypto-engine";
+ reg = <0x0 0x04748000 0x0 0x18000>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>,
+ <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&rpmpd RPMHPD_CX>;
+ };
+
qupv3_0: geniqup@4ac0000 {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x04ac0000 0x0 0x2000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Tycho Andersen @ 2026-05-21 15:05 UTC (permalink / raw)
To: Tom Lendacky
Cc: Pratik R. Sampat, ashish.kalra, john.allen, herbert, davem,
linux-crypto, linux-kernel, aik, nikunj, michael.roth
In-Reply-To: <b02682e5-8890-454a-ab75-fff1b6566922@amd.com>
On Thu, May 21, 2026 at 08:12:52AM -0500, Tom Lendacky wrote:
> > Now, with unregister no longer protected by sev_cmd_mutex, a concurrent init
> > can race with shutdown on the sysfs lifetime like so:
>
> Can it? Can init and shutdown race? Isn't that part of module load /
> unload, I'm not sure how they can race...
That's only true after
https://lore.kernel.org/all/20260504165147.1615643-5-tycho@kernel.org/
right? Before that, if the first init failed, you could trigger a
re-init via ioctl(), and presumably trigger the race sashiko is
complaining about by spamming ioctl() + sysfs writes on separate
threads.
> > t1 | t2
> > ---------------------------------- | ----------------------------------
> > sev_firmware_shutdown() | sev_platform_init()
> > unregister_verify_mitigation() | register_verify_mitigation()
> > sysfs_remove_group() | sysfs_create_group()
> >
> > Both sides touch sev->verify_mit without serialization. The same race also
> > exists for init vs init which is no longer covered by sev_cmd_mutex once
> > register moves outside it.
>
> I don't think you can have init vs init race, can you? This just all seems
> odd to me. Have you created all these race scenarios to test this out?
>
> Would putting the regsiter/unregister under the sev_cmd_mutex and then
> taking the sev_cmd_mutex upon entry to _show()/_store() fix all this?
> After obtaining the mutex in _show()/_store(), you check for
> sev->verify_mit and return an error if NULL. Then you can use the
> __sev_do_cmd_locked() to issue any commands.
As long as sysfs_remove_group() happens before
__sev_firmware_shutdown() it seems like it should be fine since sysfs
will do its own synchronization. IIUC we might not need this locking
at all assuming the above is applied?
Tycho
^ permalink raw reply
* Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc
From: Goetz Goerisch @ 2026-05-21 15:25 UTC (permalink / raw)
To: Paul Louvel, Greg Kroah-Hartman
Cc: herve.codina, miquel.raynal, stable, thomas.petazzoni, Herbert Xu,
linux-crypto, Sasha Levin
In-Reply-To: <DIOA24QU02W5.2RSVK05RE7BJK@bootlin.com>
Dear Paul,
Thank you for this review and feedback.
> > Instead of renaming req_ctx->last, commit 9826d1d6ed5f8 ("crypto: talitos - stop
> > using crypto_ahash::init") should be applied. Ideally before commit
> > 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") to
> > avoid any compilation breakage and ensure correctness of the code.
>
> Small correction:
>
> Ideally before commit 00463d5f864a ("crypto: talitos - fix SEC1 32k ahash
> request limitation") to avoid any compilation breakage and ensure correctness of
> the code.
I can confirm your recommendation. Appyling this commit before, fixes the problem. Please disregard my patch.
Greg could you please backport the mentioned commit to 6.6.y in the correct order for the next update?
I have fixed it for our downstream users for now.
Thank you,
Goetz
^ permalink raw reply
* [PATCH v7 0/9] dmaengine: Add new API to combine configuration and descriptor preparation
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
Previously, configuration and preparation required two separate calls. This
works well when configuration is done only once during initialization.
However, in cases where the burst length or source/destination address must
be adjusted for each transfer, calling two functions is verbose.
if (dmaengine_slave_config(chan, &sconf)) {
dev_err(dev, "DMA slave config fail\n");
return -EIO;
}
tx = dmaengine_prep_slave_single(chan, dma_local, len, dir, flags);
After new API added
tx = dmaengine_prep_config_single(chan, dma_local, len, dir, flags, &sconf);
Additional, prevous two calls requires additional locking to ensure both
steps complete atomically.
mutex_lock()
dmaengine_slave_config()
dmaengine_prep_slave_single()
mutex_unlock()
after new API added, mutex lock can be moved. See patch
nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v7:
- Remvoe dma_(rx|tx)_lock() in nvmet totally. (sashia AI)
- Link to v6: https://patch.msgid.link/20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com
Changes in v6:
- Fix sashaki AI report problem, detail see each patch's change log
- Link to v5: https://lore.kernel.org/r/20260512-dma_prep_config-v5-0-26865bf7d935@nxp.com
Changes in v5:
- collect Mani's reviewed-by tags
- use kernel doc for new APIs.
- Link to v4: https://lore.kernel.org/r/20260506-dma_prep_config-v4-0-85b3d22babff@nxp.com
Changes in v4:
- remove void* context in config_prep() callback
- use spin lock to protect config() and prep().
- Link to v3: https://lore.kernel.org/r/20260105-dma_prep_config-v3-0-a8480362fd42@nxp.com
Changes in v3:
- collect review tags
- create safe version in framework
- Link to v2: https://lore.kernel.org/r/20251218-dma_prep_config-v2-0-c07079836128@nxp.com
Changes in v2:
- Use name dmaengine_prep_config_single() and dmaengine_prep_config_sg()
- Add _safe version to avoid confuse, which needn't additional mutex.
- Update document/
- Update commit message. add () for function name. Use upcase for subject.
- Add more explain for remove lock.
- Link to v1: https://lore.kernel.org/r/20251208-dma_prep_config-v1-0-53490c5e1e2a@nxp.com
---
Frank Li (9):
dmaengine: Add API to combine configuration and preparation (sg and single)
dmaengine: Add safe API to combine configuration and preparation
PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code
dmaengine: dw-edma: Use new .device_prep_config_sg() callback
dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code
crypto: atmel: Use dmaengine_prep_config_sg() API
Documentation/driver-api/dmaengine/client.rst | 9 ++
drivers/crypto/atmel-aes.c | 10 +-
drivers/dma/dmaengine.c | 2 +
drivers/dma/dw-edma/dw-edma-core.c | 41 +++++--
drivers/nvme/target/pci-epf.c | 33 +-----
drivers/pci/endpoint/functions/pci-epf-mhi.c | 52 +++------
drivers/pci/endpoint/functions/pci-epf-test.c | 8 +-
include/linux/dmaengine.h | 149 ++++++++++++++++++++++++--
8 files changed, 208 insertions(+), 96 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20251204-dma_prep_config-654170d245a2
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v7 1/9] dmaengine: Add API to combine configuration and preparation (sg and single)
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Previously, configuration and preparation required two separate calls. This
works well when configuration is done only once during initialization.
However, in cases where the burst length or source/destination address must
be adjusted for each transfer, calling two functions is verbose and
requires additional locking to ensure both steps complete atomically.
Add a new API dmaengine_prep_config_single() and dmaengine_prep_config_sg()
and callback device_prep_config_sg() that combines configuration and
preparation into a single operation. If the configuration argument is
passed as NULL, fall back to the existing implementation.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v4
- drop context in device_prep_config_sg()
change in v3
- remove Deprecated for callback device_prep_slave_sg().
- Move condition check before sg init.
- split function at return type.
- move safe version to next patch
change in v2
- add () for function
- use short name device_prep_sg(), remove "slave" and "config". the 'slave'
is reduntant. after remove slave, the function name is difference existed
one, so remove _config suffix.
---
Documentation/driver-api/dmaengine/client.rst | 9 ++++
include/linux/dmaengine.h | 63 +++++++++++++++++++++++----
2 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
index d491e385d61a9..5ee5d4a3596dd 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -80,6 +80,10 @@ The details of these operations are:
- slave_sg: DMA a list of scatter gather buffers from/to a peripheral
+ - config_sg: Similar with slave_sg, just pass down dma_slave_config
+ struct to avoid calling dmaengine_slave_config() every time adjusting the
+ burst length or the FIFO address is needed.
+
- peripheral_dma_vec: DMA an array of scatter gather buffers from/to a
peripheral. Similar to slave_sg, but uses an array of dma_vec
structures instead of a scatterlist.
@@ -106,6 +110,11 @@ The details of these operations are:
unsigned int sg_len, enum dma_data_direction direction,
unsigned long flags);
+ struct dma_async_tx_descriptor *dmaengine_prep_config_sg(
+ struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction dir,
+ unsigned long flags, struct dma_slave_config *config);
+
struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
struct dma_chan *chan, const struct dma_vec *vecs,
size_t nents, enum dma_data_direction direction,
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index b3d251c9734e9..defa377d2ef54 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -835,6 +835,7 @@ struct dma_filter {
* where the address and size of each segment is located in one entry of
* the dma_vec array.
* @device_prep_slave_sg: prepares a slave dma operation
+ * @device_prep_config_sg: prepares a slave DMA operation with dma_slave_config
* @device_prep_dma_cyclic: prepare a cyclic dma operation suitable for audio.
* The function takes a buffer of size buf_len. The callback function will
* be called after period_len bytes have been transferred.
@@ -934,6 +935,10 @@ struct dma_device {
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
unsigned long flags, void *context);
+ struct dma_async_tx_descriptor *(*device_prep_config_sg)(
+ struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction direction,
+ unsigned long flags, struct dma_slave_config *config);
struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
@@ -974,22 +979,44 @@ static inline bool is_slave_direction(enum dma_transfer_direction direction)
(direction == DMA_DEV_TO_DEV);
}
-static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
- struct dma_chan *chan, dma_addr_t buf, size_t len,
- enum dma_transfer_direction dir, unsigned long flags)
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_single(struct dma_chan *chan, dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags,
+ struct dma_slave_config *config)
{
struct scatterlist sg;
+
+ if (!chan || !chan->device)
+ return NULL;
+
sg_init_table(&sg, 1);
sg_dma_address(&sg) = buf;
sg_dma_len(&sg) = len;
- if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
+ if (chan->device->device_prep_config_sg)
+ return chan->device->device_prep_config_sg(chan, &sg, 1, dir,
+ flags, config);
+
+ if (config)
+ if (dmaengine_slave_config(chan, config))
+ return NULL;
+
+ if (!chan->device->device_prep_slave_sg)
return NULL;
return chan->device->device_prep_slave_sg(chan, &sg, 1,
dir, flags, NULL);
}
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_slave_single(struct dma_chan *chan, dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ return dmaengine_prep_config_single(chan, buf, len, dir, flags, NULL);
+}
+
/**
* dmaengine_prep_peripheral_dma_vec() - Prepare a DMA scatter-gather descriptor
* @chan: The channel to be used for this descriptor
@@ -1010,17 +1037,37 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
dir, flags);
}
-static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
- struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
- enum dma_transfer_direction dir, unsigned long flags)
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_sg(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction dir,
+ unsigned long flags, struct dma_slave_config *config)
{
- if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
+ if (!chan || !chan->device)
+ return NULL;
+
+ if (chan->device->device_prep_config_sg)
+ return chan->device->device_prep_config_sg(chan, sgl, sg_len,
+ dir, flags, config);
+
+ if (config)
+ if (dmaengine_slave_config(chan, config))
+ return NULL;
+
+ if (!chan->device->device_prep_slave_sg)
return NULL;
return chan->device->device_prep_slave_sg(chan, sgl, sg_len,
dir, flags, NULL);
}
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ return dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, NULL);
+}
+
#ifdef CONFIG_RAPIDIO_DMA_ENGINE
struct rio_dma_ext;
static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg(
--
2.43.0
^ permalink raw reply related
* [PATCH v7 2/9] dmaengine: Add safe API to combine configuration and preparation
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Introduce dmaengine_prep_config_single_safe() and
dmaengine_prep_config_sg_safe() to provide a reentrant-safe way to
combine slave configuration and transfer preparation.
Drivers may implement the new device_prep_config_sg() callback to perform
both steps atomically. If the callback is not provided, the helpers fall
back to calling dmaengine_slave_config() followed by
dmaengine_prep_slave_sg() under per-channel spinlock protection.
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v6
- replace mutex with spinlock in commit message
- use spinlock_saveirq according to AI review results
"The documentation in struct dma_chan notes that *_prep() may be called
from a completion callback. Since completion callbacks often execute in
softirq or hardirq contexts, if a thread calls this function from
process context, local interrupts remain enabled.
If a DMA interrupt fires on the same CPU while the lock is held, the
completion callback could attempt to call this function again to queue
the next transfer, leading it to wait on the already-held chan->lock.
Does this fallback path need to use spin_lock_irqsave() and
spin_unlock_irqrestore() to safely disable interrupts?
"
chagne in v5
- remove reduntant lock commments.
- use kernel doc to descritp API
chagne in v4
- use spinlock() to protect config() and prep()
change in v3
- new patch
---
drivers/dma/dmaengine.c | 2 ++
include/linux/dmaengine.h | 86 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 405bd2fbb4a3b..ba29e60160c1a 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1099,6 +1099,8 @@ static int __dma_async_device_channel_register(struct dma_device *device,
chan->dev->device.parent = device->dev;
chan->dev->chan = chan;
chan->dev->dev_id = device->dev_id;
+ spin_lock_init(&chan->lock);
+
if (!name)
dev_set_name(&chan->dev->device, "dma%dchan%d", device->dev_id, chan->chan_id);
else
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index defa377d2ef54..6fe46c0c94527 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -322,6 +322,8 @@ struct dma_router {
* @slave: ptr to the device using this channel
* @cookie: last cookie value returned to client
* @completed_cookie: last completed cookie for this channel
+ * @lock: protect between config and prepare transfer when driver have not
+ * implemented callback device_prep_config_sg().
* @chan_id: channel ID for sysfs
* @dev: class device for sysfs
* @name: backlink name for sysfs
@@ -341,6 +343,12 @@ struct dma_chan {
dma_cookie_t cookie;
dma_cookie_t completed_cookie;
+ /*
+ * protect between config and prepare transfer because *_prep() may be
+ * called from complete callback, which is in GFP_NOSLEEP context.
+ */
+ spinlock_t lock;
+
/* sysfs */
int chan_id;
struct dma_chan_dev *dev;
@@ -1068,6 +1076,84 @@ dmaengine_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
return dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, NULL);
}
+/**
+ * dmaengine_prep_config_sg_safe - prepare a scatter-gather DMA transfer
+ * with atomic slave configuration update
+ * @chan: DMA channel
+ * @sgl: scatterlist for the transfer
+ * @sg_len: number of entries in @sgl
+ * @dir: DMA transfer direction
+ * @flags: transfer preparation flags
+ * @config: DMA slave configuration for this transfer
+ *
+ * Prepare a DMA scatter-gather transfer together with a corresponding slave
+ * configuration update in a re-entrant and race-safe manner.
+ *
+ * DMA engine drivers may implement the optional
+ * device_prep_config_sg() callback to perform both the slave configuration
+ * and descriptor preparation atomically. In this case, the operation is
+ * fully handled by the DMA engine driver.
+ *
+ * If the DMA engine driver does not implement device_prep_config_sg(), falls
+ * back to calling dmaengine_slave_config() followed by dmaengine_prep_slave_sg().
+ * The fallback path is protected by a per-channel spinlock to ensure that
+ * concurrent callers cannot interleave configuration and descriptor preparation
+ * on the same DMA channel.
+ *
+ * Return: Pointer to a prepared DMA async transaction descriptor on success,
+ * or %NULL if the transfer could not be prepared.
+ */
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_sg_safe(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len,
+ enum dma_transfer_direction dir,
+ unsigned long flags,
+ struct dma_slave_config *config)
+{
+ struct dma_async_tx_descriptor *tx;
+ unsigned long spinlock_flags;
+
+ if (!chan || !chan->device)
+ return NULL;
+
+ if (!chan->device->device_prep_config_sg)
+ spin_lock_irqsave(&chan->lock, spinlock_flags);
+
+ tx = dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, config);
+
+ if (!chan->device->device_prep_config_sg)
+ spin_unlock_irqrestore(&chan->lock, spinlock_flags);
+
+ return tx;
+}
+
+/**
+ * dmaengine_prep_config_single_safe - prepare a single-buffer DMA transfer
+ * with atomic slave configuration update
+ * @chan: DMA channel
+ * @buf: DMA buffer address
+ * @len: length of the transfer in bytes
+ * @dir: DMA transfer direction
+ * @flags: transfer preparation flags
+ * @config: DMA slave configuration for this transfer
+ *
+ * Detail see dmaengine_prep_config_sg_safe().
+ */
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_single_safe(struct dma_chan *chan, dma_addr_t buf,
+ size_t len, enum dma_transfer_direction dir,
+ unsigned long flags,
+ struct dma_slave_config *config)
+{
+ struct scatterlist sg;
+
+ sg_init_table(&sg, 1);
+ sg_dma_address(&sg) = buf;
+ sg_dma_len(&sg) = len;
+
+ return dmaengine_prep_config_sg_safe(chan, &sg, 1, dir, flags, config);
+}
+
#ifdef CONFIG_RAPIDIO_DMA_ENGINE
struct rio_dma_ext;
static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg(
--
2.43.0
^ permalink raw reply related
* [PATCH v7 3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use dmaenigne_prep_config_single() to simplify code.
No functional change.
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v3
- add Damien Le Moal review tag
---
drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index 591d301fa89d8..0f5cf2d795108 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -182,12 +182,8 @@ static int pci_epf_test_data_transfer(struct pci_epf_test *epf_test,
else
sconf.src_addr = dma_remote;
- if (dmaengine_slave_config(chan, &sconf)) {
- dev_err(dev, "DMA slave config fail\n");
- return -EIO;
- }
- tx = dmaengine_prep_slave_single(chan, dma_local, len, dir,
- flags);
+ tx = dmaengine_prep_config_single(chan, dma_local, len,
+ dir, flags, &sconf);
} else {
tx = dmaengine_prep_dma_memcpy(chan, dma_dst, dma_src, len,
flags);
--
2.43.0
^ permalink raw reply related
* [PATCH v7 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use the new .device_prep_config_sg() callback to combine configuration and
descriptor preparation.
No functional changes.
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v6
- check dw_edma_device_config() return value; find by sashiko AI.
change in v4
- drop context in callback.
change in v3
- add Damien Le Moal review tag
---
drivers/dma/dw-edma/dw-edma-core.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index c2feb3adc79fa..92572dd8131e6 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -577,10 +577,11 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
}
static struct dma_async_tx_descriptor *
-dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
- unsigned int len,
- enum dma_transfer_direction direction,
- unsigned long flags, void *context)
+dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
+ unsigned int len,
+ enum dma_transfer_direction direction,
+ unsigned long flags,
+ struct dma_slave_config *config)
{
struct dw_edma_transfer xfer;
@@ -591,6 +592,9 @@ dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
xfer.flags = flags;
xfer.type = EDMA_XFER_SCATTER_GATHER;
+ if (config && dw_edma_device_config(dchan, config))
+ return NULL;
+
return dw_edma_device_transfer(&xfer);
}
@@ -970,7 +974,7 @@ static int dw_edma_channel_setup(struct dw_edma *dw, u32 wr_alloc, u32 rd_alloc)
dma->device_terminate_all = dw_edma_device_terminate_all;
dma->device_issue_pending = dw_edma_device_issue_pending;
dma->device_tx_status = dw_edma_device_tx_status;
- dma->device_prep_slave_sg = dw_edma_device_prep_slave_sg;
+ dma->device_prep_config_sg = dw_edma_device_prep_config_sg;
dma->device_prep_dma_cyclic = dw_edma_device_prep_dma_cyclic;
dma->device_prep_interleaved_dma = dw_edma_device_prep_interleaved_dma;
--
2.43.0
^ permalink raw reply related
* [PATCH v7 5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Pass dma_slave_config to dw_edma_device_transfer() to support atomic
configuration and descriptor preparation when a non-NULL config is
provided to device_prep_config_sg().
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v3
- rewrite dw_edma_device_slave_config() according to Damien's suggestion.
---
drivers/dma/dw-edma/dw-edma-core.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index 92572dd8131e6..ba37bc983dcd2 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -267,6 +267,20 @@ static int dw_edma_device_config(struct dma_chan *dchan,
return 0;
}
+static struct dma_slave_config *
+dw_edma_device_get_config(struct dma_chan *dchan,
+ struct dma_slave_config *config)
+{
+ struct dw_edma_chan *chan;
+
+ if (config)
+ return config;
+
+ chan = dchan2dw_edma_chan(dchan);
+
+ return &chan->config;
+}
+
static int dw_edma_device_pause(struct dma_chan *dchan)
{
struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
@@ -385,7 +399,8 @@ dw_edma_device_tx_status(struct dma_chan *dchan, dma_cookie_t cookie,
}
static struct dma_async_tx_descriptor *
-dw_edma_device_transfer(struct dw_edma_transfer *xfer)
+dw_edma_device_transfer(struct dw_edma_transfer *xfer,
+ struct dma_slave_config *config)
{
struct dw_edma_chan *chan = dchan2dw_edma_chan(xfer->dchan);
enum dma_transfer_direction dir = xfer->direction;
@@ -472,8 +487,8 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
src_addr = xfer->xfer.il->src_start;
dst_addr = xfer->xfer.il->dst_start;
} else {
- src_addr = chan->config.src_addr;
- dst_addr = chan->config.dst_addr;
+ src_addr = config->src_addr;
+ dst_addr = config->dst_addr;
}
if (dir == DMA_DEV_TO_MEM)
@@ -595,7 +610,7 @@ dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
if (config && dw_edma_device_config(dchan, config))
return NULL;
- return dw_edma_device_transfer(&xfer);
+ return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, config));
}
static struct dma_async_tx_descriptor *
@@ -614,7 +629,7 @@ dw_edma_device_prep_dma_cyclic(struct dma_chan *dchan, dma_addr_t paddr,
xfer.flags = flags;
xfer.type = EDMA_XFER_CYCLIC;
- return dw_edma_device_transfer(&xfer);
+ return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
}
static struct dma_async_tx_descriptor *
@@ -630,7 +645,7 @@ dw_edma_device_prep_interleaved_dma(struct dma_chan *dchan,
xfer.flags = flags;
xfer.type = EDMA_XFER_INTERLEAVED;
- return dw_edma_device_transfer(&xfer);
+ return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
}
static void dw_hdma_set_callback_result(struct virt_dma_desc *vd,
--
2.43.0
^ permalink raw reply related
* [PATCH v7 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
dmaengine_terminate_sync() cancels all pending requests. Calling it for
every DMA transfer is unnecessary and counterproductive. This function is
generally intended for cleanup paths such as module removal, device close,
or unbind operations.
Remove the redundant calls for success path and keep it only at error path.
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
This one also fix stress test failure after remove mutex and use new API
dmaengine_prep_slave_sg_config().
---
drivers/nvme/target/pci-epf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 4e9db96ebfecd..2afe8f4d0e461 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -420,10 +420,9 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
if (dma_sync_wait(chan, cookie) != DMA_COMPLETE) {
dev_err(dev, "DMA transfer failed\n");
ret = -EIO;
+ dmaengine_terminate_sync(chan);
}
- dmaengine_terminate_sync(chan);
-
unmap:
dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
--
2.43.0
^ permalink raw reply related
* [PATCH v7 7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use the new dmaengine_prep_config_single_safe() API to combine the
configuration and descriptor preparation into a single call.
Since dmaengine_prep_config_single_safe() performs the configuration and
preparation atomically and the mutex can be removed.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v7
- remove dma_(rx|tx)_lock totally (sashika AI)
change in v6
- remove local unused variable lock (sashika AI)
---
drivers/nvme/target/pci-epf.c | 30 ++++--------------------------
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 2afe8f4d0e461..b1ba2d0bea6d9 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -210,9 +210,7 @@ struct nvmet_pci_epf {
bool dma_enabled;
struct dma_chan *dma_tx_chan;
- struct mutex dma_tx_lock;
struct dma_chan *dma_rx_chan;
- struct mutex dma_rx_lock;
struct mutex mmio_lock;
@@ -295,9 +293,6 @@ static void nvmet_pci_epf_init_dma(struct nvmet_pci_epf *nvme_epf)
struct dma_chan *chan;
dma_cap_mask_t mask;
- mutex_init(&nvme_epf->dma_rx_lock);
- mutex_init(&nvme_epf->dma_tx_lock);
-
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -336,8 +331,6 @@ static void nvmet_pci_epf_init_dma(struct nvmet_pci_epf *nvme_epf)
nvme_epf->dma_rx_chan = NULL;
out_dma_no_rx:
- mutex_destroy(&nvme_epf->dma_rx_lock);
- mutex_destroy(&nvme_epf->dma_tx_lock);
nvme_epf->dma_enabled = false;
dev_info(&epf->dev, "DMA not supported, falling back to MMIO\n");
@@ -352,8 +345,6 @@ static void nvmet_pci_epf_deinit_dma(struct nvmet_pci_epf *nvme_epf)
nvme_epf->dma_tx_chan = NULL;
dma_release_channel(nvme_epf->dma_rx_chan);
nvme_epf->dma_rx_chan = NULL;
- mutex_destroy(&nvme_epf->dma_rx_lock);
- mutex_destroy(&nvme_epf->dma_tx_lock);
nvme_epf->dma_enabled = false;
}
@@ -368,18 +359,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
struct dma_chan *chan;
dma_cookie_t cookie;
dma_addr_t dma_addr;
- struct mutex *lock;
int ret;
switch (dir) {
case DMA_FROM_DEVICE:
- lock = &nvme_epf->dma_rx_lock;
chan = nvme_epf->dma_rx_chan;
sconf.direction = DMA_DEV_TO_MEM;
sconf.src_addr = seg->pci_addr;
break;
case DMA_TO_DEVICE:
- lock = &nvme_epf->dma_tx_lock;
chan = nvme_epf->dma_tx_chan;
sconf.direction = DMA_MEM_TO_DEV;
sconf.dst_addr = seg->pci_addr;
@@ -388,22 +376,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
return -EINVAL;
}
- mutex_lock(lock);
-
dma_dev = dmaengine_get_dma_device(chan);
dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
ret = dma_mapping_error(dma_dev, dma_addr);
if (ret)
- goto unlock;
-
- ret = dmaengine_slave_config(chan, &sconf);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto unmap;
- }
+ return ret;
- desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
- sconf.direction, DMA_CTRL_ACK);
+ desc = dmaengine_prep_config_single_safe(chan, dma_addr, seg->length,
+ sconf.direction,
+ DMA_CTRL_ACK, &sconf);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -426,9 +407,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
unmap:
dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
-unlock:
- mutex_unlock(lock);
-
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v7 8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use dmaengine_prep_config_single() to simplify
pci_epf_mhi_edma_read[_sync]() and pci_epf_mhi_edma_write[_sync]().
No functional change.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Keep mutex lock because sync with other function.
---
drivers/pci/endpoint/functions/pci-epf-mhi.c | 52 +++++++++-------------------
1 file changed, 16 insertions(+), 36 deletions(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-mhi.c b/drivers/pci/endpoint/functions/pci-epf-mhi.c
index 7f5326925ed54..c3e3b58fb86cd 100644
--- a/drivers/pci/endpoint/functions/pci-epf-mhi.c
+++ b/drivers/pci/endpoint/functions/pci-epf-mhi.c
@@ -328,12 +328,6 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_DEV_TO_MEM;
config.src_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
dst_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_FROM_DEVICE);
ret = dma_mapping_error(dma_dev, dst_addr);
@@ -342,9 +336,10 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, dst_addr, buf_info->size,
- DMA_DEV_TO_MEM,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, dst_addr, buf_info->size,
+ DMA_DEV_TO_MEM,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -401,12 +396,6 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_MEM_TO_DEV;
config.dst_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
src_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_TO_DEVICE);
ret = dma_mapping_error(dma_dev, src_addr);
@@ -415,9 +404,10 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, src_addr, buf_info->size,
- DMA_MEM_TO_DEV,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, src_addr, buf_info->size,
+ DMA_MEM_TO_DEV,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -506,12 +496,6 @@ static int pci_epf_mhi_edma_read_async(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_DEV_TO_MEM;
config.src_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
dst_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_FROM_DEVICE);
ret = dma_mapping_error(dma_dev, dst_addr);
@@ -520,9 +504,10 @@ static int pci_epf_mhi_edma_read_async(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, dst_addr, buf_info->size,
- DMA_DEV_TO_MEM,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, dst_addr, buf_info->size,
+ DMA_DEV_TO_MEM,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -585,12 +570,6 @@ static int pci_epf_mhi_edma_write_async(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_MEM_TO_DEV;
config.dst_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
src_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_TO_DEVICE);
ret = dma_mapping_error(dma_dev, src_addr);
@@ -599,9 +578,10 @@ static int pci_epf_mhi_edma_write_async(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, src_addr, buf_info->size,
- DMA_MEM_TO_DEV,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, src_addr, buf_info->size,
+ DMA_MEM_TO_DEV,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
--
2.43.0
^ permalink raw reply related
* [PATCH v7 9/9] crypto: atmel: Use dmaengine_prep_config_sg() API
From: Frank.Li @ 2026-05-21 15:32 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Using new API dmaengine_prep_config_sg() to simple code.
dmaengine_prep_config_sg() does not distinguish between configuration
failures and descriptor preparation failures, as both are reported through
a NULL return value. Converting both cases to -ENOMEM is therefore
acceptable and consistent with the helper's abstraction.
In practice, most users only care whether the operation succeeds or fails,
and do not depend on the exact errno value returned from this path.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v6
- add commit message about error propagation (sashaki AI)
---
drivers/crypto/atmel-aes.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
index b393689400b4c..d890b5a277b9c 100644
--- a/drivers/crypto/atmel-aes.c
+++ b/drivers/crypto/atmel-aes.c
@@ -795,7 +795,6 @@ static int atmel_aes_dma_transfer_start(struct atmel_aes_dev *dd,
struct dma_slave_config config;
dma_async_tx_callback callback;
struct atmel_aes_dma *dma;
- int err;
memset(&config, 0, sizeof(config));
config.src_addr_width = addr_width;
@@ -820,12 +819,9 @@ static int atmel_aes_dma_transfer_start(struct atmel_aes_dev *dd,
return -EINVAL;
}
- err = dmaengine_slave_config(dma->chan, &config);
- if (err)
- return err;
-
- desc = dmaengine_prep_slave_sg(dma->chan, dma->sg, dma->sg_len, dir,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ desc = dmaengine_prep_config_sg(dma->chan, dma->sg, dma->sg_len, dir,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+ &config);
if (!desc)
return -ENOMEM;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH bpf-next v8 0/4] Add cryptographic hash and signature verification kfuncs to BPF
From: Felix Maurer @ 2026-05-21 16:30 UTC (permalink / raw)
To: Daniel Hodges
Cc: bpf, linux-crypto, linux-kernel, linux-kselftest, ast, andrii,
daniel, vadim.fedorenko, song, yatsenko, martin.lau, eddyz87,
haoluo, jolsa, john.fastabend, kpsingh, sdf, yonghong.song,
herbert, davem
In-Reply-To: <20260225202935.31986-1-git@danielhodges.dev>
On Wed, Feb 25, 2026 at 03:29:31PM -0500, Daniel Hodges wrote:
> This patch series enhances BPF's cryptographic functionality by introducing
> kernel functions for SHA hashing and ECDSA signature verification. The changes
> enable BPF programs to verify data integrity and authenticity across
> networking, security, and observability use cases.
>
> The series addresses two gaps in BPF's cryptographic toolkit:
>
> 1. Cryptographic hashing - supports content verification and message digest
> preparation
> 2. Asymmetric signature verification - allows validation of signed data
> without requiring private keys in the datapath
Hi Daniel,
I found your series because I was about to implement something similar
like your hashing implementation. In other words, I'd be very happy to
see this patchset move forward.
Taking an initial look at your hashing patches, I'm wondering: the usual
interface to hash/digest algorithms is to have three functions: an
init() function to set up state, an update() function that can be called
multiple times to hash new bytes, and a finalize() function that creates
the actual hash. Depending on the algorithm, some of them (esp.
finalize) may be no-ops. Often, a fourth function, like hash(), is
provided as convenience, doing one init/update/finalize cycle when all
data to be hashed is already available.
I think we should provide the same init/update/finalize interface in bpf
as well to make the API more flexible. That would require splitting out
the shash_desc from the (mostly static) context. But doing so would also
address the review comment from bpf-ci bot to patch 1. WDYT?
Thanks,
Felix
^ permalink raw reply
* Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Tom Lendacky @ 2026-05-21 20:04 UTC (permalink / raw)
To: Tycho Andersen
Cc: Pratik R. Sampat, ashish.kalra, john.allen, herbert, davem,
linux-crypto, linux-kernel, aik, nikunj, michael.roth
In-Reply-To: <ag8c3v3GjWLWz-OS@tycho.pizza>
On 5/21/26 10:05, Tycho Andersen wrote:
> On Thu, May 21, 2026 at 08:12:52AM -0500, Tom Lendacky wrote:
>>> Now, with unregister no longer protected by sev_cmd_mutex, a concurrent init
>>> can race with shutdown on the sysfs lifetime like so:
>>
>> Can it? Can init and shutdown race? Isn't that part of module load /
>> unload, I'm not sure how they can race...
>
> That's only true after
> https://lore.kernel.org/all/20260504165147.1615643-5-tycho@kernel.org/
> right? Before that, if the first init failed, you could trigger a
> re-init via ioctl(), and presumably trigger the race sashiko is
> complaining about by spamming ioctl() + sysfs writes on separate
> threads.
>
>>> t1 | t2
>>> ---------------------------------- | ----------------------------------
>>> sev_firmware_shutdown() | sev_platform_init()
>>> unregister_verify_mitigation() | register_verify_mitigation()
>>> sysfs_remove_group() | sysfs_create_group()
>>>
>>> Both sides touch sev->verify_mit without serialization. The same race also
>>> exists for init vs init which is no longer covered by sev_cmd_mutex once
>>> register moves outside it.
>>
>> I don't think you can have init vs init race, can you? This just all seems
>> odd to me. Have you created all these race scenarios to test this out?
>>
>> Would putting the regsiter/unregister under the sev_cmd_mutex and then
>> taking the sev_cmd_mutex upon entry to _show()/_store() fix all this?
>> After obtaining the mutex in _show()/_store(), you check for
>> sev->verify_mit and return an error if NULL. Then you can use the
>> __sev_do_cmd_locked() to issue any commands.
>
> As long as sysfs_remove_group() happens before
> __sev_firmware_shutdown() it seems like it should be fine since sysfs
> will do its own synchronization. IIUC we might not need this locking
> at all assuming the above is applied?
That's what I'm thinking. I'll let Pratik confirm.
Thanks,
Tom
>
> Tycho
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Andrew Morton @ 2026-05-22 0:17 UTC (permalink / raw)
To: Qu Wenruo
Cc: Christoph Hellwig, H. Peter Anvin, kreijack, David Sterba,
Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <f46636c8-80ba-4802-a6a0-74cbc35e7bee@gmx.com>
On Wed, 20 May 2026 18:11:09 +0930 Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
> 在 2026/5/18 14:42, Christoph Hellwig 写道:
> > On Fri, May 15, 2026 at 12:59:34PM -0700, H. Peter Anvin wrote:
> >> I don't think this is a good idea. Error out; it is the btrfs maintainers' job to ensure user data isn't lost.
> >>
> >> The RAID-6 code has *never* supported only 3 units, and if it ever worked for *any* of the implementations it was purely by accident. Speaking as the original author I should know; this was deliberate as in some cases the degenerate case (3) would have required extra trays in the code to no user benefit.
> >>
> >> I would not be surprised if the kernel crashed or corrupted the page cache in that case.
> >
> > It does, that's why I wanted to exclude it. Anyway, for the about to be
> > resent version I'll drop this btrfs patch over the stated objection and
> > will otherwise not change anything. This means the (IMHO hypothetical)
> > users of this configuration will get a WARN_ON_ONCE triggered, but
> > otherwise keep working (or rather not working) as before.
> >
>
> For the btrfs part, I believe I can get the current 2-disk-raid5 and
> 3-disk-raid6 to fallback to raid1 inside btrfs.
>
> I hope the btrfs part can be finished and reach the next merge window,
> but I'm not 100% sure.
>
> What is the planned cycle to merge this raid5/6 cleanup?
At present it's on track for the 7.2-rc1 merge window. Does that suit?
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: Qu Wenruo @ 2026-05-22 0:27 UTC (permalink / raw)
To: Andrew Morton, Qu Wenruo
Cc: Christoph Hellwig, H. Peter Anvin, kreijack, David Sterba,
Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260521171730.7872482df453975cf60ce7dc@linux-foundation.org>
在 2026/5/22 09:47, Andrew Morton 写道:
> On Wed, 20 May 2026 18:11:09 +0930 Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>>
>>
>> 在 2026/5/18 14:42, Christoph Hellwig 写道:
>>> On Fri, May 15, 2026 at 12:59:34PM -0700, H. Peter Anvin wrote:
>>>> I don't think this is a good idea. Error out; it is the btrfs maintainers' job to ensure user data isn't lost.
>>>>
>>>> The RAID-6 code has *never* supported only 3 units, and if it ever worked for *any* of the implementations it was purely by accident. Speaking as the original author I should know; this was deliberate as in some cases the degenerate case (3) would have required extra trays in the code to no user benefit.
>>>>
>>>> I would not be surprised if the kernel crashed or corrupted the page cache in that case.
>>>
>>> It does, that's why I wanted to exclude it. Anyway, for the about to be
>>> resent version I'll drop this btrfs patch over the stated objection and
>>> will otherwise not change anything. This means the (IMHO hypothetical)
>>> users of this configuration will get a WARN_ON_ONCE triggered, but
>>> otherwise keep working (or rather not working) as before.
>>>
>>
>> For the btrfs part, I believe I can get the current 2-disk-raid5 and
>> 3-disk-raid6 to fallback to raid1 inside btrfs.
>>
>> I hope the btrfs part can be finished and reach the next merge window,
>> but I'm not 100% sure.
>>
>> What is the planned cycle to merge this raid5/6 cleanup?
>
> At present it's on track for the 7.2-rc1 merge window. Does that suit?
The current btrfs fix (*) is pretty small, I believe we can get it into
the next merge window, as long as we got enough review on it.
*:
https://lore.kernel.org/linux-btrfs/a1d63733465229936351804f3760803d5894a962.1779274630.git.wqu@suse.com/T/#u
^ permalink raw reply
* Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Pratik R. Sampat @ 2026-05-22 1:58 UTC (permalink / raw)
To: Tom Lendacky, Tycho Andersen
Cc: ashish.kalra, john.allen, herbert, davem, linux-crypto,
linux-kernel, aik, nikunj, michael.roth
In-Reply-To: <4362cbe9-b9a6-42c8-8066-807e4a82c7e5@amd.com>
On 5/21/26 4:04 PM, Tom Lendacky wrote:
> On 5/21/26 10:05, Tycho Andersen wrote:
>> On Thu, May 21, 2026 at 08:12:52AM -0500, Tom Lendacky wrote:
>>>> Now, with unregister no longer protected by sev_cmd_mutex, a concurrent init
>>>> can race with shutdown on the sysfs lifetime like so:
>>>
>>> Can it? Can init and shutdown race? Isn't that part of module load /
>>> unload, I'm not sure how they can race...
>>
>> That's only true after
>> https://lore.kernel.org/all/20260504165147.1615643-5-tycho@kernel.org/
>> right? Before that, if the first init failed, you could trigger a
>> re-init via ioctl(), and presumably trigger the race sashiko is
>> complaining about by spamming ioctl() + sysfs writes on separate
>> threads.
Yes, this is the race I had in mind and probably what sashiko complained about
in it's review too. I missed this patch from earlier. This should avoid any
racing.
>>
>>>> t1 | t2
>>>> ---------------------------------- | ----------------------------------
>>>> sev_firmware_shutdown() | sev_platform_init()
>>>> unregister_verify_mitigation() | register_verify_mitigation()
>>>> sysfs_remove_group() | sysfs_create_group()
>>>>
>>>> Both sides touch sev->verify_mit without serialization. The same race also
>>>> exists for init vs init which is no longer covered by sev_cmd_mutex once
>>>> register moves outside it.
>>>
>>> I don't think you can have init vs init race, can you? This just all seems
>>> odd to me. Have you created all these race scenarios to test this out?
>>>
>>> Would putting the regsiter/unregister under the sev_cmd_mutex and then
>>> taking the sev_cmd_mutex upon entry to _show()/_store() fix all this?
>>> After obtaining the mutex in _show()/_store(), you check for
>>> sev->verify_mit and return an error if NULL. Then you can use the
>>> __sev_do_cmd_locked() to issue any commands.
>>
>> As long as sysfs_remove_group() happens before
>> __sev_firmware_shutdown() it seems like it should be fine since sysfs
>> will do its own synchronization. IIUC we might not need this locking
>> at all assuming the above is applied?
>
> That's what I'm thinking. I'll let Pratik confirm.
>
Yes, sysfs should do its own synchronization and I'm assuming this means that we
don't need any locks anymore and I can get rid of the sev_mit_sysfs_mutex and
move unregister outside the sev_cmd_mutex.
I tested this with putting a msleep() in the _show()/_store() and in parallel
rmmod calling shutdown. This seems to work without issues whereas with the
former approach I could deadlock waiting on sev_cmd_mutex.
>
>>> Also, on the register function, all you need is the check for
>>> !(sev->snp_feat_info_0.ecx & SNP_VERIFY_MITIGATION_SUPPORTED) since if
>>> !sev->snp_plat_status.feature_info is true, so is this this check. And, as
>>> the spec says, the required firmware state is based on the mitigation
>>> requirements, so I don't think you should be checking for snp_initialized.
Ack, will just keep the SNP_VERIFY_MITIGATION_SUPPORTED check in the next
iteration.
Thanks Tom and Tycho!
--Pratik
> Thanks,
> Tom
>
>>
>> Tycho
>
^ permalink raw reply
* [PATCH] crypto: loongson - Select CRYPTO_RNG
From: Eric Biggers @ 2026-05-22 2:25 UTC (permalink / raw)
To: linux-crypto, Herbert Xu
Cc: linux-kernel, loongarch, Huacai Chen, Qunqin Zhao, Yinggang Gu,
Lee Jones, Eric Biggers, kernel test robot, stable
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>
---
drivers/crypto/loongson/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/loongson/Kconfig b/drivers/crypto/loongson/Kconfig
index 15475da8fc11..f4e1544ffbb4 100644
--- a/drivers/crypto/loongson/Kconfig
+++ b/drivers/crypto/loongson/Kconfig
@@ -1,5 +1,6 @@
config CRYPTO_DEV_LOONGSON_RNG
tristate "Support for Loongson RNG Driver"
depends on MFD_LOONGSON_SE
+ select CRYPTO_RNG
help
Support for Loongson RNG Driver.
base-commit: 6c9dddeb582fde005360f4fe02c760d45ca05fb5
--
2.54.0
^ permalink raw reply related
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