[PATCH 0/2] Add Crypto Engine support for the Glymur SoC

[PATCH 0/2] Add Crypto Engine support for the Glymur SoC

[Harshal Dev]

Document and add the device-tree nodes to enable the Crypto Engine
and its BAM for Glymur.

Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
Harshal Dev (2):
      dt-bindings: crypto: qcom-qce: Document the Glymur crypto engine
      arm64: dts: qcom: glymur: Add crypto engine

 .../devicetree/bindings/crypto/qcom-qce.yaml       |  1 +
 arch/arm64/boot/dts/qcom/glymur.dtsi               | 26 ++++++++++++++++++++++
 2 files changed, 27 insertions(+)
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260416-glymur_crypto_enablement-be2ff022b429

Best regards,
-- 
Harshal Dev <harshal.dev@oss.qualcomm.com>

[PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Glymur crypto engine

[Harshal Dev]

Document the crypto engine on Glymur platform.

Signed-off-by: Harshal Dev <harshal.dev@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 79d5be2548bc..0b62271f8bfe 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -45,6 +45,7 @@ properties:
 
       - items:
           - enum:
+              - qcom,glymur-qce
               - qcom,kaanapali-qce
               - qcom,qcs615-qce
               - qcom,qcs8300-qce

-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Glymur crypto engine

[Krzysztof Kozlowski]

On Thu, Apr 16, 2026 at 06:37:20PM +0530, Harshal Dev wrote:
> Document the crypto engine on Glymur platform.
> 
> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
>  1 file changed, 1 insertion(+)
>

Poor commit msg, but none of previous patches were doing it better, so:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Glymur crypto engine

[Harshal Dev]

On 4/17/2026 3:17 PM, Krzysztof Kozlowski wrote:
> On Thu, Apr 16, 2026 at 06:37:20PM +0530, Harshal Dev wrote:
>> Document the crypto engine on Glymur platform.
>>
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>>  Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
>>  1 file changed, 1 insertion(+)
>>
> 
> Poor commit msg, but none of previous patches were doing it better, so:

Noted, I'll try to do better next time.

Regards,
Harshal

> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Glymur crypto engine

[Herbert Xu]

On Thu, Apr 16, 2026 at 06:37:20PM +0530, Harshal Dev wrote:
> Document the crypto engine on Glymur platform.
> 
> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
>  1 file changed, 1 insertion(+)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine

[Harshal Dev]

On Glymur, there is a crypto engine IP block similar to the ones found on
SM8x50 platforms.

Describe the crypto engine and its BAM.

Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f23cf81ddb77..e8c796f2c572 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
 			status = "disabled";
 		};
 
+		cryptobam: dma-controller@1dc4000 {
+			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
+			reg = <0x0 0x01dc4000 0x0 0x28000>;
+			interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			iommus = <&apps_smmu 0x480 0x0>,
+				 <&apps_smmu 0x481 0x0>;
+			qcom,ee = <0>;
+			qcom,controlled-remotely;
+			num-channels = <20>;
+			qcom,num-ees = <4>;
+		};
+
+		crypto: crypto@1dfa000 {
+			compatible = "qcom,glymur-qce", "qcom,sm8150-qce", "qcom,qce";
+			reg = <0x0 0x01dfa000 0x0 0x6000>;
+			dmas = <&cryptobam 4>, <&cryptobam 5>;
+			dma-names = "rx",
+				    "tx";
+			iommus = <&apps_smmu 0x480 0x0>,
+				 <&apps_smmu 0x481 0x0>;
+			interconnects = <&aggre1_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+			interconnect-names = "memory";
+		};
+
 		tcsr_mutex: hwlock@1f40000 {
 			compatible = "qcom,tcsr-mutex";
 			reg = <0x0 0x01f40000 0x0 0x20000>;

-- 
2.34.1

Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine

[Konrad Dybcio]

On 4/16/26 3:07 PM, Harshal Dev wrote:
> On Glymur, there is a crypto engine IP block similar to the ones found on
> SM8x50 platforms.
> 
> Describe the crypto engine and its BAM.
> 
> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index f23cf81ddb77..e8c796f2c572 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>  			status = "disabled";
>  		};
>  
> +		cryptobam: dma-controller@1dc4000 {
> +			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
> +			reg = <0x0 0x01dc4000 0x0 0x28000>;
> +			interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
> +			#dma-cells = <1>;
> +			iommus = <&apps_smmu 0x480 0x0>,
> +				 <&apps_smmu 0x481 0x0>;

It seems like these aren't the right SIDs on this platform.. Have you
tested this patch on hw?

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine

[Harshal Dev]

Hi,

On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
> On 4/16/26 3:07 PM, Harshal Dev wrote:
>> On Glymur, there is a crypto engine IP block similar to the ones found on
>> SM8x50 platforms.
>>
>> Describe the crypto engine and its BAM.
>>
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> index f23cf81ddb77..e8c796f2c572 100644
>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>  			status = "disabled";
>>  		};
>>  
>> +		cryptobam: dma-controller@1dc4000 {
>> +			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>> +			reg = <0x0 0x01dc4000 0x0 0x28000>;
>> +			interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>> +			#dma-cells = <1>;
>> +			iommus = <&apps_smmu 0x480 0x0>,
>> +				 <&apps_smmu 0x481 0x0>;
> 
> It seems like these aren't the right SIDs on this platform.. Have you
> tested this patch on hw?

Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
(I hope I don't need to pad them?)

Unfortunately, I could only validate driver probe on my limited ramdisk environment:

[    4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1

I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
SIDs and wait for a Tested-by from him.

Regards,
Harshal

> 
> Konrad

Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine

[Konrad Dybcio]

On 4/17/26 11:22 AM, Harshal Dev wrote:
> Hi,
> 
> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>> SM8x50 platforms.
>>>
>>> Describe the crypto engine and its BAM.
>>>
>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>> ---
>>>  arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>  1 file changed, 26 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>> index f23cf81ddb77..e8c796f2c572 100644
>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>  			status = "disabled";
>>>  		};
>>>  
>>> +		cryptobam: dma-controller@1dc4000 {
>>> +			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>> +			reg = <0x0 0x01dc4000 0x0 0x28000>;
>>> +			interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>> +			#dma-cells = <1>;
>>> +			iommus = <&apps_smmu 0x480 0x0>,
>>> +				 <&apps_smmu 0x481 0x0>;
>>
>> It seems like these aren't the right SIDs on this platform.. Have you
>> tested this patch on hw?
> 
> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
> (I hope I don't need to pad them?)

No, you don't

> 
> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
> 
> [    4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
> 
> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
> SIDs and wait for a Tested-by from him.

Thanks

I think you should be able to get some life out of the crypto engine
via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
mentioned reports a failure on Hamoa)

Konrad

Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine

[Harshal Dev]

On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
> On 4/17/26 11:22 AM, Harshal Dev wrote:
>> Hi,
>>
>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>> SM8x50 platforms.
>>>>
>>>> Describe the crypto engine and its BAM.
>>>>
>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>  1 file changed, 26 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>  			status = "disabled";
>>>>  		};
>>>>  
>>>> +		cryptobam: dma-controller@1dc4000 {
>>>> +			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>> +			reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>> +			interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>> +			#dma-cells = <1>;
>>>> +			iommus = <&apps_smmu 0x480 0x0>,
>>>> +				 <&apps_smmu 0x481 0x0>;
>>>
>>> It seems like these aren't the right SIDs on this platform.. Have you
>>> tested this patch on hw?
>>
>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>> (I hope I don't need to pad them?)
> 
> No, you don't

Ack.

> 
>>
>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>
>> [    4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>
>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>> SIDs and wait for a Tested-by from him.
> 
> Thanks
> 
> I think you should be able to get some life out of the crypto engine
> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
> mentioned reports a failure on Hamoa)

Sure, I'll try this, could you also point me to the bug report?

Regards,
Harshal

> 
> Konrad

Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine

[johannes.goede]

Hi,

On 17-Apr-26 15:38, Harshal Dev wrote:
> 
> 
> On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
>> On 4/17/26 11:22 AM, Harshal Dev wrote:
>>> Hi,
>>>
>>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>>> SM8x50 platforms.
>>>>>
>>>>> Describe the crypto engine and its BAM.
>>>>>
>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>> ---
>>>>>  arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>>  1 file changed, 26 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>>  			status = "disabled";
>>>>>  		};
>>>>>  
>>>>> +		cryptobam: dma-controller@1dc4000 {
>>>>> +			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>>> +			reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>>> +			interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>>> +			#dma-cells = <1>;
>>>>> +			iommus = <&apps_smmu 0x480 0x0>,
>>>>> +				 <&apps_smmu 0x481 0x0>;
>>>>
>>>> It seems like these aren't the right SIDs on this platform.. Have you
>>>> tested this patch on hw?
>>>
>>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>>> (I hope I don't need to pad them?)
>>
>> No, you don't
> 
> Ack.
> 
>>
>>>
>>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>>
>>> [    4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>>
>>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>>> SIDs and wait for a Tested-by from him.
>>
>> Thanks
>>
>> I think you should be able to get some life out of the crypto engine
>> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
>> mentioned reports a failure on Hamoa)
> 
> Sure, I'll try this, could you also point me to the bug report?

No bug report yet, I was asking around internally who I should
talk to about his.

I'm seeing 7.0-rc# QCE crypto selftest failures on a Lenovo ThinkPad
T14s gen 6 (Hamoa x1e78100):

[    1.357020] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
[    1.369951] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
[    1.443143] alg: aead: rfc4309-ccm-aes-qce decryption failed on test vector 1; expected_error=0, actual_error=-6, cfg="misaligned splits crossing pages, inplace"

This is with manually compiled 7.0-rc# using Fedora's default kernel
config which includes: CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y
with the latter being hidden behind CONFIG_EXPERT for some reason.

This is a regression compared to 6.19.y where CONFIG_CRYPTO_SELFTESTS=y
is also enabled by Fedora and it works fine.

I've not looked further into this yet, other then a message to fellow
OSTT team arm64-laptop users asking for tips / whom to report this to.

I would be happy to send create a kernel.bugzilla.org bug-report
about this to, or report to email somewhere, or ...

Please let met know where you want a bug-report to be filed and
also what information to add on top of the above info ?

E.g. these failures trigger a WARN() and thus log a backtrace,
do you want those backtraces and if yes I presume I should run
them through addr2line  ?

Regards,

Hans

Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine

[Harshal Dev]

+Udit, +Bartoz

Hello Hans,

On 4/17/2026 8:00 PM, johannes.goede@oss.qualcomm.com wrote:
> Hi,
> 
> On 17-Apr-26 15:38, Harshal Dev wrote:
>>
>>
>> On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
>>> On 4/17/26 11:22 AM, Harshal Dev wrote:
>>>> Hi,
>>>>
>>>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>>>> SM8x50 platforms.
>>>>>>
>>>>>> Describe the crypto engine and its BAM.
>>>>>>
>>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>>> ---
>>>>>>  arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>>>  1 file changed, 26 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>>>  			status = "disabled";
>>>>>>  		};
>>>>>>  
>>>>>> +		cryptobam: dma-controller@1dc4000 {
>>>>>> +			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>>>> +			reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>>>> +			interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> +			#dma-cells = <1>;
>>>>>> +			iommus = <&apps_smmu 0x480 0x0>,
>>>>>> +				 <&apps_smmu 0x481 0x0>;
>>>>>
>>>>> It seems like these aren't the right SIDs on this platform.. Have you
>>>>> tested this patch on hw?
>>>>
>>>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>>>> (I hope I don't need to pad them?)
>>>
>>> No, you don't
>>
>> Ack.
>>
>>>
>>>>
>>>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>>>
>>>> [    4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>>>
>>>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>>>> SIDs and wait for a Tested-by from him.
>>>
>>> Thanks
>>>
>>> I think you should be able to get some life out of the crypto engine
>>> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
>>> mentioned reports a failure on Hamoa)
>>
>> Sure, I'll try this, could you also point me to the bug report?
> 
> No bug report yet, I was asking around internally who I should
> talk to about his.
> 
> I'm seeing 7.0-rc# QCE crypto selftest failures on a Lenovo ThinkPad
> T14s gen 6 (Hamoa x1e78100):
> 
> [    1.357020] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
> [    1.369951] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
> [    1.443143] alg: aead: rfc4309-ccm-aes-qce decryption failed on test vector 1; expected_error=0, actual_error=-6, cfg="misaligned splits crossing pages, inplace"
> 
> This is with manually compiled 7.0-rc# using Fedora's default kernel
> config which includes: CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y
> with the latter being hidden behind CONFIG_EXPERT for some reason.
>
> This is a regression compared to 6.19.y where CONFIG_CRYPTO_SELFTESTS=y
> is also enabled by Fedora and it works fine.

Our Crypto Engine enablement for Hamoa (x1e80100) was merged as part of the 7.0 kernel
https://lore.kernel.org/all/a9a6b840-5a4f-4d27-8b34-da82657e5c9d@app.fastmail.com/

I did not run the CRYPTO_SELF_TESTS for these, so I am not sure if they were passing
for 7.0 with the Crypto Engine enablement changes. I also do not know if we have been
running the self-tests for other Qualcomm targets which have support for the Crypto Engine.
Maybe Bartoz can help answer this, since he has been involved from the beginning.

But it is worthwhile to check if something else introduced this regression or simply
the enablement of Crypto Engine on Hamoa. If you have a manually compiled 7.0-rc build
could you perhaps check reproduction after reverting this commit?
7d1974ce80fc386834e5667b0f579c2c766c4faa ("arm64: dts: qcom: x1e80100: Add crypto engine")

> 
> I've not looked further into this yet, other then a message to fellow
> OSTT team arm64-laptop users asking for tips / whom to report this to.
> 
> I would be happy to send create a kernel.bugzilla.org bug-report
> about this to, or report to email somewhere, or ...
> 
> Please let met know where you want a bug-report to be filed and
> also what information to add on top of the above info ?
> 
> E.g. these failures trigger a WARN() and thus log a backtrace,
> do you want those backtraces and if yes I presume I should run
> them through addr2line  ?
> 

Please send an email to me, Neeraj, Udit and Bartoz for a separate discussion on this.
Please provide information which can help us reproduce this on our setup, and
also the the dmesg and backtrace logs which you are mentioning here apart from any
other information which you feel is relevant.

Thank you very much for your efforts on this!
Regards,
Harshal

> Regards,
> 
> Hans
> 
>